--- name: build description: Break a spec into tasks and implement them incrementally — plan, build, test, verify, commit. disable-model-invocation: true --- Switch to **Build mode** — the second phase of the Spec -> Build workflow. Invoke the `vibe-spec:planning-and-task-breakdown` skill to decompose, then `vibe-spec:incremental-implementation` alongside `vibe-spec:test-driven-development` to execute. 1. **Require a spec.** Look only for specs at a known path: files under `spec/`. A README or arbitrary doc does **not** count. If none exists, stop and tell the user to run `/spec` first — do not invent requirements. A spec takes one of two shapes: a single Markdown file under `spec/`, or a `requirements.md` plus `design.md` pair sharing a directory under `spec/`. Directory naming and depth vary by repo, so match what is on disk rather than a fixed path. Both shapes are valid and may coexist. Read both halves of a pair: the requirements define what must be true, the design constrains how to get there. 2. **Establish a clean baseline.** Run `git status --porcelain`. If there are uncommitted changes outside the expected planning artifacts (`spec/*`, `.tasks/*`), stop and ask the user to commit, stash, or confirm how to handle them. Autonomous per-task commits must not absorb unrelated local work, or the clean-rollback guarantee breaks. 3. **Decide whether to decompose or resume.** `.tasks/plan.md` is self-describing — read its frontmatter and classify: | State | Action | | --- | --- | | No `.tasks/plan.md` | **Decompose** | | Every task already complete | **Decompose** — archive the finished plan first | | A `spec_sources` hash no longer matches the file on disk | **Stale** | | `base_commit` is not an ancestor of the current `HEAD` | **Stale** | | Otherwise, tasks remain | **Resume** | Verify `spec_sources` with `sha256sum` (or `shasum -a 256`) and `base_commit` with `git merge-base --is-ancestor HEAD`. **When stale, stop and ask the user.** Report which check failed and what changed — a spec was edited, or the branch moved. Offer to discard the plan and decompose afresh, or to keep it and resume anyway. Do not decide this alone: both causes are deliberate human actions, and silently discarding a plan throws away in-progress work. Say how bad it is, so the choice is an informed one. A split spec makes this precise: - **A `requirements.md` changed** — the acceptance criteria the tasks were written against no longer hold. Completed tasks may have built the wrong thing. Recommend discarding. - **Only a `design.md` changed** — the target behaviour is intact and completed tasks still stand; the change bears on how the remaining ones are implemented. Recommend resuming, and re-read the design before the next task. - **A single-file spec changed** — the two cannot be told apart. Diff it against the commit the plan was cut at and say which sections moved. 4. **Decompose (when the classification says so).** Break the spec into small vertically-sliced tasks with acceptance criteria and dependency ordering, and add checkpoints between phases listing only machine-checkable verifications. Write `.tasks/plan.md` and `.tasks/todo.md`, and add `.tasks/` to `.gitignore` if it is not there already. `.tasks/plan.md` starts with frontmatter recording what the plan was derived from: ```yaml --- feature: spec_sources: - path: spec/.md # or both halves of a split spec, sha256: # listed separately so a design-only # change is distinguishable base_commit: created_at: --- ``` **Go straight to execution — do not ask the user to review the breakdown.** Invoking `/build` is itself the approval. 5. **Execute every task in dependency order.** Use each task's declared dependencies; if they aren't explicit, execute in the order the plan lists them. For each task: 1. Delegate its implementation to a **subagent running the lower cost model** (Agent tool on Claude with `model: "sonnet"`; Codex with `model: "gpt-5.6-terra"`; Task tool on Cursor with a Composer `model` slug from that host's list) — pass it the task, its acceptance criteria, and the RED → GREEN → regression → build loop to run. 2. Invoke the `vibe-spec:code-review-and-quality` skill and review the task's changes across its five axes, categorizing findings as Critical, Important, or Suggestion. Delegate Critical and Important fixes to a subagent on that same lower-cost family; carry Suggestions to the final summary. 3. Stage only the files that task touched — never `git add -A` blindly — and make one commit per task so any point is a clean rollback. 4. Mark the task complete in `.tasks/todo.md` and record the commit SHA next to it. The SHAs let a later run reconstruct real progress from `git log` instead of trusting the file. 6. **Stop and ask the user** (do not push through) when: - a test can't be made to pass or the build breaks without an obvious fix → follow vibe-spec:debugging-and-error-recovery - the spec is ambiguous, or a task needs a decision the spec doesn't cover - a task is high-risk or irreversible — auth/permission changes, destructive data migrations, payments, deletions, deploys, anything touching secrets, **or anything you can't undo with `git revert`** → follow vibe-spec:doubt-driven-development and get explicit sign-off before continuing After the user resolves a blocker, they re-invoke `/build` — step 3 classifies it as a resume and it continues from the next pending task. 7. **Archive on completion.** Once every task is done, move `.tasks/plan.md` and `.tasks/todo.md` into `.tasks/archive/-/`, keeping both filenames. A plan left directly in `.tasks/` therefore always means unfinished work, which is what makes step 3's classification trustworthy. 8. **Summarize at the end:** tasks completed, tests added, commits made, and anything skipped, flagged, or Suggestions left for the user. If any step fails, follow the `vibe-spec:debugging-and-error-recovery` skill.