spec

Name: spec
Author: JuliusBrussee

2.3kinstalls81forks

How to install spec?

juliusbrussee/cavekit/spec

$npx -y skills add JuliusBrussee/cavekit --skill spec

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	# spec — spec mutator
2
3	Read `FORMAT.md` at repo root if not already loaded. Caveman skill applies to all writes here.
4
5	## DISPATCH
6
7	Inspect user request and project state:
8
9	1. No `SPEC.md` at repo root AND args describe idea → NEW
10	2. No `SPEC.md` AND `from-code` in args → DISTILL
11	3. `SPEC.md` exists AND args start `bug:` → BACKPROP
12	4. `SPEC.md` exists AND args start `amend` → AMEND
13	5. `SPEC.md` exists, no args → ask user which mode
14
15	## INPUTS — spec is the sole mutator
16
17	The other verbs produce material; spec writes it. Ingest their handoff blocks
18	into the right section, show a diff, write on OK:
19
20	- grill → sharpened §G + §C
21	- research → §R rows (add the §R section if absent)
22	- review → drafted §V lines + the risk verdict
23	- deepen → §I/§V/§T amendments
24
25	⊥ rewrite a section the handoff did not name. Sectioned ownership (see FORMAT.md).
26
27	## NEW — idea → spec
28
29	Input: user idea. If it arrived fuzzy, prefer running grill first.
30
31	Steps:
32	1. Extract goal (1 line, caveman). → §G.
33	2. List constraints user stated or implied. → §C.
34	3. List external surfaces user named. → §I.
35	4. §R only if research ran — else omit the section (right-size).
36	5. Propose initial invariants. → §V (numbered V1…).
37	6. Break goal into ordered tasks. → §T pipe table, all status `.`, ids T1…
38	7. §B section with header row only (`id\|date\|cause\|fix`).
39
40	Write to `SPEC.md`. Show user full file. Ask: "spec OK? `/review` if high-blast-radius, else `/build`."
41
42	## DISTILL — code → spec
43
44	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).
45
46	Caveman everywhere. Flag uncertain items with `?` in text so user can confirm.
47
48	## BACKPROP — bug → §B + §V
49
50	Input: `bug: <description>`.
51
52	Steps:
53	1. Parse bug description.
54	2. Find root cause (read relevant code).
55	3. Decide: would a new invariant catch recurrence? If yes → draft `V<next>`.
56	4. Append §B row: `B<next>\|<date>\|<cause>\|V<N>`.
57	5. Append new invariant to §V.
58	6. If fix also changes behavior → add/update §T rows.
59	7. Show diff. Apply only on user OK.
60
61	Rule: every bug gets a §B entry. Invariant optional but preferred.
62
63	## AMEND — targeted edit
64
65	Input: `amend §V.3` or `amend §T` etc.
66
67	Read that section. Show current. Ask user what changes. Write. Show diff.
68
69	Never silently rewrite sections user did not name.
70
71	## OUTPUT RULES
72
73	- Caveman format per `FORMAT.md`.
74	- Preserve identifiers, paths, code verbatim.
75	- Numbering monotonic — never reuse §V.N or §B.N.
76	- §T row `cites` column ! list §V/§I deps: `T5\|.\|impl auth mw\|V2,I.api`.
77
78	## NON-GOALS
79
80	- No sub-agents. Main thread writes.
81	- No dashboards, no logs, no state files beyond SPEC.md itself.
82	- No auto-build after spec. User invokes build explicitly.

People who liked this also viewed

6 picks

Type

spec

2.3kinstalls81forks

View on GitHub

How to install spec?

juliusbrussee/cavekit/spec

$npx -y skills add JuliusBrussee/cavekit --skill spec

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# spec — spec mutator
2
3	Read `FORMAT.md` at repo root if not already loaded. Caveman skill applies to all writes here.
4
5	## DISPATCH
6
7	Inspect user request and project state:
8
9	1. No `SPEC.md` at repo root AND args describe idea → NEW
10	2. No `SPEC.md` AND `from-code` in args → DISTILL
11	3. `SPEC.md` exists AND args start `bug:` → BACKPROP
12	4. `SPEC.md` exists AND args start `amend` → AMEND
13	5. `SPEC.md` exists, no args → ask user which mode
14
15	## INPUTS — spec is the sole mutator
16
17	The other verbs produce material; spec writes it. Ingest their handoff blocks
18	into the right section, show a diff, write on OK:
19
20	- grill → sharpened §G + §C
21	- research → §R rows (add the §R section if absent)
22	- review → drafted §V lines + the risk verdict
23	- deepen → §I/§V/§T amendments
24
25	⊥ rewrite a section the handoff did not name. Sectioned ownership (see FORMAT.md).
26
27	## NEW — idea → spec
28
29	Input: user idea. If it arrived fuzzy, prefer running grill first.
30
31	Steps:
32	1. Extract goal (1 line, caveman). → §G.
33	2. List constraints user stated or implied. → §C.
34	3. List external surfaces user named. → §I.
35	4. §R only if research ran — else omit the section (right-size).
36	5. Propose initial invariants. → §V (numbered V1…).
37	6. Break goal into ordered tasks. → §T pipe table, all status `.`, ids T1…
38	7. §B section with header row only (`id\|date\|cause\|fix`).
39
40	Write to `SPEC.md`. Show user full file. Ask: "spec OK? `/review` if high-blast-radius, else `/build`."
41
42	## DISTILL — code → spec
43
44	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).
45
46	Caveman everywhere. Flag uncertain items with `?` in text so user can confirm.
47
48	## BACKPROP — bug → §B + §V
49
50	Input: `bug: <description>`.
51
52	Steps:
53	1. Parse bug description.
54	2. Find root cause (read relevant code).
55	3. Decide: would a new invariant catch recurrence? If yes → draft `V<next>`.
56	4. Append §B row: `B<next>\|<date>\|<cause>\|V<N>`.
57	5. Append new invariant to §V.
58	6. If fix also changes behavior → add/update §T rows.
59	7. Show diff. Apply only on user OK.
60
61	Rule: every bug gets a §B entry. Invariant optional but preferred.
62
63	## AMEND — targeted edit
64
65	Input: `amend §V.3` or `amend §T` etc.
66
67	Read that section. Show current. Ask user what changes. Write. Show diff.
68
69	Never silently rewrite sections user did not name.
70
71	## OUTPUT RULES
72
73	- Caveman format per `FORMAT.md`.
74	- Preserve identifiers, paths, code verbatim.
75	- Numbering monotonic — never reuse §V.N or §B.N.
76	- §T row `cites` column ! list §V/§I deps: `T5\|.\|impl auth mw\|V2,I.api`.
77
78	## NON-GOALS
79
80	- No sub-agents. Main thread writes.
81	- No dashboards, no logs, no state files beyond SPEC.md itself.
82	- No auto-build after spec. User invokes build explicitly.

People who liked this also viewed

6 picks

Type