Skill Lifecycle
How a skill is created, gated for approval, graded, and optimised — from draft to production.
A skill is not merely written and dropped into the catalogue. It moves through a lifecycle designed so that a new capability is proven before it is trusted, and measured after it ships.
The lifecycle tool
A single lifecycle skill covers four modes:
| Mode | Purpose |
|---|---|
| Create | Draft a new skill from a specification, following the drafting guide. |
| Convert | Turn an existing legacy command into a skill. |
| Audit | Run a structured multi-point audit of a skill's quality. |
| Optimise | Improve an existing skill against measured shortcomings. |
Creation and optimisation run against a drafting guide that fixes the anatomy of a skill: a tight name, a description written to trigger accurately, staged instructions, and only the references a run actually needs.
The approval gate
New or materially changed skills pass through a staged approval gate before they are trusted in production:
- Pre-flight — the draft is checked against the drafting guide and the audit checklist.
- Verification — a verification agent grades the skill's behaviour against representative inputs, watching both for correct activation and for correct output.
- Operator sign-off — the operator approves distinctive or higher-risk skills; low-risk, audit-clean skills with a distinctive trigger may skip later gates by explicit decision.
- Monitoring — once live, the skill's real-world behaviour feeds the improvement machinery.
The registry is the source of truth for what is installed. A single-skill change is a targeted registry edit — never a full regeneration, which would clobber the hand-elaborated zones (audit dispositions, install notes, conversion queue) that the registry accumulates.
Grading
Three verification skills measure skill quality objectively:
- Grade — score a skill's output against a rubric.
- Compare — blind-compare two versions of a skill's output to decide which is better.
- Analyse — explain why one version outperforms another, so the win is reproducible.
Self-correcting runs
For work that should be pursued until it passes rather than in a single shot, a loop-composition skill wraps a goal in a bounded, grader-gated loop: it composes a per-goal contract, runs iterations against a design-match harness, and exits in one of three states — clean, capped (budget exhausted), or blocked — under an explicit kill-switch and evidence gate. This is how "keep iterating until it matches" becomes a governed protocol rather than an open-ended burn.
See improvement for the autonomous machinery that turns live telemetry back into skill changes.