- Add grill: calibrated plan stress-testing before speccing - Add spec: sole mutator of SPEC.md with format specification - Add caveman: token-compression dialect for invariants and tasks - Add review: adversarial pre-implementation refutation of spec - Add build: single-threaded plan-to-execute loop with external oracles - Add check: read-only drift detector comparing code vs invariants - Add backprop: bug-to-spec feedback loop binding regression tests - Add deepen: complexity reduction and interface shrinking pass - Format all skills to 5-phase Skill Architect anatomy with System One balance - Synchronize symlinks across OpenCode, Codex, and Claude Code
78 lines
2.9 KiB
Markdown
78 lines
2.9 KiB
Markdown
---
|
|
name: build
|
|
description: >
|
|
Plan-then-execute implementation loop against SPEC.md tasks. Operates single-threaded on main agent thread.
|
|
Executes tasks in order, runs verification tests as external oracles, and triggers backprop on failure.
|
|
Use when asked to "build", "implement spec", "build §T.n", "build next task", or "run the build".
|
|
concerns: [system-one-balance]
|
|
---
|
|
|
|
# Build — Implement Spec
|
|
|
|
Single-threaded native plan → execute loop against `SPEC.md`.
|
|
|
|
---
|
|
|
|
## Phase 0: Setup and Protocols
|
|
|
|
1. **Verify Prerequisites**:
|
|
- `SPEC.md` must exist at the project root. If absent, defer to `spec` to author it first.
|
|
- Read §R if present: external facts the build must honor, never contradict or re-derive.
|
|
- For high-blast-radius changes (shared modules, auth, payments, database migrations), confirm `/review` has run.
|
|
|
|
---
|
|
|
|
## Phase 1: Ingest and Check
|
|
|
|
1. Parse invocation arguments:
|
|
- `§T.n`: Target specific task row.
|
|
- `--next`: Target the lowest-numbered row with status `.` or `~`.
|
|
- `--all` (or empty): Execute every pending `.` row in sequential order.
|
|
2. Confirm verification oracle:
|
|
- Identify the exact automated command (e.g. `pytest`, `cargo test`, `npm test`) that verifies completion.
|
|
|
|
---
|
|
|
|
## Phase 2: Processing (Core Logic)
|
|
|
|
### Step 1: Plan Task Implementation
|
|
For the chosen task(s):
|
|
1. Cite every §V invariant that applies; the implementation must satisfy all.
|
|
2. Cite every §I interface touched; preserve specified signatures and shapes.
|
|
3. List files to create or modify.
|
|
4. Establish the verification contract: specify which concrete test will prove each §V touched.
|
|
|
|
### Step 2: Sequential Execution
|
|
For each task in order:
|
|
1. Flip `§T.n` status cell from `.` → `~` in `SPEC.md`.
|
|
2. Edit code according to plan.
|
|
3. Run the verification command.
|
|
4. **Pass**: Flip `~` → `x` in `SPEC.md`. Create atomic commit: `T<n>: <task description>`.
|
|
5. **Fail**: Do NOT retry blindly; route to Failure Recovery.
|
|
|
|
### Step 3: Failure Recovery & Backprop
|
|
When a verification test fails:
|
|
1. Inspect failure output.
|
|
2. Determine failure classification:
|
|
- **Code defect in task**: Fix code and re-test.
|
|
- **Spec defect or unhandled edge case**: Invoke `backprop` with `bug: <cause>` to record in §B and draft §V before resuming.
|
|
|
|
---
|
|
|
|
## Phase 3: The System One Balance Pass
|
|
|
|
- **Augment, Don't Handcuff**:
|
|
- Keep execution single-threaded on the main agent; avoid uncoordinated background subagent sprawl.
|
|
- Flip only §T status cells in `SPEC.md` during build; leave architectural changes to `spec`.
|
|
- Avoid speculative work beyond the assigned task.
|
|
|
|
---
|
|
|
|
## Phase 4: Output Execution & Verification
|
|
|
|
A task is verified as complete (`x`) only when:
|
|
1. The verification command exits with code 0.
|
|
2. Every §V touched has an automated passing test.
|
|
3. Full test suite passes with zero regressions.
|
|
4. `SPEC.md` reflects current completion state.
|