1.7 KiB
1.7 KiB
name, description, scope
| name | description | scope |
|---|---|---|
| build | 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. | 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.
- 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.
- Select the named task, the first pending/in-progress task for
--next, or all unfinished tasks for--allor a request to implement the whole spec. - 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.
- Mark the selected task
~, implement it, and verify the requested behavior. Mark itxonly when the evidence supports completion. Leave incomplete tasks unfinished and explain any limitations. - On failure, inspect the cause before changing anything else. Fix task defects
directly. Use
backpropfor 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.