ds-build

/ds-build

A plan is not progress. Handing an AI a task list produces half-implemented units, "done" claims with no signal behind them, and a tree nobody can bisect. This skill takes a source of work — a GitHub issue, a specs/{feature}/tasks.md, or a plain request — and executes it one bounded unit at a time, each proven by its own verify command before the next starts, then closes the record with the evidence.

Plan Executor — intake → re-verify → impact map → bounded units → red proof → aggregate gate → code-proven close.

Completion Evidence — applies to every phase: Report done/OK only with the machine-checkable evidence the gates name — the exact command run and its observed output (or file:line diff). Missing evidence → report INCOMPLETE plus what is missing. Self-assessment is never evidence. (This band repeats at file end by design — both copies are normative.)

Triggers

• User runs /ds-build
• User says "implement this plan", "execute the tasks", "do issue #N", "build the feature in the spec"
• A specs/{feature}/tasks.md with unchecked tasks exists and the user asks to proceed
• /ds-issue --do, ds-pipeline (after tasks are generated) or ds-freeze (kept set) hand execution here

Triggers — INVOKE / DON'T INVOKE

INVOKE	DON'T INVOKE
"execute specs/001-x/tasks.md", "implement the plan"	"turn this idea into a plan" (→ ds-pipeline)
"do issue #42 end to end"	"file an issue for this" (→ ds-issue intake)
"build the kept set from the freeze"	"decide what ships now vs later" (→ ds-freeze)
"this bug — reproduce and fix it" → only when the fix is planned; otherwise	"find why this fails" (→ ds-debug)
"add the feature described in the request"	"write tests for X" alone (→ ds-test)

Contract

Dimensions: none (carrier)

• Executes work; never plans a feature from scratch (a plain request is normalized into a one-line goal + files + done criteria, not a spec) and never decides scope (that is ds-freeze's job).
• Standalone. Sources: a GitHub issue (via gh), a specs/{feature}/tasks.md, or the request text. The shared loop it runs is ../core/execution-loop.md; this file adds only the executor-specific rules.
• Full accounting enforced: every finding and planned check ends in an explicit disposition (fixed / skipped + reason / only you can do); summary totals balance.
• Pre-existing / out-of-scope errors detected during work are NOT skipped — fixed inline or escalated with concrete blocker.
• Every unit has a signal. A task without a runnable verify command gets one before any edit (stack-native check from ../core/toolchains.md, a test, or an observable effect); "looks right" is not a signal.
• Checkpoint (../core/checkpoint-protocol.md): git status --porcelain before the first write; a dirty path the plan would touch → that unit is only you can do (commit or stash first); disjoint dirt is listed and left alone. Failed units are reverted file-by-file (git checkout -- {files}), never with a tree-wide reset.
• Mechanical Done Gate: {check-cmd} resolved at setup (priority: ds-quality enforcement arm, profile Toolchain:, stack-native format → lint → type → test), baseline captured, re-run after every unit and once in aggregate before close; new red → fix ≤ 3 attempts with the same command, then revert the unit and record reverted; baseline red reported red-at-baseline; no tooling → Verification-Infrastructure Gap surfaced, never skipped.
• Budgeted backtracking: ≤ 3 fix attempts per approach, ≤ 3 approaches per unit; every failed attempt records {approach} failed because {root cause}; all approaches exhausted → unit blocked with the recorded causes, dependent units re-planned, never a fourth identical retry.
• Publishing is never done here: commits are local; push, PR, tag, release, deploy are on the exception list (../core/ask-exception-list.md) and reported only you can do with the exact command.
• State-exempt: the record (issue body, tasks.md ticks, commits) is durable outside the run; a resumed run re-reads it.