---
name: build
description: >
  Implement tasks from an existing SPEC.md when asked to implement the spec, build a named spec task, or continue the spec workflow. Ordinary compiler/build commands do not activate this skill.
scope: global
---

# Build spec tasks

Use this workflow only when the project has adopted `SPEC.md`. An ordinary feature
or bug fix does not require creating one. Follow [shared verification](../../protocols/workflow.md#verification).

1. Read the selected tasks and their relevant constraints, interfaces, invariants,
   and research. Treat sourced findings as evidence; recheck them if stale or
   contradicted by current code.
2. Select the named task, the first pending/in-progress task for `--next`, or all
   unfinished tasks for `--all` or a request to implement the whole spec.
3. Inspect touched code and choose a concrete completion check. For changes to
   auth, payments, shared contracts, or migrations, inspect the risks and existing
   review findings; perform a focused review yourself if needed without making
   the user launch another skill.
4. Mark the selected task `~`, implement it, and verify the requested behavior.
   Mark it `x` only when the evidence supports completion. Leave incomplete tasks
   unfinished and explain any limitations.
5. On failure, inspect the cause before changing anything else. Fix task defects
   directly. Use `backprop` for a meaningful spec gap or recurring behavioral bug;
   do not create invariants for ordinary intermediate mistakes.

`build` owns task status cells. Architectural or scope changes belong to `spec`;
perform a targeted amendment within the authorized task when required. Continue
in task order; do not impose commits or a full-suite run after every row.