Korium:Skills

Memory keeps what you learned. A skill says how to work.

“This client needs a named owner for every deliverable” is a memory, with the meeting or decision that supports it. “When reviewing a proposal, check scope, owners, assumptions and exclusions” is a skill. Used together, they help the assistant apply the method to the actual situation.

A skill normally has a SKILL.md instruction file and may include references, templates or scripts. Loading the instructions does not run the scripts or grant new permissions. The assistant still needs the tools, source access and approval required for the work.

Start with the Korium skills

Ask your connected assistant to call korium_get_toolkit with op: "guide", then op: "manifest". Read the returned README. The manifest lists the files, their paths and hashes.

The starter includes skills/korium-memory/SKILL.md and skills/korium-code-search/SKILL.md, plus a house rule, a sample researcher and hook instructions. Fetch a listed file with:

{
  "op": "file",
  "rel_path": "skills/korium-memory/SKILL.md"
}

Check the returned hash against the manifest and review the text before adding it to your project. Fetch only what you need. Your assistant’s MCP connection is enough to retrieve these files; CLI login is for code indexing, not for memory.

Put it where your assistant reads skills

Keep the skill directory and its relative references together. Don’t paste a script into the instruction file or flatten a bundle of supporting files into one paragraph.

• CodexProject skills under .agents/skills, with the existing project rules preserved.
• Claude CodeProject skills under .claude/skills, alongside CLAUDE.md instructions.
• OpenClawThe agent’s workspace skills directory, not a copied client configuration.
• CoworkStart with an explicit task instruction and verified memory calls.

Open a fresh task and ask the assistant which skill it loaded. Then give it a small task with a result you can inspect. A file on disk is not evidence that the assistant used it.

Use a versioned skill from the registry

For bundles beyond the starter toolkit, use the Tinker installer configured for your project. It resolves the release, fetches the files, verifies them and puts them in the declared locations. Ask it to identify the selected version and proposed file changes before accepting the installation.

The installer must already be set up with authorized registry access. It is separate from the code-indexing CLI. If your project has no loader, start with the toolkit above or ask your administrator to configure one; do not borrow another client’s token.

For integration authors: the registry read contract

The installer calls tinker_list, tinker_get_skill and tinker_receipt through MCP tools/call. These names are not advertised in the assistant’s normal tool list. The following request is for that registry client, not a tool to invent in a chat:

{
  "schema_version": "1",
  "channel": "stable"
}

That request goes to tinker_list. Its result identifies each release by namespace, version and channel. Use those returned values, not a guessed bundle name.

1. Call tinker_get_skill with op: "manifest", schema_version: "1", and the returned namespace, semver and channel.
2. Read the manifest and fetch the needed files with op: "file" and a listed rel_path. Keep the same release identity for every file.
3. Use tinker_receipt for that release and verify the file hashes before accepting the bundle. The installer performs these integrity checks when it loads a release.
4. Review permissions, scripts and destination paths before installing. Preserve existing project instructions instead of replacing them wholesale.

A hash confirms the file matches the named release, not that its advice is right for your business. A rejected fetch is not an empty skill. Report the reason instead of reconstructing missing instructions from the title.

Turn a repeated explanation into a skill

Start with one task you already know how to judge. Here is an illustrative proposal-review instruction, not a claim about any customer or a preinstalled catalog entry:

Review this proposal before it goes to the client.
1. Search Korium for this client's agreed scope, constraints and
   lessons from earlier work. Cite the source memories.
2. Read the proposal. Check deliverables, owners, assumptions,
   exclusions and anything that conflicts with those decisions.
3. Separate confirmed problems from questions we need to ask.
4. Return the issue, its evidence and a suggested correction.
5. Wait for approval before changing commitments or sending it.
6. Save only approved new decisions or useful lessons, with sources.

Give the skill a specific name and a description that says when it should be used. Add your team’s review format and an example of a good result. Keep live client facts in memory so you are not maintaining them in every copy of the skill.

Test it, then improve it

Try a proposal with a known omission, one that is already sound and one with a disputed requirement. Check that the skill finds the omission, avoids inventing a problem and asks about the dispute. Review its sources as well as its prose.

When a better method emerges, propose a skill revision and test it before making it the team’s version. Save why you changed the method in memory. Use a workflow when the job needs several stages, handoffs or approval points.