build · juliusbrussee — Claude Code skill: what it does, how to install
Implements tasks from SPEC.md through a plan, execution and verification loop. Use it for a specific §T task or the next unfinished item.
npx skills add JuliusBrussee/cavekit --skill build -a claude-codeWhat build does
The skill reads SPEC.md, selects a §T task from its argument, or picks the next unfinished task. Before editing, it checks relevant §V invariants, affected §I interfaces, files to change and the verification command. When SPEC.md is missing, it directs you to the spec skill first.
For changes involving shared modules, auth, data, money or public §I, it runs /review. It then updates the task status in SPEC.md, edits the code and runs the chosen check. This skill is a poor fit for parallel work because it uses one thread and creates no sub-agents.
A passing check marks the task as x and creates a commit containing the task goal and §V references. On a failed test or build, build invokes backprop before retrying. It distinguishes a code defect from a spec issue or an unspecified edge case, calling spec first for the latter two.
What it helps with
- implement a selected §T task from
SPEC.md - pick the next unfinished task
- map §V invariants to named tests
- run
/reviewfor a high-impact change - send a failed check back to the specification
Example prompts for the agent
build §T.3build --next- Run the build for all unfinished tasks in
SPEC.md.
How to install build
1Skills CLI (Vercel)
npx skills add JuliusBrussee/cavekit --skill build -a claude-code2Manually: put the files in place
~/.claude/skills/build/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/build/
1Skills CLI (Vercel)
npx skills add JuliusBrussee/cavekit --skill build -a codex2Manually: put the files in place
.agents/skills/build/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add JuliusBrussee/cavekit --skill build -a cursor2Manually: put the files in place
.cursor/skills/build/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install JuliusBrussee/cavekit build2Manually: put the files in place
.github/skills/build/SKILL.md1Skills CLI (Vercel)
npx skills add JuliusBrussee/cavekit --skill build -a gemini-cli2Platform CLI
gemini skills install https://github.com/JuliusBrussee/cavekit --path skills/buildManually: put the files in place
.devin/skills/build/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add JuliusBrussee/cavekit --skill build -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about build
How do I install build in Claude Code?
Run npx skills add JuliusBrussee/cavekit --skill build -a claude-code, then run npx skills add JuliusBrussee/cavekit --skill build -a claude-code again. The skill file is placed at ~/.claude/skills/build/SKILL.md.
What does build do?
It plans and implements tasks from SPEC.md, then validates the result with a named test, build or lint command. It updates task status and commits after a successful check.
What happens when a test or build fails?
build invokes backprop before retrying. If the issue is in the specification or an unspecified edge case, it calls spec to update §V and §B before resuming.
Source text
SKILL.md · MIT
--- name: build description: | 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 1. Read `SPEC.md`. If missing → tell user to invoke the spec skill first. Stop. 2. Read `FORMAT.md` once if not loaded. 3. Read §R if present — external facts the build must honor, ⊥ re-derive or contradict. 4. Parse invocation args: - `§T.n` → that task only - `--next` → lowest-numbered row with status `.` or `~` - `--all` or 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): 1. Cite every §V invariant that applies. Plan must respect all. 2. Cite every §I interface touched. Plan must preserve shape. 3. List files to create / edit. 4. **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. 5. 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: 1. Flip §T.n status cell `.` → `~`. Just write to SPEC.md. 2. Edit code per plan. 3. Run verification command. 4. **Pass** → flip `~` → `x`. Next task. 5. **Fail** → invoke backprop skill. Do NOT retry blindly. ## FAIL → BACKPROP On test/build failure: 1. Read failure output. 2. Ask: is failure (a) my code bug, (b) spec wrong, or (c) unspecified edge case? 3. If (a) → fix code, re-run. No spec change. 4. 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. ## WRITE POLICY - Only flip §T status. No other SPEC.md edits from build. - Other spec edits → invoke spec skill. - Commit after each §T completes. Message: `T<n>: <goal line>` + §V cites. ## VERIFICATION Task `x` only if: - Verification command (the oracle) exits 0. - Every §V touched has its named test from the verification contract, and it passes. - No §V invariant regressed (run full test suite at end). ## NON-GOALS - No sub-agents. No parallel workers. Main thread only. - No progress dashboards. `cat SPEC.md | grep §T` is the dashboard. - No speculative work beyond chosen task scope.
© JuliusBrussee · MIT · JuliusBrussee/cavekit
Similar skills
All skills for Agent setup: memory, context, orchestration →build by other authors comes first.