Spec Build

---
name: spec-build
description: Work through an already-planned spec feature by delivering the tasks in specs/NNN_feature_slug/tasks/ one at a time, verifying each independently. Use ONLY when such a tasks/ directory exists and the user is executing it; for ad-hoc, one-off, or any non-spec code change use the build skill instead. Composes the build skill for commands and conventions. Step 3 of the spec-driven workflow.
---

# spec-build

Drives spec-driven, per-task delivery. This is step 3 of the workflow: `spec-ideate` → `spec-tasks` → `spec-build`.

## When to use

**Only** when a `specs/NNN_feature_slug/tasks/` directory already exists (produced by `spec-tasks`) and the user is
working through that task list — delivering the tasks one at a time so each can be verified independently. For any other
code change — ad-hoc fixes, upgrades, one-off implementation not tied to a spec — use the `build` skill instead.

## Follow the `build` skill

For all repo commands (test / lint / format / build / run) and coding conventions, use the **`build`** skill — this
skill does not restate them. `build` is the general reference; `spec-build` only adds the preflight and per-task
delivery loop below.

## Preflight the task against the code

Task files are written at planning time — potentially long before execution, and without opening the code. Their bullets
carry rationales ("it currently does X", "so that Y doesn't happen"), and the code moves underneath them. **Before
writing any code**, test the premises the task file asserts:

- **Claims about this repo's current state.** Open every file the `Changes` section names and confirm the described
  current behaviour is actually there.
- **Claims about third-party behaviour** — Anchor, GitHub Actions, Terraform, AWS semantics. Verify against the tool's
  documentation or a local command, **never from memory**. This is where a rationale is most often wrong and least
  likely to be noticed, because the code alone cannot falsify it.
- **Preconditions.** Every task in `Depends on` is `Status: Done`, the named paths exist, and no earlier task has
  already delivered part of the scope.
- **Test doubles.** The `Verification (QA)` section must agree with the `build` skill's testing conventions: the chain
  is exercised against the local validator, only AWS SDK clients are mocked. A task that proposes mocking an RPC client
  or a `solana_*_interface` fragment is a **material** finding — do not build it that way.

Apply the `grilling` skill's dividing line: **facts** are yours to look up, **decisions** are the user's. The preflight
tests falsifiable premises only.

### Reporting findings

- **Material** — the flaw would change what gets built. Stop before implementing. Report the premise as written, the
  evidence contradicting it, and a recommended alternative, then wait for the user's ruling.
- **Non-material** — stale wording, a path that moved, cosmetics. Note it, proceed, and mention it in the handback.

Where the ruling deviates from the task file, amend that file in the same change: strike the bullet through and state
what was done instead and why. A task marked `Done` must not still assert something known to be false.

## Per-task delivery loop

Deliver **one task at a time** and let the user verify each independently:

1. Pick the next unchecked task from `specs/NNN_feature_slug/tasks/README.md`.
2. **Preflight it against the code** (see above). Stop here if it turns up a material flaw.
3. Work directly on `main` — no feature branch (solo portfolio repo).
4. Implement **only that task's scope**, following the `build` skill's commands and conventions.
5. Run the task's QA (tests / lint / format / typecheck for the languages touched — see the `build` skill). Tests that
   need the local validator cannot run from the agent sandbox: run the static checks, then hand the test command to the
   user and say so in the handback rather than reporting the tests as passing.
6. Tick the task off in `tasks/README.md` and set its `Status: Done`. If the preflight changed the plan, amend the task
   file in the same change to record what was done instead and why.
7. **Stop and hand back with the changes left unstaged**, listing any non-blocking preflight findings alongside the
   diff. Do not commit or push. The user reviews the diff, then commits/pushes and verifies independently. Only continue
   to the next task on the user's explicit go-ahead.

## Out of scope

- Restating build/QA commands or conventions — those live in the `build` skill.
- Re-grilling `requirements.md` or reopening settled design decisions — the preflight tests falsifiable premises, it is
  not a re-plan.
- No feature branches, **no staging or committing**, no pushing, no PR creation.
- No batching multiple tasks in one go — wait for the user's go-ahead between tasks.