$npx -y skills add MageByte-Zero/spec-superflow --skill build-executorGovern implementation from an approved execution contract. Invoke when execution-contract.md is approved and the user wants disciplined build work, TDD execution, or guarded batch-by-batch implementation.
| 1 | # Build Executor |
| 2 | |
| 3 | Controls the implementation phase. Uses `execution-contract.md` as the workflow authority. |
| 4 | |
| 5 | ## Required Inputs |
| 6 | |
| 7 | Read: `execution-contract.md`, `tasks.md`, relevant `specs/`, relevant `design.md`. (Skip contract/spec requirements when workflow is `tweak`.) |
| 8 | |
| 9 | Check workflow mode first: `npx --yes --package spec-superflow@0.11.0 ssf state get <change-dir> workflow`. If `tweak` → direct edit mode. If `hotfix` or `full` → standard contract-first discipline. |
| 10 | |
| 11 | Branch/worktree preflight before ANY implementation edit (mandatory — do not skip): |
| 12 | 1. Run the isolation check: |
| 13 | ```bash |
| 14 | npx --yes --package spec-superflow@0.11.0 ssf isolate <change-dir> |
| 15 | ``` |
| 16 | This script enforces git isolation: if you are on `main`/`master` it creates a |
| 17 | git worktree (preferred) or a new branch, and exits non-zero if it cannot and you |
| 18 | have not approved `--force`. |
| 19 | 2. If `npx --yes --package spec-superflow@0.11.0 ssf isolate` exits non-zero: STOP. Do not edit `main`/`master` in place. |
| 20 | Ask the user for explicit approval (and re-run with `npx --yes --package spec-superflow@0.11.0 ssf isolate <change-dir> --force` |
| 21 | only after they approve). |
| 22 | 3. If it succeeds, report the chosen branch/worktree and make all implementation |
| 23 | edits there. |
| 24 | |
| 25 | ## Core Laws |
| 26 | |
| 27 | ### Law 1: Contract First |
| 28 | The execution contract is the approved handoff artifact, not chat history. |
| 29 | |
| 30 | ### Law 2: TDD Iron Law — No Production Code Without a Failing Test First |
| 31 | RED (write test, see it fail) → GREEN (write minimal code, see it pass) → REFACTOR (clean up, suite stays green). |
| 32 | |
| 33 | **Red Flags**: "Quick implementation first, test later" / "Skip the test, manually verify" / "I already know it works" / "Just this one time without tests." ALL mean STOP and write the test first. |
| 34 | |
| 35 | ### Law 3: Review Before Drift |
| 36 | Block on: logic defects, spec violations, missing required tests, unintended scope expansion. |
| 37 | |
| 38 | ### Law 4: Rewind on Contract Break |
| 39 | Return to `specifying` or `bridging` if: new behavior appears, interfaces change materially, design assumptions fail, artifacts no longer define intended implementation. |
| 40 | |
| 41 | ## Execution Mode Selection |
| 42 | |
| 43 | For `full`/`hotfix`, generate proposed waves from the approved contract, then use the recommendation as a decision aid rather than silently defaulting a mode: |
| 44 | |
| 45 | ```bash |
| 46 | npx --yes --package spec-superflow@0.11.0 ssf execution recommend <change-dir> \ |
| 47 | --wave <wave-id>:<parallel|serial>:<task,...>[:<depends-on,...>] --json |
| 48 | # Show every available mode, the observed facts, and the recommendation to the user. |
| 49 | # The command writes a receipt tied to the artifacts, contract, and waves. After the user chooses, record that explicit confirmation: |
| 50 | npx --yes --package spec-superflow@0.11.0 ssf execution plan <change-dir> \ |
| 51 | --mode <selected-mode> --confirm --reason "user-selected execution mode" \ |
| 52 | --wave <wave-id>:<parallel|serial>:<task,...>[:<depends-on,...>] |
| 53 | # Add --acknowledge-recommendation when the selection differs from the recommendation. |
| 54 | npx --yes --package spec-superflow@0.11.0 ssf execution show <change-dir> --json |
| 55 | ``` |
| 56 | |
| 57 | The optional fourth `--wave` segment names prerequisite wave IDs. `execution show --json` reports `current`, plus each wave's `depends_on`, `receipt`, `blockers`, `retryable`, and `eligible` status. A wave with `retryable: true` has a current `fail` receipt and is eligible only for its focused repair and re-review; its dependents remain blocked until its replacement `pass` receipt. Report the saved plan revision, selected mode, ordered waves, dependencies, and whether every `parallel` wave can actually be dispatched concurrently on the current platform. If concurrency is unavailable, state the capability and reason plainly; retain the planned `parallel` strategy and do not silently execute it as a serial or Batch Inline plan. |
| 58 | |
| 59 | The recommendation uses task count, configured `execution.inlineThreshold`, and declared wave strategy. It never auto-selects: present every available mode and the recommendation to the user. `--confirm` records any user-selected mode; a choice that differs from the recommendation requires `--acknowledge-recommendation` so the plan captures an informed risk decision. |
| 60 | |
| 61 | | Mode | Criteria | |
| 62 | |------|----------| |
| 63 | | **SDD** | Recommended for parallel waves, multiple waves, or work beyond the inline threshold | |
| 64 | | **Inline** | Recommended for a single sequential task; always available for a user-confirmed choice | |
| 65 | | **Batch Inline** | Recommended for a bounded sequential batch; it remains serial and is never presented as parallel | |
| 66 | |
| 67 | Do not transition to `executing` until `execution show` reports `current: true` and the phase guard passes. A revised plan must repeat `npx --yes --package spec-superflow@0.11.0 ssf execution recommend` and use `npx --yes --pa |