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.

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.