writing-kit-skills

A kit skill exists to make an agent take the same process every run. Every rule here serves that predictability at the lowest token cost that still binds weaker CLIs — this kit installs standalone into many runtimes, so redundancy is spent deliberately, never by accident.

The skeleton

Every SKILL.md follows this order, skipping sections it genuinely doesn't need:

Definitional opener — one or two sentences stating what the skill produces and the boundary that makes it this skill and not a neighbour. No ## Purpose heading, no restatement of the frontmatter description.
Inputs — what must be known before work starts, and the stop-and-ask rule for anything missing.
Rules — the binding constraints. Each prohibition is paired with the positive action ("Dispatch fires only on explicit user say-so; until then, keep capturing"), and may carry one clause of rationale. No second section restating rules in negated form.
Process / Workflow / Modes — ### N. Verb-phrase steps or named modes. Each step ends where an agent can tell done from not-done.
The artifact (when the skill writes one) — template plus two or three filled sample rows at most; full examples live in references/.
Output — the exact chat surface: templates, caps, and the stop.
Completion criteria — observable checks only (a path that exists, a command output, a read-back match, a git status state). Never checklist items that re-assert body rules; the body already binds them.

Word budget

A SKILL.md runs 1,000–1,300 words; 1,500 (body only, after the closing ---) is the validator-enforced ceiling. Over budget → move mechanics and long examples to references/; never hit budget by thinning refusal or safety language.