spec

# 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.