Skills & Procedures

Skills are reusable procedures for recurring work. How to review a pull request. How to prep a release. How to run browser checks. Encoded once, named, and loaded by the harness exactly when the task matches — instead of every agent rediscovering the process from scratch.

From "remember to..." to a named capability

There's a quiet but pivotal shift hiding in this primitive. Before skills, process knowledge lived in instructions: "remember to run the tests, remember to check the changelog, remember our review checklist." Instructions scale badly — they're always loaded, they compete for attention, and they can't carry real procedure.

A skill moves that expertise into a named capability the harness can invoke:

# skill: review-pr

When to use: reviewing any pull request in this repo.

Steps:
1. Read the diff and the linked issue — understand intent first
2. Check migrations for backwards compatibility
3. Run the focused test suite for touched modules
4. Verify no secrets or debug flags in the diff
5. Leave findings as file:line comments, severity-ordered

Prefer: read-only tools until findings are confirmed.

A good skill encodes when to use it, what inputs it needs, what steps to follow and in what order, and which tools to prefer.

In the wild

You'll see this primitive as skills, slash commands, playbooks, runbooks, recipes, and workflows. The idea became important enough that agent skills are now standardized under the Linux Foundation. In the memory frame, this same layer is called procedural memory — the how-to knowledge that survives across sessions.

Procedure is necessary — but it is not evidence

A skill can say run the tests. It cannot confirm they passed. It can say check the browser rendering. Was the screenshot actually clean? Making work repeatable is not the same as proving the work succeeded.

The agent will end its turn saying "done." The harness needs a way to reply: "show me."