32 lines
1.7 KiB
Markdown
32 lines
1.7 KiB
Markdown
---
|
|
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.
|