feat: refresh shared skills catalog

skills/build/SKILL.md

@@ -1,77 +1,31 @@
 ---
 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]
+  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 — Implement Spec
+# Build spec tasks
 
-Single-threaded native plan → execute loop against `SPEC.md`.
+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.
 
-## 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.
+`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.