Memory, code, skills and workflows

Remember: shared memory

Korium:mem holds the decisions, lessons, corrections and handoffs that explain the work. An assistant reads that memory before it decides and saves useful learning as it goes. Another authorized assistant can use the same material later.

Start here even if you are not writing software. A project decision, a client constraint or an operating lesson can be useful without any code attached. Save and retrieve your first memory.

Locate: code intelligence

Korium:code is a map of symbols in a repository, tied to a commit. It points an agent toward relevant files and line ranges. The agent then reads the source locally, instead of repeatedly exploring the whole tree.

The Mac CLI builds and updates that map. It does not upload source text, and it does not replace tests or local verification. Index a repository, then use memory to explain the decisions behind the code.

Equip: ready-made skills

A skill is a reusable set of instructions for a particular kind of work. It can explain the steps, the evidence to check and what a good result looks like. Load the skill when the task needs it instead of putting every instruction into every conversation.

Korium’s starter toolkit includes memory and code-search skills, a sample agent, a project rule and hook guidance. Ask your assistant to fetch the toolkit manifest, read its README and show you the proposed files before installing them.

Use the Korium toolkit tool to read the guide and manifest.
Show me which files apply to this project. Do not overwrite
my existing project instructions or hooks.

The toolkit is text. Fetching it does not run it, install the CLI or grant the agent any new permissions.

Run: workflows you can change

A workflow describes how a piece of work proceeds: which steps come first, where a person makes a decision and what needs to be handed to the next step. Start with an available playbook, adapt it to your team or write your own.

First ask the connected tools which catalog you can access. Where bottega_config is exposed, call it with the request below and inspect platform_playbooks. Each entry identifies a playbook, its version and its content hash.

{ "schema_version": "1" }

This is a configuration read, not a download or a run. Load the chosen playbook through the skill-loading tool or installed catalog your environment actually provides. If none is available, stop at choosing the playbook and ask your administrator how to install it; do not invent a fetch command.

For example, account-plan was present in the catalog checked for this guide. Select that returned entry, inspect its version, load its instructions through your configured loader and review them before supplying client information. A persona is not another workflow, and the available catalog is not proof that every listed playbook is installed.

Keep the input, the outcome and what you changed. If the workflow failed, save the failure and evidence too. Connecting the memory MCP service alone does not install a workflow runner.

Make a release check reusable

This is an illustrative workflow you can write locally after the first-memory exercise. It is not a claim that an identically named catalog item exists. Ask your assistant to propose a new release-check-demo/SKILL.md in its project skill directory, without replacing an existing skill.

The complete file can start like this:

---
name: release-check-demo
description: Run the labeled onboarding release-check demonstration using Korium memory. Do not use this demonstration as a real release policy.
---

# Release-check demonstration

Use synthetic totals only. This exercise does not authorize a release.

1. Search onboarding.demo for the current release-check rule.
2. Read its source and replacement links. If the rule is unclear, ask.
3. Prepare the totals and list the checks the rule requires.
4. Show where a real workflow would require each review. Do not invent sign-off.
5. Report the result and save what changed, with evidence.
6. Keep every saved outcome labeled as demonstration material.
7. If the checks need improving, propose a skill change for review.

Review the file before installing it. Start a fresh session, confirm the assistant can find the skill and ask it to use release-check-demo on synthetic totals. If it cannot find the skill, check that client’s configured skill directory before proceeding.

The memory supplies the rule and its reason. The skill supplies reusable instructions. The workflow puts reading, checking, approval and saving in order; code search is only needed if the task also involves software.

After a dry run, inspect the output and the new memory receipt. If you improve the skill, review and save the file change as well as the reason in memory. Capturing a lesson does not automatically update the skill file or publish a new catalog version.

Put the four parts into one task

1. Read memory. Find the relevant decisions and constraints.
2. Locate the code. Ask the index where the implementation lives, then verify the source.
3. Load the skill. Use the instructions appropriate to the work.
4. Run the workflow. Do the work, with the required human approvals.
5. Save the learning. Capture what changed, why, how it was checked and what remains open.

You can use only the parts you need. A non-technical team may start with shared memory. A software team may use all four in the same task.

Where to find the exact tools

The tool reference explains capture, search, browse, trace, imports, relations and code search. Your client’s live tool list is the authority for the exact schema and what your connection is permitted to call.

Tool availability, an installed skill and a working integration are separate checks. When something is missing, identify which one you expected before reinstalling the whole setup.