SECURITY REVIEW
Not yet assessed
Review the original instructions and requested permissions before installing.
No security review is available for this catalog entry yet.
Documentation · Writing / AGENT SKILL
spec
0
Create and maintain SPEC.md, including invariants, tasks, and bug records.
Create, amend, or backprop bugs into SPEC.md at repo root. Sole mutator
of the project spec. Triggers when the user asks to write a spec, start
a new spec, distill a spec from existing code, add invariants, amend
sections (§G, §C, §I, §V, §T, §B), or record a bug via backprop.
Common phrasings: "write the spec for...", "new spec", "bug: ...",
"amend §V.3", "distill spec from code", "spec this idea". Reads and
follows FORMAT.md for the caveman encoding rules and pipe-table shape
of §T and §B.
Understand the trade-offs.
SKILL QUALITY
Not yet assessed
How clearly the skill guides your agent, how complete its workflow is, and how you can check the outcome.
No quality assessment is available for this catalog entry yet.
The full skill.
Original instructions from the publisher’s SKILL.md
# spec — spec mutator Read `FORMAT.md` at repo root if not already loaded. Caveman skill applies to all writes here. ## DISPATCH Inspect user request and project state: 1. No `SPEC.md` at repo root AND args describe idea → **NEW** 2. No `SPEC.md` AND `from-code` in args → **DISTILL** 3. `SPEC.md` exists AND args start `bug:` → **BACKPROP** 4. `SPEC.md` exists AND args start `amend` → **AMEND** 5. `SPEC.md` exists, no args → ask user which mode ## INPUTS — spec is the sole mutator The other verbs produce material; spec writes it. Ingest their handoff blocks into the right section, show a diff, write on OK: - **grill** → sharpened §G + §C - **research** → §R rows (add the §R section if absent) - **review** → drafted §V lines + the risk verdict - **deepen** → §I/§V/§T amendments ⊥ rewrite a section the handoff did not name. Sectioned ownership (see FORMAT.md). ## NEW — idea → spec Input: user idea. If it arrived fuzzy, prefer running **grill** first. Steps: 1. Extract goal (1 line, caveman). → §G. 2. List constraints user stated or implied. → §C. 3. List external surfaces user named. → §I. 4. §R only if **research** ran — else omit the section (right-size). 5. Propose initial invariants. → §V (numbered V1…). 6. Break goal into ordered tasks. → §T pipe table, all status `.`, ids T1… 7. §B section with header row only (`id|date|cause|fix`). Write to `SPEC.md`. Show user full file. Ask: "spec OK? `/review` if high-blast-radius, else `/build`." ## DISTILL — code → spec Walk repo. Produce §G (infer from README/package.json/main entry), §C (infer from stack), §I (enumerate public APIs/CLIs/configs), §V (derive from tests and assertions), §T (one task per known TODO or missing test), §B (empty). Caveman everywhere. Flag uncertain items with `?` in text so user can confirm. ## BACKPROP — bug → §B + §V Input: `bug: <description>`. Steps: 1. Parse bug description. 2. Find root cause (read relevant code). 3. Decide: would a new invariant catch recurrence? If yes → draft `V<next>`. 4. Append §B row: `B<next>|<date>|<cause>|V<N>`. 5. Append new invariant to §V. 6. If fix also changes behavior → add/update §T rows. 7. Show diff. Apply only on user OK. Rule: every bug gets a §B entry. Invariant optional but preferred. ## AMEND — targeted edit Input: `amend §V.3` or `amend §T` etc. Read that section. Show current. Ask user what changes. Write. Show diff. Never silently rewrite sections user did not name. ## OUTPUT RULES - Caveman format per `FORMAT.md`. - Preserve identifiers, paths, code verbatim. - Numbering monotonic — never reuse §V.N or §B.N. - §T row `cites` column ! list §V/§I deps: `T5|.|impl auth mw|V2,I.api`. ## NON-GOALS - No sub-agents. Main thread writes. - No dashboards, no logs, no state files beyond SPEC.md itself. - No auto-build after spec. User invokes build explicitly.