spec
Original:🇺🇸 English
Translated
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.
3installs
Sourcejuliusbrussee/cavekit
Added on
NPX Install
npx skill4agent add juliusbrussee/cavekit specTags
Translated version includes tags in frontmatterSKILL.md Content
View Translation Comparison →spec — spec mutator
Read at repo root if not already loaded. Caveman skill applies to all writes here.
FORMAT.mdDISPATCH
Inspect user request and project state:
- No at repo root AND args describe idea → NEW
SPEC.md - No AND
SPEC.mdin args → DISTILLfrom-code - exists AND args start
SPEC.md→ BACKPROPbug: - exists AND args start
SPEC.md→ AMENDamend - exists, no args → ask user which mode
SPEC.md
NEW — idea → spec
Input: user idea.
Steps:
- Extract goal (1 line, caveman). → §G.
- List constraints user stated or implied. → §C.
- List external surfaces user named. → §I.
- Propose initial invariants. → §V (numbered V1…).
- Break goal into ordered tasks. → §T pipe table, all status , ids T1…
. - §B section with header row only ().
id|date|cause|fix
Write to . Show user full file. Ask: "spec OK? suggest edits or invoke build."
SPEC.mdDISTILL — 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:
- Parse bug description.
- Find root cause (read relevant code).
- Decide: would a new invariant catch recurrence? If yes → draft .
V<next> - Append §B row: .
B<next>|<date>|<cause>|V<N> - Append new invariant to §V.
- If fix also changes behavior → add/update §T rows.
- Show diff. Apply only on user OK.
Rule: every bug gets a §B entry. Invariant optional but preferred.
AMEND — targeted edit
Input: or etc.
amend §V.3amend §TRead 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 column ! list §V/§I deps:
cites.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.