Build
Plan-then-execute implementation against SPEC.md.
Install
npx skills add JuliusBrussee/cavekit --skill build -g -a claude-code -y- Repository
- JuliusBrussee/cavekit1.2k
- Category
- Testing
- Updated
- 3mo ago
- License
- MIT
- Context cost
- Lightabout 644 tokens
- Runs scripts
- No, instructions only
What it does
Plan-then-execute implementation against SPEC.md. Native single-thread loop, no sub-agents. On test or build failure, auto-invokes the backprop skill before retrying, a failed verification always considers whether a new §V invariant would prevent recurrence. Triggers when the user asks to build, implement, execute the spec, or tackle a specific §T task (`build §T.3`, `build --next`, `implement next task`, `run the build`). Expects SPEC.md to exist; if not, defers to the spec skill.
build, implement spec
Single-thread native plan→execute. You are main Claude. No swarm.
LOAD
- Read
SPEC.md. If missing → tell user to invoke the spec skill first. Stop. - Read
FORMAT.mdonce if not loaded. - Read §R if present, external facts the build must honor, ⊥ re-derive or contradict.
- Parse invocation args:
§T.n→ that task only--next→ lowest-numbered row with status.or~--allor empty → every.row in §T order
High blast radius (shared module, auth, data, money, public §I)? Run /review first. Trivial & reversible? Skip planning ceremony, just do step EXECUTE.
PLAN
Native plan mode, you delegate to it, you do not reinvent task breakdown. For chosen task(s):
- Cite every §V invariant that applies. Plan must respect all.
- Cite every §I interface touched. Plan must preserve shape.
- List files to create / edit.
- Verification contract, name the EXACT test(s) / acceptance criteria that prove each §V touched. Which test, not "add tests". "Do TDD" alone backfires; the spec says what to check. Each §V touched → a named test that fails first.
- Name verification command (test, build, lint), this is the external oracle. Green = done; ⊥ "looks done".
Show plan. Wait for user OK unless auto mode.
EXECUTE
Per task in order:
- Flip §T.n status cell
.→~. Just write to SPEC.md. - Edit code per plan.
- Run verification command.
- Pass → flip
~→x. Next task. - Fail → invoke backprop skill. Do NOT retry blindly.
FAIL → BACKPROP
On test/build failure:
- Read failure output.
- Ask: is failure (a) my code bug, (b) spec wrong, or (c) unspecified edge case?
- If (a) → fix code, re-run. No spec change.
- If (b) or (c) → invoke spec skill with
bug: <cause>first, let it update §V and §B, then resume build against updated spec.
Rule: never silently fix root-cause without considering backprop. §B is the memory that stops recurrence.
