Write an Instruction
Type: kb/types/instruction.md
An instruction is a reusable procedure that lives in kb/instructions/. It has the same format as a skill but is invoked manually rather than through automatic routing.
Instructions are created in two moves. First, abstract the stable core: do the task by hand several times, notice which steps recur and which vary, and conjecture the recurring steps as a procedure with its boundary — the repetition is the evidence that licenses the generalization. Second, where companion methodology notes exist, work the procedure body out from them: the written steps should be recoverable from the methodology plus the task, so a methodology change flags the instruction for rework. The variable parts become parameters or decision points. The reasoning that produced the steps stays in methodology notes, not in the instruction.
Instructions must be frontloaded — self-contained enough for an agent with no prior context. Define terms inline. Don't assume the reader has loaded other KB documents. An instruction may be handed to a sub-agent that has nothing else in its context window.
Prerequisites
You should have performed the task manually at least twice in different contexts. If you haven't, do it manually first — you can't abstract a stable core from repetitions that haven't happened.
Steps
-
Identify the stable core. Review what you did across instances. Which steps recurred? Which parts varied by context? The recurring steps are the procedure; the intro's two moves say what happens to the rest.
-
Draft the procedure. Write it as a sequence of imperative steps. Use "do X" not "X is important because." Include:
- What to check before starting (prerequisites)
- The steps in execution order
- Decision points where context determines the path
- What to verify when done
-
What NOT to do (critical constraints)
-
Add frontmatter. Every instruction needs: ```yaml
description: One line — what this instruction does, when to use it. type: kb/types/instruction.md
``` The description helps a human scanning the directory decide whether this instruction fits their situation. It also makes promotion to a skill frictionless.
-
Cut the reasoning. Remove explanations of why each step exists. If the reasoning is worth preserving, it belongs in a methodology note that links to this instruction — not in the instruction itself. Keep only enough reasoning for the agent to handle edge cases and decision points.
-
Test the boundaries. Add explicit scope boundaries — when does this instruction NOT apply? The agent won't sense this on its own. If the task falls outside scope, say what to do instead.
-
Write a companion note (optional but recommended). Write a note in
kb/notes/that describes the instruction, explains its rationale, and links to the instruction file. Keep its two possible source relationships separate: - The stable core is generalized from repeated manual operations. If those source instances are retained and their collection authorizes the edge, record
Abstracted into:at the source. - Where methodology notes shape the procedure body, record
Operationalized into:in each methodology source note, pointing to the instruction. Do not collapse either relationship into a target-sidederived-fromlink.
Verify
- The instruction reads as a sequence of actions, not an essay
- An agent reading it cold could execute it without asking clarifying questions
- Reasoning is minimal — just enough for edge cases
- Scope boundaries are explicit
- Frontmatter has a description
Promotion to skill
If the instruction proves useful enough to warrant automatic routing:
- Create
kb/instructions/<name>/and move the instruction there asSKILL.md. - Add the skill frontmatter fields (
name,allowed-tools,context,model). - Add
<name>toMANIFEST.promoted_skillsinsrc/commonplace/scaffold_manifest.py. - Update the control-plane routing table in
CLAUDE.mdorAGENTS.md.commonplace-initwill then copy that instruction directory into the runtime skill surfaces (.claude/skills/and.agents/skills/) with thecommonplace-prefix.