@loneexile/omp-superpowers 7.0.0-omp.2 → 7.0.0-omp.3

package/CHANGELOG.md

@@ -6,6 +6,19 @@ A version is `<upstream version>-omp.<n>`: the upstream release this fork is syn
 
 ## [Unreleased]
 
+## [7.0.0-omp.3] - 2026-10-16
+
+### Changed
+
+- **A small change no longer goes through the full process.** brainstorming's small-change row said "build it through the normal workflow", which left it to a plan and a subagent run. It now has its own path: after the in-chat approval the session builds it itself, test first, runs the covering tests and the suite once, and commits once, with no design document, plan or subagents. A new behavior such as a `--quiet` flag can be small. Security, auth, concurrency, money, migrations, changes one revert cannot undo, new config files or stored formats, changes to existing behavior (defaults, exit codes, error handling, what happens with no input), new interfaces other code builds on and new dependencies never are: in a live run before that list was written, a request for a `--format` flag and a `~/.wcrc` config file was sized small and committed with no design, and the commit also changed what the tool does with no input. In a measured herdr-tunnel feature (2026-09-21), the brainstorm, plan and finish phases took 1h41m of its 3h52m agent time.
+- **One approval for design, plan and method.** A playback no longer waits for its own answer; it rides along with the next question. For software, the plan is written right after the builder check, and writing-plans asks once for approval of the design, the plan, the execution method and the workspace (a new branch in this checkout by default, so no `/move`), picking the method itself and naming its reason instead of asking the partner to choose. In the same feature, 16h55m of 20h48m wall clock was waiting for the partner's reply across the brainstorm, plan and finish prompts; this removes some of those prompts, not the time a partner takes to answer the rest. The combined plan-review and method prompt alone waited 1h42m.
+- **subagent-driven-development reviews per task only where risk earns it, and runs independent tasks in parallel.** writing-plans marks security, auth, concurrency, migration or persisted-format, money and destructive tasks `**Review:** per-task`, and a plan with such a mark runs subagent-driven unless the partner says otherwise. The controller's pre-flight scan turns the marks into a review list and the scan table into waves: tasks with no shared file or interface (lockfiles, manifests and test-time ports count as shared) run in parallel, up to three, each in its own `omp worktree add` worktree. Every dispatch for a wave task, reviewers included, names its worktree. A wave task's covering tests run on the merged tree before the merge commits (`git merge --no-ff --no-commit`), a failure goes back to its implementer as a counted round, and the full suite runs once after each wave. A task reviewed at final gets the controller's own run of its covering tests instead of a task reviewer, and `sdd-final-reviewer` does the task review's work on it, and on any rebased or wave-fix code, before the seams. 6.4.2-omp.3 removed parallel waves because they rode on `task.isolation`, whose patch merge leaves no commits and whose agents cannot be resumed; these waves use git worktrees and keep both. Across six measured SDD runs, task reviews and re-reviews took 2h28m and final reviews 1h24m, against 7h06m of implementation, and every task ran in sequence.
+- **`sdd-final-reviewer` always reports crashes and lost data.** A crash (an uncaught exception, a traceback) or lost data on input a user can give is a finding, never a "Declined to judge" line, whatever the plan or spec says about that input. In a live SDD run on a three-task plan, the final reviewer listed a traceback on a bad `--larger-than` value under "Declined to judge", and the branch kept it; per-task reviews now cover fewer tasks, so the final review is where such a crash gets caught.
+
+### Fixed
+
+- **The `task.isolation` notes match omp 18.11.0.** They said isolated work always returns as an uncommitted patch and an isolated agent cannot be messaged. Measured in two scratch runs on 18.11.0 (the bundled `task` agent, and an `sdd-implementer` seat on cursor-sdk): `merge: branch` keeps a subagent's commits and cherry-picks them onto the parent branch as it finishes, under new ids, and deletes the task branch; a same-file conflict leaves `omp/task/<id>` behind. A `write agent://<id>` to an isolated agent answers `Delivered` although its result says it "cannot be resumed or messaged", and the fix it then committed never reached the parent branch while the session ran; after the session ended it sat on a leftover `omp/task/<id>` branch that also repeated the already-merged commit. `pi-tools.md` now says never to send an isolated subagent a follow-up, and how to recover one that went out (cherry-pick only its new commits). SDD still uses its own worktrees, because its fix rounds resume the implementer.
+
 ## [7.0.0-omp.2] - 2026-10-11
 
 ### Changed
@@ -90,7 +103,8 @@ First release, synced to upstream [v6.4.2](https://github.com/obra/superpowers/b
 - The fork's rewritten subagent-driven-development text invokes its helper scripts through `bash` as well, so a package extractor that drops exec bits cannot break them.
 - `sdd-final-reviewer` carries upstream's new review rules from `code-reviewer.md`, the template it replaces in SDD's final review: the spec is a vision document (behavior it is silent on is graded by what a reasonable person expects), and a "Declined to judge" section that the controller rules on and ledgers like a plan conflict.
 
-[Unreleased]: https://github.com/LoneExile/omp-superpowers/compare/v7.0.0-omp.2...HEAD
+[Unreleased]: https://github.com/LoneExile/omp-superpowers/compare/v7.0.0-omp.3...HEAD
+[7.0.0-omp.3]: https://github.com/LoneExile/omp-superpowers/releases/tag/v7.0.0-omp.3
 [7.0.0-omp.2]: https://github.com/LoneExile/omp-superpowers/releases/tag/v7.0.0-omp.2
 [7.0.0-omp.1]: https://github.com/LoneExile/omp-superpowers/releases/tag/v7.0.0-omp.1
 [6.4.2-omp.4]: https://github.com/LoneExile/omp-superpowers/releases/tag/v6.4.2-omp.4

package/README.md

@@ -8,7 +8,8 @@ This fork keeps the skills and fixes the omp side:
 
 - the injected tool mapping tells the truth about `task`, `todo`, `read`/`grep`/`glob`
 - **five omp agents** (`agents/sdd-*.md`) give every subagent-driven-development seat its own model, thinking level, and tool set
-- subagent-driven-development is rewritten around them: three-round fix loop, structured reviewer output, implementers one at a time
+- subagent-driven-development is rewritten around them: three-round fix loop, structured reviewer output, independent tasks in parallel worktrees, a task review only where a task's risk earns it
+- a small change skips the design document, plan and subagents, and a project asks for one approval of design, plan and execution method together
 
 ## Install
 
@@ -41,9 +42,9 @@ Agent definitions are read **per dispatch**, so a reinstall takes effect on the
 
 The skills drive themselves once loaded. The usual path:
 
-1. `read skill://brainstorming` — turn an idea into a design
-2. `read skill://writing-plans` — produce `docs/plans/<date>-<name>.md`
-3. `read skill://subagent-driven-development` — execute the plan task by task via subagents. If you choose Native at the plan handoff, `executing-plans` runs instead: the session does every task itself, and only the final review is a subagent (`sdd-final-reviewer`)
+1. `read skill://brainstorming` — turn an idea into a design. A small change stops here: after you approve it in chat, the session builds it itself, test first, and commits once
+2. `read skill://writing-plans` — produce `docs/plans/<date>-<name>.md`, pick the execution method, and ask once for approval of the design, the plan and the method together
+3. `read skill://subagent-driven-development` — execute the plan via subagents, independent tasks in parallel. If you swap to Native in that approval, `executing-plans` runs instead: the session does every task itself, and only the final review is a subagent (`sdd-final-reviewer`)
 4. `read skill://finishing-a-development-branch` — merge / PR / discard
 
 On omp the agent invokes a skill by reading it (`read skill://<name>`); you can also invoke one explicitly with `/skill:<name>`.
@@ -54,10 +55,15 @@ On omp the agent invokes a skill by reading it (`read skill://<name>`); you can
 
 ```mermaid
 flowchart TD
-    B["task-brief: one task's text from the plan"] --> I
-    I["sdd-implementer: TDD, commit, report file"] --> P["review-package: git diff -U10 to a file"]
+    S["pre-flight scan: review list + waves"] --> B
+    B["task-brief: one task's text from the plan; a wave of 2+ gets a worktree per task"] --> I
+    I["sdd-implementer: TDD, commit, report file"] --> L{"on the review list?"}
+    L -->|"no: review at final"| T["controller runs the covering tests"]
+    T -->|"pass"| D
+    T -->|"fail: fix round"| I
+    L -->|"yes: risk class"| P["review-package: git diff -U10 to a file"]
     P --> R["sdd-reviewer: spec + quality, structured result"]
-    R -->|"approved"| D["ledger: Task N complete"]
+    R -->|"approved"| D["merge the task branch; ledger: Task N complete"]
     R -->|"Critical or Important findings"| F
     F["fix round 1 or 2: resume sdd-implementer"] --> RR["sdd-rereviewer: verdict per finding"]
     RR -->|"all addressed"| D
@@ -65,9 +71,9 @@ flowchart TD
     E --> RR
     RR -->|"still open after round 3"| A["controller adjudicates and parks with a ruling"]
     A --> D
-    D --> N{"more tasks?"}
+    D --> N{"more waves?"}
     N -->|"yes"| B
-    N -->|"no"| W["sdd-final-reviewer: whole-branch, once per plan"]
+    N -->|"no"| W["sdd-final-reviewer: whole-branch, once per plan; does the task review's work for review-at-final tasks"]
     W --> X["finishing-a-development-branch"]
 
     classDef seat fill:#1e3a8a,stroke:#3b82f6,color:#dbeafe
@@ -144,7 +150,7 @@ Rules that are easy to get wrong:
 
 | setting | why |
 |---|---|
-| `task.isolation.enabled` (+ `isolation.backend`, default `auto`) | off by default. SDD does not use it: implementers run one at a time, because isolated work returns as an applied patch with no per-task commits, and an isolated subagent cannot be messaged for fix rounds. Older omp builds spelled this `task.isolation.mode`; check `omp config get task.isolation.enabled` on your build |
+| `task.isolation.enabled` (+ `isolation.backend`, default `auto`) | off by default. SDD does not use it. Under the default `merge: patch` isolated work returns as an uncommitted patch; `merge: branch` keeps commits but applies them as each task ends, before review, under new ids. Either way, an isolated subagent cannot take a fix round: on omp 18.11.0 a message to one is delivered, but its fix never reaches your branch while the session runs. Parallel tasks get their own `omp worktree add` worktrees instead. Older omp builds spelled this `task.isolation.mode`; check `omp config get task.isolation.enabled` on your build |
 | `task.enableEffort` | exposes per-dispatch `effort` (`"lo"`, `"med"`, `"hi"`); `"hi"` maps to the model's top supported level, capped by `task.maxEffort`. SDD uses `effort: "hi"` for high-risk task reviews, and for escalation only when a host override lowers that seat |
 | `task.showResolvedModelBadge` (default off) | shows the model each subagent actually ran. A seat whose pinned provider has no credentials silently runs on another model |
 | `task.enableLsp`, `astGrep.enabled` (both default off) | omp only activates `lsp` and `ast_grep` in subagents when these are on |
@@ -155,11 +161,12 @@ Rules that are easy to get wrong:
 - `.pi/extensions/superpowers.ts` — the injected mapping names `task`, `todo`, the `sdd-*` roster, and the no-`model:`-field rule; it also re-arms on `session_switch`, skips subagent sessions, and ignores an `agent_end` that will auto-continue; it tells a dispatching session to name the checks each subagent must run, since omp 18.4.12 tells subagents to leave builds, tests and smoke runs to the main agent unless their assignment explicitly instructs them; its last paragraph points a vibe-mode director (tools include `vibe_spawn` but not `task`) at the *Vibe mode* section of `pi-tools.md`
 - `.omp-plugin/plugin.json` — new. Marks the repo root as an omp-native plugin so a marketplace or `--plugin-dir` install keeps each agent's `model:` line
 - `skills/using-superpowers/references/pi-tools.md` — same, as the reference doc; it also gains a *Checks* subsection (the 18.4.12 subagent hand-off rule, and why every dispatch names its checks) and a *Vibe mode* section: what a director keeps and lacks, how skill actions map onto `vibe_*` and workers, and the worktree and request-budget limits
-- `agents/sdd-*.md` — new. Each seat's `model:` is a pin plus a role fallback (`@task` or `@slow`), and all set `readSummarize: false`. `sdd-final-reviewer` reviews the whole branch for both ways of running a plan. It reads `requesting-code-review/code-reviewer.md` at run time and applies its What to Check, Calibration, severity definitions and Critical Rules, while carrying upstream's vision-document and Declined-to-judge rules in its own body. Descriptions name roles, never models
-- `skills/subagent-driven-development/` — *Model Selection* → *Agent Selection*; fix-loop cap 5 → 3 with a round-3 escalation seat; a proven-trivial-fix route that replaces a re-review with a one-command proof; implementers run one at a time; the scripts directory resolves via `realpath skill://subagent-driven-development/scripts`; fix rounds resume the implementer with `write agent://<id>` (id ledgered) and full results are read at `agent://<id>`; task review scales with risk through `effort: "hi"`; the controller checks reviewer results; templates show omp's real `{ context, tasks: [{ agent, task, solutionSpace }] }` wire shape and the reviewers' structured fields; one omp paragraph for vibe mode, where a director (no `task` or `bash`) hands the whole run to one `good` worker that dispatches the seats itself
+- `skills/brainstorming/` — a defined small-change path: after the in-chat approval the session builds it itself, test first, runs the covering tests and the suite once, and commits once, with no design document, plan or subagents (a new behavior such as a `--quiet` flag can be small; security, auth, concurrency, money, migrations, changes one revert cannot undo, new config files or stored formats, changes to existing behavior, new interfaces other code builds on and new dependencies never are); a playback rides along with the next question instead of waiting for its own answer; for software, the plan is written right after the builder check so the design and the plan get one approval
+- `agents/sdd-*.md` — new. Each seat's `model:` is a pin plus a role fallback (`@task` or `@slow`), and all set `readSummarize: false`. `sdd-final-reviewer` reviews the whole branch for both ways of running a plan; after subagent-driven-development it does the task review's work on every task left to it (`review at final`) before the seams. It reads `requesting-code-review/code-reviewer.md` at run time and applies its What to Check, Calibration, severity definitions and Critical Rules, while carrying upstream's vision-document and Declined-to-judge rules in its own body; a crash or lost data on user input is always a finding, never a Declined-to-judge line. Descriptions name roles, never models
+- `skills/subagent-driven-development/` — *Model Selection* → *Agent Selection*; fix-loop cap 5 → 3 with a round-3 escalation seat; a proven-trivial-fix route that replaces a re-review with a one-command proof; the pre-flight scan builds a review list (plan-marked or ruled high-risk tasks get a task review, the rest get the controller's own covering-test run and the final review) and waves (tasks with no shared file or interface run in parallel, up to three, each in its own `omp worktree add` worktree, merged back with `--no-ff`); the scripts directory resolves via `realpath skill://subagent-driven-development/scripts`; fix rounds resume the implementer with `write agent://<id>` (id ledgered) and full results are read at `agent://<id>`; task review scales with risk through `effort: "hi"`; the controller checks reviewer results; templates show omp's real `{ context, tasks: [{ agent, task, solutionSpace }] }` wire shape and the reviewers' structured fields; one omp paragraph for vibe mode, where a director (no `task` or `bash`) hands the whole run to one `good` worker that dispatches the seats itself
 - `skills/executing-plans/` — one additive omp paragraph in *Final Review*: the `task` tool has no `model:` field, so the final review goes to `sdd-final-reviewer` (its model is what the host maps that agent to), told that no task was reviewed; it also resolves the scripts directory with `realpath` and reads full results at `agent://<id>`; one more omp paragraph for vibe mode, where a director hands the whole run to one `good` worker
 - `skills/using-git-worktrees/` — additive omp section: `/wt` is the user's one-line answer to the consent question (moves the session, carries WIP); when the agent creates the worktree itself it uses `omp worktree add` under `~/.omp/wt/` (the only place `omp worktree list`/`clear` manage), knows that command leaves uncommitted changes behind, and asks for `/move <path>` because `cd` never moves the tools' cwd. Also: clone-first falls back to a plain checkout without `node_modules` (no copy-on-write, or in-repo targets); setup and tests use the bash tool's `cwd` parameter until `/move`; `omp worktree clear --all` is warned against, since it force-removes every worktree, uncommitted work included; omp's bash rewrites a literal `git worktree add` into `omp worktree add` only without shell expansion; vibe mode refuses `/move` and `/wt`, so the worktree and `/move` come before `/vibe`, or every worker brief carries the absolute path
-- `skills/writing-plans/` — one added line in *Execution Handoff*: in vibe mode both execution approaches run in one `good` worker the director briefs, not in its own session
+- `skills/writing-plans/` — *Execution Handoff* picks the method itself and asks for one approval of the design, the plan and the method; *Review Marks* (and a self-review check) mark security, auth, concurrency, migration, money and destructive tasks `**Review:** per-task`; tasks that share no file or interface can run in parallel; in vibe mode both execution approaches run in one `good` worker the director briefs, not in its own session
 - `README.md` — this file: rewritten for omp (install, seats, overrides, maintenance); upstream's multi-harness README is gone
 - `tests/pi/test-pi-extension.mjs` — covers the extension's lifecycle (bootstrap on start, `session_switch`, compaction; none for subagents or an auto-continuing `agent_end`), the action table in `pi-tools.md`, the seat table against the names in `agents/*.md`, and the `.omp-plugin/plugin.json` manifest; the package-name assertion is gone (`scripts/check-npm-package.sh` checks the published name)
 - `package.json` — the npm identity: `@loneexile/omp-superpowers`, `<upstream version>-omp.<n>` versions, a `files` allowlist (the extension, `skills/`, `agents/`), `publishConfig`, `omp`/`oh-my-pi` keywords; `main` is dropped, since it pointed at the OpenCode plugin this package does not ship
@@ -178,7 +185,7 @@ git rebase upstream/main
 git push --force-with-lease origin main
 ```
 
-Expect conflicts in `skills/subagent-driven-development/`, `pi-tools.md`, `README.md`, and `package.json` whenever upstream touches them — this fork rewrites those files rather than appending to them (README.md is never a partial conflict). In `package.json` keep the fork's identity and set `version` to `<new upstream version>-omp.1`: CI's package check fails until the version's base matches the upstream version in `.claude-plugin/plugin.json`. `agents/`, the extension's mapping paragraph, and the omp blocks in `using-git-worktrees` are additive.
+Expect conflicts in `skills/subagent-driven-development/`, `skills/brainstorming/`, `skills/writing-plans/`, `pi-tools.md`, `README.md`, and `package.json` whenever upstream touches them — this fork rewrites those files rather than appending to them (README.md is never a partial conflict). In `package.json` keep the fork's identity and set `version` to `<new upstream version>-omp.1`: CI's package check fails until the version's base matches the upstream version in `.claude-plugin/plugin.json`. `agents/`, the extension's mapping paragraph, and the omp blocks in `using-git-worktrees` are additive.
 
 A clean rebase is not the whole sync. Upstream's edits to text this fork replaced never reach the replacement, so read upstream's diff for those files and port what still applies. The v6.4.x sync needed two: `bash scripts/...` invocations in the SDD text, and `code-reviewer.md`'s new review rules. Upstream edits to `code-reviewer.md`'s What to Check, Calibration, severity definitions and Critical Rules now reach `sdd-final-reviewer` without porting, because it reads the file at run time. Edits to the vision-document or Declined-to-judge sections still need porting into the agent body, which carries them itself.
 
@@ -197,7 +204,7 @@ gh release create "v$v" --target main --title "v$v" --notes-file /tmp/notes.md
 
 ### New omp versions
 
-Before trusting a new omp release, re-check the harness facts this fork depends on — against the **running binary**, not an npm source tree that may lag it. `~/.bun/install/global/node_modules/@oh-my-pi/pi-coding-agent/src` routinely lags `omp --version` (a 17.4.2 tree sat beside an 18.1.17 binary while this README was written, and the isolation setting had been renamed in between). The fork was last verified against omp 18.4.10; its vibe-mode text and the subagent check rule were re-checked against 18.4.12. To read the exact running version's source, pack it into a temp dir: `cd "$(mktemp -d)" && npm pack @oh-my-pi/pi-coding-agent@$(omp --version | cut -d/ -f2) && tar xzf *.tgz` (source under `package/src`). The live oracles are `omp config list --json` (every setting and its default), the `task` tool's own description in a session (agent roster, item fields), a `session_init.resolvedModel` line in a subagent transcript (what actually resolved), and `grep -a` on the binary for an exact string when you need to know whether a code path exists.
+Before trusting a new omp release, re-check the harness facts this fork depends on — against the **running binary**, not an npm source tree that may lag it. `~/.bun/install/global/node_modules/@oh-my-pi/pi-coding-agent/src` routinely lags `omp --version` (a 17.4.2 tree sat beside an 18.1.17 binary while this README was written, and the isolation setting had been renamed in between). The fork was last verified against omp 18.4.10; its vibe-mode text and the subagent check rule were re-checked against 18.4.12, and the `task.isolation` notes against 18.11.0. To read the exact running version's source, pack it into a temp dir: `cd "$(mktemp -d)" && npm pack @oh-my-pi/pi-coding-agent@$(omp --version | cut -d/ -f2) && tar xzf *.tgz` (source under `package/src`). The live oracles are `omp config list --json` (every setting and its default), the `task` tool's own description in a session (agent roster, item fields), a `session_init.resolvedModel` line in a subagent transcript (what actually resolved), and `grep -a` on the binary for an exact string when you need to know whether a code path exists.
 
 ## License
 

package/agents/sdd-final-reviewer.md

@@ -1,6 +1,6 @@
 ---
 name: sdd-final-reviewer
-description: "Superpowers final whole-branch reviewer, dispatched once per plan: after subagent-driven-development it checks the seams between reviewed tasks; after an inline executing-plans run it is the only review the branch gets. Triages the ledger lines it is given."
+description: "Superpowers final whole-branch reviewer, dispatched once per plan: after subagent-driven-development it reviews the tasks left to it and the seams between all of them; after an inline executing-plans run it is the only review the branch gets. Triages the ledger lines it is given."
 tools: read, grep, glob, bash, lsp, ast_grep
 # thinkingLevel is the seat's reasoning tier; an explicit :level on the model
 # string (or on a task.agentModelOverrides entry) takes precedence over it.
@@ -15,7 +15,7 @@ readSummarize: false
 
 You review a whole branch once, at the end of a plan. Your dispatch gives the merge-base..HEAD review package, the plan/spec paths, the ledger lines to triage, and how the plan ran:
 
-- **subagent-driven-development:** every task went through its own task review, except the fixes the controller applied itself on the proven-trivial route (ledger lines `Task <N>: applied … proof: …`, passed in the dispatch), which skipped the re-review: check each such fix and its proof as if no one had. Per-task reviews cannot see cross-file seams; you can, so spend your attention there.
+- **subagent-driven-development:** the dispatch names the tasks that had their own task review (`review per-task`, with a risk class) and the tasks that did not (`review at final`). Do the task review's work on every `review at final` task first, as for an inline run below. Then the seams: per-task reviews cannot see cross-file seams, so spend your attention there, deepest around the `review per-task` classes. Fixes the controller applied itself on the proven-trivial route (ledger lines `Task <N>: applied … proof: …`, passed in the dispatch) skipped the re-review: check each such fix and its proof as if no one had.
 - **executing-plans (inline):** no task was reviewed, and you are the only fresh review this branch gets. Do the task reviews' work across the whole branch first — every plan requirement present, nothing extra, the code sound, and tests that can fail (would deleting a fix, or a plausible regression, leave them green?) — then the seams.
 
 If the dispatch does not say how the plan ran, review it as an inline run.
@@ -24,10 +24,11 @@ If the dispatch does not say how the plan ran, review it as an inline run.
 - Read `skill://requesting-code-review/code-reviewer.md` first and apply its **What to Check** (plan alignment, code quality, architecture, testing, production readiness), its **Calibration**, its Critical / Important / Minor definitions (under *Output Format → Issues*), and its **Critical Rules**. Its Output Format layout, Recommendations, Assessment, and Read-Only Review section do not apply: `<output>` below governs the result, and the bash limits below govern the checkout.
 - Read the package in full, from line 1, with an explicit range: a bare `read` returns only the first 300 lines, `<path>:1-3000` returns up to 3,000 per call, and when the footer says `[Showing lines … of N. Use :M to continue]` you continue with `:M-<M+2999>` until you have read all N lines. Never judge from a partial read. A line over 768 characters arrives truncated — `grep -n` the file to see one in full.
 - Then trace every patch-introduced type, value, or contract across its consuming side: the dispatch point is often outside the diff — read it before concluding the producer is correct.
-- If the dispatch names a high-risk change class (concurrency, security, a data migration), start there and go deeper.
+- If the dispatch names a high-risk change class (concurrency, security, a data migration), go deepest there, after any task left to you for its task review. Code the dispatch lists as `rebased` or `Wave <K>: fix` had no task review: check it as if no one had.
 - Bash is read-only: `git log`, `git show`, `git diff`, running a focused test. Never edit, never run the whole suite.
 - Read-only is your rule, not the harness's: omp mounts MCP and extension tools on you as `xd://` devices reached through `write`, and the `tools:` list cannot remove them. Never call an `xd://` device, or any extension or MCP tool, that executes code, writes files, or changes external state — nor a memory tool that writes (`retain`, `memory_edit`) if your tool list shows one.
 - The spec is a vision document: it says what the software must do, not every input, environment, or condition it will meet. Where it is silent, a reasonable person's expectation is the requirement — the spec's silence is not permission. Grade such findings by their effect on that person, not by whether the spec mentions the trigger.
+- A crash (an uncaught exception, a traceback) or lost data on input a user can give is always a finding, never a `Declined to judge` line, whatever the plan or spec says about that input.
 - If the dispatch carries the plan's Review Focus list, check each item deliberately: those are inputs and failure modes the plan's tests do not exercise.
 - Triage the ledger lines you were given: which deferred minors must be fixed before merge, which rulings you overturn — say why in one line each.
 - You do not dispatch subagents.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@loneexile/omp-superpowers",
-  "version": "7.0.0-omp.2",
+  "version": "7.0.0-omp.3",
   "description": "obra/superpowers adapted for Oh My Pi (omp): a truthful task/todo tool mapping and five subagent-driven-development agents, each with its own model, thinking level, and tools.",
   "type": "module",
   "keywords": [

package/skills/brainstorming/SKILL.md

@@ -31,7 +31,8 @@ Your first message is two things, in this order:
    have you just start, they can say so. If they take you up on it, this
    skill is done: state any significant how-it-gets-made choice
    (platform, language, medium) in one plain line, then do what they
-   asked through the normal workflow.
+   asked the way its size calls for (Size the Work, below). Their opt-out
+   is the approval a small change needs.
 2. One open question that gets them describing. Ask about a real moment
    or a concrete picture: "What's the moment you find yourself wishing
    this existed?" or "Tell me about the people who'll be in the room."
@@ -113,12 +114,15 @@ conversation.
 
 Play back as you go. As soon as you understand one part well enough to
 describe it (what it's for and who it serves, say, or how one piece
-behaves), describe that part back in about 200-300 words, then return to
-questions about the next part. Playback and questions alternate through
-the whole conversation; the last chunk covers whatever is left.
+behaves), describe that part back in about 200-300 words. A playback
+doesn't wait for its own answer: send it in the same message as your
+next question, with one line saying they can correct anything in it in
+their reply. The last chunk covers whatever is left and goes out with
+the size you pick; for a small change, it ends by asking whether to
+build it.
 
 Mark anything you're guessing as your guess; only what they said goes in
-as theirs. End each chunk by asking what's wrong or missing.
+as theirs.
 
 Before you send a chunk, check it: does it describe something they'll
 look at, like a page, a screen, a schedule, or a printout? If so, and
@@ -134,9 +138,41 @@ words. They can override it.
 | Size | The full description | Then |
 |------|----------------------|------|
 | A quick, clear task | the request itself | do it |
-| A small change | in chat | build it through the normal workflow |
+| A small change | in chat | the small-change path, below |
 | A project with a written design | a written design document | a full plan (for software: superpowers:writing-plans) |
 
+**A small change** is one you can describe in a few lines of chat: it
+stays inside one area of the work, adds nothing that other parts will
+build on, and one revert undoes it. Adding a behavior can be small (a new
+`--quiet` flag). These are never small; size them as projects: security,
+authentication, concurrency, money, data migrations, anything one revert
+cannot undo, and in software a new config file or stored format, a change
+to existing behavior (a default, an exit code, error handling, what
+happens with no input), a new interface other code builds on (plugins, a
+public API), or a new dependency.
+
+**The small-change path.** Once they approve the description, build it
+yourself, in this session: no design document, no plan, no subagents.
+For software:
+
+1. Run `git status --short` first and note anything that isn't yours. On
+   the default branch or a detached HEAD, start a branch for the change
+   (`git switch -c <topic>`), unless they told you to work where you are.
+2. Test first (superpowers:test-driven-development): a failing test,
+   then the code that makes it pass. A change no test can cover
+   (configuration, docs) gets the cheapest check that can fail instead:
+   a build, a lint, a parse. Their approval of the description covers
+   that exception.
+3. Run the tests that cover the change, then the full suite once.
+4. Commit once, staging your own files by path, never with `-a` or `-A`.
+5. Before you call it done, follow
+   superpowers:verification-before-completion: name the commit, the
+   command you ran, what it printed, and any changes in the tree that
+   aren't yours.
+
+Your human partner reviews that commit; it is the only review a small
+change gets. Outside software, make the change and show it to them.
+
 If it grows mid-task, stop, say so, and step up a size.
 
 If this is really several independent projects, say so, agree on an
@@ -159,9 +195,11 @@ Otherwise, ask. Your human partner's preferences override both.
 
 **Builder check:** dispatch a fresh subagent with
 `builder-check-prompt.md` in this directory. When you tell your human
-partner you're writing it up, say a reviewer will read it first and you
-may come back once with a few questions. Don't hand over the document
-until the check is back. Sort what the builder asks into three piles:
+partner you're writing it up, say a reviewer will read it first, that you
+may come back once with a few questions, and, for software, that the
+plan comes with it. Don't hand over the document until the check is
+back. Without a subagent tool, read the document as that builder
+yourself. Sort what the builder asks into three piles:
 
 - **Answered already** by the conversation or the project: put the answer
   in the document.
@@ -170,26 +208,31 @@ until the check is back. Sort what the builder asks into three piles:
 - **Theirs:** only your human partner can answer it, and the answer changes
   what gets built.
 
-Bring the "theirs" pile in one message, most important first. Update the
-document with their answers, then hand it over with a short list of the
-calls you made so they can check those while reading. That's the only
-round of questions the check produces. Without a subagent tool, read the
-document as that builder yourself.
+Bring the "theirs" pile in one message, most important first. That's the
+only round of questions the check produces. Update the document with
+their answers. Then, for software, don't hand the document over on its
+own: invoke superpowers:writing-plans and write the plan now, so your
+human partner approves the design and its plan in one reading. The plan's
+handoff asks for that approval and lists the calls you made. Outside
+software, hand the document over with a short list of the calls you made
+so they can check those while reading.
 
 <HARD-GATE>
 Nothing gets built until your human partner approves the full
-description: in chat for a small change, the document for a project.
-Building includes writing product code, scaffolding, installing
-dependencies, creating projects, and invoking an implementation skill.
-Reading and exploring are fine.
+description: in chat for a small change; for a software project, the
+design document and its plan together, in one approval; otherwise the
+document. Building includes writing product code, scaffolding,
+installing dependencies, creating projects, and invoking an
+implementation skill. Reading, exploring, and writing the plan are fine.
 
 Two exceptions. If they opted out of the questions, the skill is done
 and the gate goes with it. A spike they said yes to may be built; it
 stays labeled throwaway, and keeping what it produced is a new request
 that comes back through this gate.
 
-After a project's document is approved, the next step is the plan. For
-software, invoke superpowers:writing-plans and no other skill.
+The next step after the builder check is the plan. For software, write
+it before the approval: invoke superpowers:writing-plans and no other
+skill. Outside software, the plan follows the document's approval.
 </HARD-GATE>
 
 ## Red Flags
@@ -200,6 +243,7 @@ software, invoke superpowers:writing-plans and no other skill.
 | "I'll fill in sensible defaults" | Good. Say them out loud. A default they never heard is one they couldn't reject. |
 | "I should explain the process first" | Ask your question. The process shows itself. |
 | "They said 'sounds good' to the idea" | Approval covers what you showed them. A description you haven't written isn't approved. |
+| "I'll get the design approved, then write the plan" | For software, write the plan first, so they approve both in one reading. A change to the design updates the plan before you ask again. |
 | "The spike works, I'll keep building on it" | Keeping it is a new request. Back through the gate. |
 
 ## Visual Companion

package/skills/executing-plans/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: executing-plans
-description: Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
+description: Use when executing an implementation plan in the current session as the implementer yourself — your human partner approved inline execution, or no subagent tool is available
 ---
 
 # Executing Plans
@@ -10,7 +10,7 @@ subagent per task, no reviewer per task. One fresh-context review of the
 whole branch at the end.
 
 **Why inline:** Subagent-driven development pays for a fresh implementer
-and a fresh reviewer on every task, each re-reading the codebase from zero.
+on every task and a fresh reviewer on each high-risk one, each re-reading the codebase from zero.
 Inline execution pays for one context (yours) plus one reviewer at the end.
 What it gives up is a fresh context per task and a second pair of eyes per
 task. This skill keeps what those two things bought, by other means: the
@@ -25,7 +25,7 @@ record that survives your own forgetting.
 ledger and the tool results carry the record.
 
 **Continuous execution:** Do not pause to check in with your human partner
-between tasks. They chose inline execution to spend less, not to answer
+between tasks. They approved inline execution to spend less, not to answer
 "should I continue?" after every task. Execute all tasks from the plan
 without stopping.
 
@@ -62,7 +62,7 @@ answers. The worktree and budget limits are in "Vibe mode" in
 ## When to Use
 
 - You have a plan from superpowers:writing-plans and your human partner
-  chose inline execution at the handoff.
+  approved inline (Native) execution at the handoff.
 - Your harness has no subagent tool (see the per-platform references in
   `../using-superpowers/references/`). Never fabricate a dispatch; run
   the plan here.
@@ -74,8 +74,8 @@ it runs well on a mid-tier session model, and the one place the most
 capable model earns its cost is the final review, which this skill
 dispatches separately. Tell your human partner so when they choose inline.
 
-Prefer superpowers:subagent-driven-development when your human partner
-wants a review gate on every task, or when the plan is long enough that
+Prefer superpowers:subagent-driven-development when the plan marks tasks
+`**Review:** per-task`, when your human partner wants a review gate on every task, or when the plan is long enough that
 its later tasks would run on a compacted context. Inline execution over a
 long plan still works — the ledger is what makes it recoverable — but the
 last tasks get the least of you.
@@ -292,7 +292,9 @@ carries the model — so choosing the reviewer's model means choosing its
 agent. Dispatch `sdd-final-reviewer`, the whole-branch reviewer this
 plugin ships, not the bundled `reviewer` or `task` agent. Give it the
 inputs above and say the plan ran inline, with no task reviewed, so it
-checks every change rather than only cross-task seams. Do not paste
+checks every change rather than only cross-task seams. Name every task the
+plan marks `**Review:** per-task`, with its class, so it goes deepest
+there. Do not paste
 code-reviewer.md into the dispatch: the agent reads the review rubric from
 it itself, and its own `<output>` governs. Its model is whatever this host
 maps that agent to: opus-5-5 · max by default (`@slow` when that pin has no

package/skills/requesting-code-review/SKILL.md

@@ -12,7 +12,7 @@ Dispatch a code reviewer subagent to catch issues before they cascade. The revie
 ## When to Request Review
 
 **Mandatory:**
-- After each task in subagent-driven development
+- After each task on subagent-driven development's review list, and once on the whole branch at the end
 - After completing major feature
 - Before merge to main
 

package/skills/subagent-driven-development/SKILL.md

@@ -5,11 +5,11 @@ description: Use when executing implementation plans with independent tasks in t
 
 # Subagent-Driven Development
 
-Execute plan by dispatching a fresh implementer subagent per task, a task review (spec compliance + code quality) after each, and a broad whole-branch review at the end.
+Execute a plan by dispatching a fresh implementer subagent per task — independent tasks in parallel waves, each in its own worktree — with a task review (spec compliance + code quality) for each task on the review list, and one broad whole-branch review at the end that also does the task review's work for every other task.
 
 **Why subagents:** You delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed at their task. They should never inherit your session's context or history — you construct exactly what they need. This also preserves your own context for coordination work.
 
-**Core principle:** Fresh subagent per task + task review (spec + quality) + broad final review = high quality, fast iteration
+**Core principle:** Fresh subagent per task + parallel waves for independent tasks + a task review where risk earns it + one broad final review = high quality, fast iteration
 
 **Narration:** between tool calls, narrate at most one short line — the
 ledger and the tool results carry the record.
@@ -28,7 +28,8 @@ Four things stop you, and only these: an irreversible or destructive
 operation; a security-sensitive action; a side effect outside this worktree
 that norms say you ask about first (a merge, a push to a shared branch, a
 publish); and a plan so broken that every path forward is a guess. For those,
-stop and ask.
+stop and ask. This skill's own wave merges into the plan branch, and the task
+worktrees it creates and removes, are not among them.
 
 **On omp in vibe mode** (your tools include `vibe_spawn` but not `task`)
 you are the director, and this loop cannot run in your session: you have
@@ -54,24 +55,25 @@ limits are in "Vibe mode" in
 digraph when_to_use {
     "Have implementation plan?" [shape=diamond];
     "Tasks mostly independent?" [shape=diamond];
-    "Partner chose inline, or no subagent tool?" [shape=diamond];
+    "Inline approved at the handoff, or no subagent tool?" [shape=diamond];
     "subagent-driven-development" [shape=box];
     "executing-plans" [shape=box];
     "Manual execution or brainstorm first" [shape=box];
 
     "Have implementation plan?" -> "Tasks mostly independent?" [label="yes"];
     "Have implementation plan?" -> "Manual execution or brainstorm first" [label="no"];
-    "Tasks mostly independent?" -> "Partner chose inline, or no subagent tool?" [label="yes"];
+    "Tasks mostly independent?" -> "Inline approved at the handoff, or no subagent tool?" [label="yes"];
     "Tasks mostly independent?" -> "Manual execution or brainstorm first" [label="no - tightly coupled"];
-    "Partner chose inline, or no subagent tool?" -> "executing-plans" [label="yes"];
-    "Partner chose inline, or no subagent tool?" -> "subagent-driven-development" [label="no"];
+    "Inline approved at the handoff, or no subagent tool?" -> "executing-plans" [label="yes"];
+    "Inline approved at the handoff, or no subagent tool?" -> "subagent-driven-development" [label="no"];
 }
 ```
 
 **vs. Executing Plans (inline):**
 - Fresh subagent per task (no context pollution) instead of one context doing every task
-- Review after each task (spec compliance + code quality) instead of only at the end
-- Costs a fresh context per task and per review; inline costs one context plus one final reviewer
+- Independent tasks run in parallel; inline runs every task in turn
+- A task review (spec compliance + code quality) for each high-risk task, plus the final review; inline has only the final review
+- Costs a fresh context per task and per task review; inline costs one context plus one final reviewer
 - Both run in this session, share the same plan workspace and ledger, and never pause between tasks
 
 ## The Process
@@ -81,11 +83,14 @@ digraph process {
     rankdir=TB;
 
     subgraph cluster_per_task {
-        label="Per Task";
+        label="Per Task (every task of a wave at once)";
         "Dispatch implementer subagent (./implementer-prompt.md)" [shape=box];
         "Implementer asks questions?" [shape=diamond];
         "Answer questions, provide context" [shape=box];
         "Implementer implements, tests, commits, self-reviews" [shape=box];
+        "On the review list?" [shape=diamond];
+        "Run the brief's covering tests yourself" [shape=box];
+        "Resume implementer with the failure" [shape=box];
         "Generate review package, dispatch task reviewer (./task-reviewer-prompt.md)" [shape=box];
         "Spec ✅ and quality approved?" [shape=diamond];
         "Finding conflicts with plan text?" [shape=diamond];
@@ -98,42 +103,49 @@ digraph process {
         "Any load-bearing finding?" [shape=diamond];
         "Rule and continue; stop only if every path forward is a guess" [shape=box];
         "Park findings in ledger with rulings" [shape=box];
-        "Append completion to ledger, mark todo complete" [shape=box];
+        "Merge the task branch (wave of 2+), append completion to ledger, mark todo complete" [shape=box];
     }
 
-    "Setup: worktree, ledger check, read plan, pre-flight review" [shape=box];
-    "More tasks remain?" [shape=diamond];
-    "Dispatch final reviewer: sdd-final-reviewer (package + ledger lines; its agent file governs the output)" [shape=box];
+    "Setup: worktree, ledger check, read plan, pre-flight scan: review list + waves" [shape=box];
+    "Start the next wave: a worktree per task when it has 2+" [shape=box];
+    "More waves remain?" [shape=diamond];
+    "Dispatch final reviewer: sdd-final-reviewer (package + ledger lines + the tasks left to it; its agent file governs the output)" [shape=box];
     "Final findings? ONE fix dispatch, one scoped re-review, adjudicate residuals" [shape=box];
     "Final review clean: delete this plan's workspace" [shape=box];
     "Use superpowers:finishing-a-development-branch" [shape=box style=filled fillcolor=lightgreen];
 
-    "Setup: worktree, ledger check, read plan, pre-flight review" -> "Dispatch implementer subagent (./implementer-prompt.md)";
+    "Setup: worktree, ledger check, read plan, pre-flight scan: review list + waves" -> "Start the next wave: a worktree per task when it has 2+";
+    "Start the next wave: a worktree per task when it has 2+" -> "Dispatch implementer subagent (./implementer-prompt.md)";
     "Dispatch implementer subagent (./implementer-prompt.md)" -> "Implementer asks questions?";
     "Implementer asks questions?" -> "Answer questions, provide context" [label="yes"];
     "Answer questions, provide context" -> "Implementer implements, tests, commits, self-reviews";
     "Implementer asks questions?" -> "Implementer implements, tests, commits, self-reviews" [label="no"];
-    "Implementer implements, tests, commits, self-reviews" -> "Generate review package, dispatch task reviewer (./task-reviewer-prompt.md)";
+    "Implementer implements, tests, commits, self-reviews" -> "On the review list?";
+    "On the review list?" -> "Run the brief's covering tests yourself" [label="no - review at final"];
+    "Run the brief's covering tests yourself" -> "Merge the task branch (wave of 2+), append completion to ledger, mark todo complete" [label="pass"];
+    "Run the brief's covering tests yourself" -> "Resume implementer with the failure" [label="fail"];
+    "Resume implementer with the failure" -> "Run the brief's covering tests yourself";
+    "On the review list?" -> "Generate review package, dispatch task reviewer (./task-reviewer-prompt.md)" [label="yes"];
     "Generate review package, dispatch task reviewer (./task-reviewer-prompt.md)" -> "Spec ✅ and quality approved?";
-    "Spec ✅ and quality approved?" -> "Append completion to ledger, mark todo complete" [label="yes"];
+    "Spec ✅ and quality approved?" -> "Merge the task branch (wave of 2+), append completion to ledger, mark todo complete" [label="yes"];
     "Spec ✅ and quality approved?" -> "Finding conflicts with plan text?" [label="no"];
     "Finding conflicts with plan text?" -> "Rule on the conflict, ledger the ruling" [label="yes"];
     "Rule on the conflict, ledger the ruling" -> "Fix round R of 3: R≤2 resume implementer; R=3 fresh sdd-escalation-implementer";
     "Finding conflicts with plan text?" -> "Fix round R of 3: R≤2 resume implementer; R=3 fresh sdd-escalation-implementer" [label="no"];
     "Fix round R of 3: R≤2 resume implementer; R=3 fresh sdd-escalation-implementer" -> "Dispatch scoped re-review (./re-review-prompt.md)";
     "Dispatch scoped re-review (./re-review-prompt.md)" -> "All findings addressed?";
-    "All findings addressed?" -> "Append completion to ledger, mark todo complete" [label="yes"];
+    "All findings addressed?" -> "Merge the task branch (wave of 2+), append completion to ledger, mark todo complete" [label="yes"];
     "All findings addressed?" -> "R = 3?" [label="no"];
     "R = 3?" -> "Fix round R of 3: R≤2 resume implementer; R=3 fresh sdd-escalation-implementer" [label="no - next round"];
     "R = 3?" -> "Adjudicate each open finding" [label="yes - breaker trips"];
     "Adjudicate each open finding" -> "Any load-bearing finding?";
     "Any load-bearing finding?" -> "Rule and continue; stop only if every path forward is a guess" [label="yes"];
     "Any load-bearing finding?" -> "Park findings in ledger with rulings" [label="no"];
-    "Park findings in ledger with rulings" -> "Append completion to ledger, mark todo complete";
-    "Append completion to ledger, mark todo complete" -> "More tasks remain?";
-    "More tasks remain?" -> "Dispatch implementer subagent (./implementer-prompt.md)" [label="yes"];
-    "More tasks remain?" -> "Dispatch final reviewer: sdd-final-reviewer (package + ledger lines; its agent file governs the output)" [label="no"];
-    "Dispatch final reviewer: sdd-final-reviewer (package + ledger lines; its agent file governs the output)" -> "Final findings? ONE fix dispatch, one scoped re-review, adjudicate residuals";
+    "Park findings in ledger with rulings" -> "Merge the task branch (wave of 2+), append completion to ledger, mark todo complete";
+    "Merge the task branch (wave of 2+), append completion to ledger, mark todo complete" -> "More waves remain?" [label="after the wave's last task"];
+    "More waves remain?" -> "Start the next wave: a worktree per task when it has 2+" [label="yes"];
+    "More waves remain?" -> "Dispatch final reviewer: sdd-final-reviewer (package + ledger lines + the tasks left to it; its agent file governs the output)" [label="no"];
+    "Dispatch final reviewer: sdd-final-reviewer (package + ledger lines + the tasks left to it; its agent file governs the output)" -> "Final findings? ONE fix dispatch, one scoped re-review, adjudicate residuals";
     "Final findings? ONE fix dispatch, one scoped re-review, adjudicate residuals" -> "Final review clean: delete this plan's workspace";
     "Final review clean: delete this plan's workspace" -> "Use superpowers:finishing-a-development-branch";
 }
@@ -184,8 +196,14 @@ a ledger file, not only in todos.
   line names your plan file, tasks with a `Task <N>: complete` line are DONE
   — do not re-dispatch them; resume at the first task without one. A task
   whose last line is `dispatched` or `re-dispatched` is mid-implementation:
-  check `git log` from its BASE and read `agent://<id>` before you dispatch
-  anything. A task
+  check `git log` from its BASE (on its task branch, for a wave task whose
+  `dispatched` line names a worktree) and read `agent://<id>` before you
+  dispatch anything. A wave task whose last line is `merged` is merged: clean
+  up its worktree and branch (Complete the task) and write its `complete`
+  line. A wave task whose branch tip is already an ancestor of the plan
+  branch (`git merge-base --is-ancestor <branch> HEAD`) merged before the
+  ledger caught up: ledger `merged` and do the same. A worktree that exists
+  for a task with no `dispatched` line is reused, not added again. A task
   whose last line is a fix round is mid-loop: resume the loop at the next
   round. A ledger whose first line names a different plan file — or a stray
   ledger at the old flat path `.superpowers/sdd/progress.md` — is another
@@ -222,9 +240,34 @@ Write the table to the ledger. Rule on everything you find before execution
 begins — each finding against the plan text that mandates it — and record
 each ruling in the ledger. If the scan is clean, proceed without comment.
 Rule on each conflict it surfaces — the spec is the binding authority, the
-plan is its argument — record the ruling beside its row, and dispatch
-Task 1. The review loop remains the net for conflicts that only emerge from
-implementation.
+plan is its argument — and record the ruling beside its row. Clean or not,
+the same table then gives you the two ledger blocks below; write both before
+the first dispatch. The review loop remains the net for conflicts that only
+emerge from implementation.
+
+**The review list.** A task gets its own task review when the plan marks it
+`**Review:** per-task`, or when you rule it high-risk: security or
+authentication, concurrency, a data migration or persisted format, money, a
+destructive operation, or an interface two or more later tasks consume. A
+batch (below) counts as one task. Ledger one line per task, `Task <N>:
+review per-task — <class>` or `Task <N>: review at final`. The final
+whole-branch review does the task review's work for every `review at final`
+task. A task joins the list mid-run, ledgered as `Task <N>: review per-task
+— <reason>`, when its report is DONE_WITH_CONCERNS about correctness, it
+went BLOCKED, or its implementer needed 100+ turns.
+
+**The waves.** Tasks with no row between them in the scan table (no shared
+file, no shared interface), whose `Consumes` all come from earlier waves,
+form one wave: take them in plan order, at most three to a wave. A task that
+consumes another's interface waits for the wave that produces it. Files
+every task tends to touch (a lockfile, a manifest, a CHANGELOG, an index or
+barrel file) count as shared, and so does anything the tests hold at run
+time (a fixed port, a database, a cache directory). Ledger
+`Wave <K>: tasks <N>, <N>, <N>` for each wave, then start Wave 1. A plan that
+is one long chain gets one task per wave and runs in sequence, and so does
+every plan whose checkout has uncommitted changes to tracked files
+(`git status --porcelain --untracked-files=no` not empty): a merge needs
+them committed or stashed. Untracked files do not block a wave.
 
 ## Agent Selection
 
@@ -346,13 +389,12 @@ needs 100+ turns, or a re-review that wanders, is the signal to rule that
 task onto the escalation seat. Re-reviews are verdict-only work over a small
 diff — `low` reasoning is correct for them, not a compromise.
 
-**Scale the task review to the diff's risk.** The reviewer seat is fixed, but
-a small mechanical diff does not need the deepest reasoning and a subtle one
-(concurrency, security, a data migration) does. When `task.enableEffort` is
-on (it is off by default — `omp config get task.enableEffort`), dispatch the
-reviewer for such a diff with `effort: "hi"`: that selects the resolved
-model's top thinking level, capped by `task.maxEffort`. When it is off, ledger
-the risk — `Task <N>: high-risk diff — <class>` — and name that class in the
+**Scale the task review to the diff's risk.** Every task on the review list
+is there for its risk class or a trouble signal (Setup), so its reviewer needs the deepest
+reasoning the seat has. When `task.enableEffort` is on (it is off by
+default — `omp config get task.enableEffort`), dispatch that reviewer with
+`effort: "hi"`: that selects the resolved model's top thinking level,
+capped by `task.maxEffort`. Either way, name each listed task's class in the
 final review dispatch.
 
 **Escalation (fix round 3):** the implementer that got stuck cannot see its
@@ -406,8 +448,9 @@ judge, and **Mergeable:** come last.
 
 ### 1. Dispatch the implementer
 
-Record BASE (`git rev-parse HEAD`) before dispatching — the review package
-and fix-round diffs need it.
+Record BASE (`git rev-parse HEAD` in the plan checkout) before dispatching —
+the review package and fix-round diffs need it. Every task in a wave shares
+the wave's BASE.
 
 - **Task brief:** before dispatching an implementer, run this skill's
   `bash scripts/task-brief PLAN_FILE N` — it extracts the task's full text to a
@@ -440,7 +483,8 @@ and fix-round diffs need it.
   a pointer to that ledger entry in the dispatch.
 - Record the implementer's agent identity from the dispatch result —
   fix-loop rounds 1-2 resume this agent.
-- Never dispatch multiple implementation subagents in parallel (conflicts).
+- Dispatch a wave's implementers together: ONE `task` call with one item per
+  task. A task runs only in the wave the ledger gave it.
 - **On omp, the agent id is the handle and resume is a message.** The
   `<task-result id="X" …>` envelope (inline, or delivered as a notice)
   reports the agent id and says the agent is now idle. Use that id exactly
@@ -448,7 +492,8 @@ and fix-round diffs need it.
   that was already taken (`Name-2`), and calls a follow-up turn's job
   `<id>-2` — the job id is not the agent id. Ledger the dispatch the moment
   you have the id, together with BASE, so both survive compaction:
-  `Task <N>: dispatched (BASE <base7>, implementer <id>)`. Fix rounds 1-2
+  `Task <N>: dispatched (BASE <base7>, implementer <id>[, worktree <absolute path>])`,
+  the worktree part for a wave task only. Fix rounds 1-2
   and the answer to a NEEDS_CONTEXT then go to that agent with
   `write agent://<id>`.
 - **The write has two success answers; only an error means "dispatch
@@ -461,14 +506,51 @@ and fix-round diffs need it.
   next result arrives as a notice either way. Only an error answer (`Failed:
   …`, or a write error) means dispatch a fresh `sdd-implementer`. That
   dispatch gets a new id, which omp may suffix (`Name-2`) because the old id is
-  taken: ledger it — `Task <N>: re-dispatched (implementer <new id>)` — and use
+  taken: ledger it — `Task <N>: re-dispatched (implementer <new id>[, worktree <absolute path>])` — and use
   it from then on.
-- **One implementer at a time, no isolation.** On omp, SDD dispatches
-  implementers one at a time, in plan order, in the shared checkout, and does
-  not use `task.isolation.enabled`: under the default
-  `task.isolation.merge: patch` an isolated run's work lands as an applied but
-  uncommitted diff, so a review package has no commit range to cut, and an
-  isolated agent cannot be resumed or messaged, which fix rounds 1-2 need.
+- **A wave of two or more: one git worktree per task, not omp isolation.**
+  Implementers sharing one checkout overwrite each other, and
+  `task.isolation.enabled` does not fit SDD. Under the default
+  `task.isolation.merge: patch` an isolated run's work lands as an applied
+  but uncommitted diff, so a review package has no commit range to cut.
+  `merge: branch` keeps the commits, but omp cherry-picks them onto the plan
+  branch the moment the task ends, before any review, under new commit ids,
+  and deletes the task branch. And fix rounds 1-2 resume the implementer,
+  which an isolated agent cannot take. Measured on omp 18.11.0: a `write
+  agent://<id>` to an isolated agent answers `Delivered`, the agent commits
+  its fix in its own copy, and the fix never reaches the plan branch while
+  the session runs; after the session ended it sat on a leftover
+  `omp/task/<id>` branch that also repeats the already-merged commit.
+  Before dispatching the wave, from the plan checkout, add one
+  worktree per task at the plan branch's head:
+
+  ```bash
+  repo=$(basename "$(git rev-parse --show-toplevel)")
+  omp worktree add -b "sdd/<plan>/task-<N>" ~/.omp/wt/"$repo-<plan>-task-<N>"
+  ```
+
+  `<plan>` is the plan file's name without `.md`;
+  superpowers:using-git-worktrees says why `omp worktree add` and
+  `~/.omp/wt/`. If the add warns that the clone fell back to a plain
+  checkout, the worktree lacks `node_modules` and other ignored build
+  output: run the plan's install step there before dispatching. A wave of
+  one runs in the plan checkout, with no extra worktree.
+
+  **Until it merges, a wave task lives in its worktree, not in yours.** The
+  `task` tool has no `cwd`, so every subagent starts in your checkout, which
+  does not have the task's commits yet. So every dispatch for the task —
+  implementer, re-dispatch, escalation, reviewer, re-reviewer — carries its
+  worktree's absolute path: the implementer template's `Work from:` line,
+  and for a reviewer a `Checkout: <path>` line saying to read the changed
+  files and their call sites there. Every command you run for the task
+  (its tests, a proven-trivial fix and its commit) runs with the `bash`
+  tool's `cwd` set to that path, and its branch `sdd/<plan>/task-<N>` stands
+  in for HEAD in every review-package command for it. The skill's scripts
+  (`task-brief`, `review-package`) still run from the plan checkout, never
+  from a task worktree: they write into the workspace of the checkout they
+  run in, and a task worktree's copy is deleted with it. If the session
+  never got `/move`d into the plan's worktree (Setup), run every git command
+  that touches the plan branch with `cwd` set to the plan checkout, too.
 
 Template: [implementer-prompt.md](implementer-prompt.md)
 
@@ -476,9 +558,18 @@ Template: [implementer-prompt.md](implementer-prompt.md)
 
 Implementer subagents report one of four statuses. Handle each appropriately:
 
-**DONE:** Generate the review package (`bash scripts/review-package PLAN_FILE BASE HEAD`, from this skill's directory — it prints the unique file path it wrote; BASE is the commit you recorded before dispatching the implementer — never `HEAD~1`, which silently drops all but the last commit of a multi-commit task), then dispatch `sdd-reviewer` with the printed path.
+**DONE:** For a wave task, first check it worked where it should: its
+worktree has commits past BASE (`git -C <worktree> rev-list --count
+BASE..HEAD` is 1 or more), its worktree is clean (`git -C <worktree> status
+--porcelain` empty; untracked leftovers go back to the implementer), and
+your own checkout gained no changes. A task that wrote into your checkout
+goes back to its implementer with the paths. Then check the task's line in
+the review list.
 
-**DONE_WITH_CONCERNS:** The implementer completed the work but flagged doubts. Read the concerns before proceeding. If the concerns are about correctness or scope, address them before review. If they're observations (e.g., "this file is getting large"), note them and proceed to review.
+- **`review per-task`:** generate the review package (`bash scripts/review-package PLAN_FILE BASE HEAD`, from this skill's directory — it prints the unique file path it wrote; BASE is the commit you recorded before dispatching the implementer — never `HEAD~1`, which silently drops all but the last commit of a multi-commit task; for a wave task, its branch `sdd/<plan>/task-<N>` stands in for HEAD), then dispatch `sdd-reviewer` with the printed path.
+- **`review at final`:** run the covering test command from the brief yourself, once, in the task's checkout, with its output redirected to a file in the plan's workspace; read the tail. A brief that names no test (docs, configuration) gets the cheapest check that can fail instead (a build, a lint, a parse), or goes on the review list. That run is the only check this task gets before the final review, so never take the implementer's report in its place. A pass completes the task (step 5). A failure goes back to the implementer with the output file's path: rounds 1-2 resume it, round 3 is a fresh `sdd-escalation-implementer`, as in the fix loop, and each round ends when your rerun passes, with no re-review. A failure after round 3 is a plan the tests disagree with: stop and ask.
+
+**DONE_WITH_CONCERNS:** The implementer completed the work but flagged doubts. Read the concerns before proceeding. If the concerns are about correctness, address them before review, and put a `review at final` task on the review list (`Task <N>: review per-task — <concern>`). If they're observations (e.g., "this file is getting large"), note them and proceed.
 
 **NEEDS_CONTEXT:** The implementer needs information that wasn't provided. Provide the missing context and re-dispatch. On omp, message the idle agent instead (`write agent://<id>`, the id from the ledger's `dispatched` line): it keeps its context and yields again. Only a write error means re-dispatch, with the context carried in the brief.
 
@@ -505,11 +596,13 @@ rush it into implementation.
 
 ### 3. Review the task
 
-Per-task reviews are task-scoped gates. The broad review happens once, at the
-final whole-branch review. Never skip the task review, and never accept a
-report missing either verdict — spec compliance AND task quality are both
-required. Implementer self-review never replaces the task review; both are
-needed.
+Task reviews run for the tasks on the review list (Setup); every other task
+gets its review from the final whole-branch review. Per-task reviews are
+task-scoped gates; the broad review happens once, at the end. For a task on
+the list, never skip the review, and never accept a report missing either
+verdict — spec compliance AND task quality are both required. Implementer
+self-review never replaces a review: for a listed task the task review is
+it, for any other the final review is.
 
 - Hand the reviewer its diff as a file: run this skill's
   `bash scripts/review-package PLAN_FILE BASE HEAD` and pass the reviewer the file path
@@ -527,7 +620,8 @@ needed.
   dispatch a task reviewer without a diff file.
 - **Reviewer inputs:** the task reviewer gets three paths — the same brief
   file, the report file, and the review package — plus the global
-  constraints that bind the task.
+  constraints that bind the task, and for a wave task a `Checkout:` line with
+  its worktree's absolute path (the re-reviewer gets the same line).
 - The global-constraints block you hand the reviewer is its attention
   lens. Copy the binding requirements verbatim from the plan's Global
   Constraints section or the spec: exact values, exact formats, and the
@@ -693,17 +787,58 @@ a silent discard is forbidden.
 
 ### 5. Complete the task
 
-When the review comes back clean — or every open finding is parked with a
-ruling at the cap — append the completion line to the ledger in the same
-message as your other bookkeeping:
+A task is done when its review comes back clean, when every open finding is
+parked with a ruling at the cap, or, for a `review at final` task, when your
+own run of its covering tests passes.
+
+**A wave task merges first, and its tests run before the merge commits.**
+From the plan checkout, as soon as the task is done (wave tasks are
+independent, so their order does not matter):
+
+```bash
+git merge --no-ff --no-commit "sdd/<plan>/task-<N>"
+# run the task's covering tests on the merged tree, output to a workspace file
+git commit --no-edit
+```
+
+If the merge stops on a conflict, or the covering tests fail on the merged
+tree, run `git merge --abort` and send the task back to its implementer
+(`write agent://<id>`) with the plan branch's name and, for a failure, the
+output file's path: rebase onto the plan branch, fix what the merge
+exposed, re-run its covering tests, report again. Each such round counts
+toward the task's three rounds (rounds and breaker as in the fix loop);
+ledger it as `Task <N>: rebased (<conflict | failing test>)`. A `review
+per-task` task whose rebase changed code gets a scoped re-review over its
+rebased commits: `review-package PLAN_FILE <plan-branch>
+sdd/<plan>/task-<N>`. A failure that belongs to a task already merged, not
+to this one, goes to ONE fix dispatch on the plan checkout as a fix round of
+that earlier task; then merge this one.
+
+Right after the merge commit, ledger `Task <N>: merged (<sha7>)`, then
+remove the task's worktree and branch: `git worktree remove <path>`, then
+`git branch -d "sdd/<plan>/task-<N>"`. If the removal refuses, read
+`git -C <path> status --short`: use `--force` only when nothing it lists is
+missing from the merge; otherwise ledger it and leave it for Finish.
+
+After the last task of a wave of two or more merges, run the full suite once
+in the plan checkout, output to a workspace file. Implementers ran it in
+worktrees without their siblings, so this is the first run on the combined
+tree. A failure no single task owns goes to ONE fix dispatch on the plan
+checkout, ledgered `Wave <K>: fix (<failing tests>)`, before the next wave
+starts.
+
+Then append the completion line to the ledger in the same message as your
+other bookkeeping:
 
 - `Task <N>: complete (commits <base7>..<head7>, review clean)`
 - `Task <N>: complete (commits <base7>..<head7>, <K> parked)` after a
   tripped breaker
+- `Task <N>: complete (commits <base7>..<head7>, review at final — tests: <command>, pass)`
 
-Then mark the todo complete and move on. Never move to the next task while
-the review has open Critical/Important issues that are neither fixed nor
-parked-with-ruling at the cap.
+Then mark the todo complete. Start the next wave only when every task of
+this one is complete and merged; never start it while a task has open
+Critical/Important issues that are neither fixed nor parked-with-ruling at
+the cap.
 
 ## Final Review
 
@@ -713,13 +848,15 @@ branch started from, e.g. `git merge-base main HEAD`) and include the
 printed path in the final review dispatch, so the final reviewer reads
 one file instead of re-deriving the branch diff with git commands. Dispatch
 `sdd-final-reviewer` (the deepest seat, once per plan — see Agent
-Selection) with a `task` that says the plan ran subagent-driven — every
-task went through its task review, except the fixes you applied yourself on
-the proven-trivial route, which skipped the re-review — and names: the
-package path, the plan/spec paths, and the ledger's deferred-minor and
-parked-with-ruling lines verbatim, plus every `Task <N>: applied … proof:`
-line (the reviewer checks those fixes as if unreviewed) and any
-`high-risk diff` line (so the last review spends its depth there). Do not
+Selection) with a `task` that says the plan ran subagent-driven and names:
+the package path; the plan/spec paths; every `review per-task` task with its
+class, which had its own task review (so the last review spends its depth
+on the seams around them); every `review at final` task, which had none, so
+the final reviewer does the task review's work on it first; the ledger's
+deferred-minor and parked-with-ruling lines verbatim; every `rebased` and
+`Wave <K>: fix` line (code no task review saw); and every `Task <N>:
+applied … proof:` line, a fix you applied yourself on the proven-trivial
+route without a re-review (the reviewer checks those as if unreviewed). Do not
 paste requesting-code-review's `code-reviewer.md` into the dispatch — that
 template asks a prose "Ready to merge?" and has no slot for the package or
 the ledger; the agent reads that file's review rubric itself. The agent
@@ -757,6 +894,11 @@ took on your human partner's behalf reach them — they read it and rework
 whatever you got wrong. A ruling that dies with the workspace was a decision
 made in secret.
 
+Check that no wave left anything behind: `git worktree list` shows none of
+this plan's task worktrees, and `git branch --list 'sdd/<plan>/*'` is empty.
+Remove a leftover as in Complete the task, or name it in your final message
+if it holds work the merge does not.
+
 When the final whole-branch review is clean and its fixes are merged,
 delete this plan's workspace (`rm -rf <workspace>`) — the git history is
 the record now. Sibling directories belong to other plans; leave them
@@ -774,7 +916,9 @@ Use superpowers:finishing-a-development-branch.
 | "The reviewer will just find something new anyway" | Scoped re-reviews verify fixes; they cannot wander. New findings on untouched code go to the ledger, not the loop. |
 | "This finding is obviously wrong, I'll drop it" | You adjudicate only at the cap, and every ruling is a ledger entry. Silent discards are forbidden. |
 | "The fix was small, skip the re-review" | Small is not the test — proven is. If you cannot run one command that proves the exact property (and ledger it), the round ends with a scoped re-review. |
-| "Reviews slow the loop down" | The loop without reviews is just unverified churn. Reviews are the loop's brakes and steering. |
+| "This auth change is one line — review it at final" | Risk class, not size, puts a task on the review list. One line of auth gets its own review. |
+| "The report says the tests pass, skip my run" | For a `review at final` task, your run is the only check before the merge. Run it. |
+| "These two tasks barely touch — same wave" | A shared file or a Consumes/Produces link means separate waves. A conflict costs a rebase round; a silent clash between them costs the final review. |
 | "Ledger bookkeeping is overhead" | The ledger is what survives compaction. Controllers without one have re-dispatched entire completed task sequences. |
 | "The implementer spawned its own reviewer — free extra assurance" | It's a duplicate seat reviewing the same diff; the task review is the gate. A worker-spawned reviewer is a defect to flag, not rigor. |
 
@@ -788,11 +932,13 @@ You: I'm using Subagent-Driven Development to execute this plan.
 [Resolve workspace: bash scripts/sdd-workspace docs/plans/feature-plan.md — no ledger inside, fresh start]
 [On omp: scripts dir resolved with realpath skill://subagent-driven-development/scripts and added to the ledger as "SDD scripts: <dir>"; each script runs as bash <dir>/<name>]
 [Create todos for all tasks]
+[Pre-flight scan → ledger: Tasks 1, 3, 4: review at final · Task 2: review per-task — persisted data (repair rewrites stored records) · Wave 1: tasks 1, 3 · Wave 2: tasks 2, 4]
 
-Task 1: Hook installation script
+Wave 1: Task 1 (hook installation script) and Task 3 (help text)
 
-[Run task-brief for Task 1; dispatch implementer with brief + report paths + context]
-[Ledger: Task 1: dispatched (BASE a1b2c3d, implementer Impl1)]
+[Two worktrees: omp worktree add -b sdd/feature-plan/task-1 …, and task-3]
+[Run task-brief for Tasks 1 and 3; ONE task call with two implementer items, each naming its worktree]
+[Ledger: Task 1: dispatched (BASE a1b2c3d, implementer Impl1, worktree /home/me/.omp/wt/app-feature-plan-task-1)]
 
 Implementer: "Before I begin - should the hook be installed at user or system level?"
 
@@ -804,23 +950,23 @@ Implementer: [Later]
   - Self-review: Found I missed --force flag, added it
   - Committed
 
-[Run review-package PLAN_FILE BASE HEAD; dispatch sdd-reviewer with the printed path]
-sdd-reviewer: spec_compliance: compliant · task_quality: approved
-  strengths: ["Good test coverage", "clean"] · findings: []
-
-[Ledger: Task 1: complete (commits a1b2c3d..d4e5f6a, review clean)]
+[Task 1 is review at final: run the brief's covering test in its worktree — npm test test/install.test.js: 5/5 passing]
+[git merge --no-ff --no-commit sdd/feature-plan/task-1; covering test on the merged tree passes; git commit --no-edit]
+[Ledger: Task 1: merged (9a8b7c6); worktree and branch removed]
+[Ledger: Task 1: complete (commits a1b2c3d..d4e5f6a, review at final — tests: npm test test/install.test.js, pass)]
+[Task 3 likewise; its merge was the wave's last, so the full suite runs once in the plan checkout: pass]
 
-Task 2: Recovery modes
+Wave 2: Task 2 (recovery modes, review per-task) and Task 4
 
 [Run task-brief for Task 2; dispatch implementer with brief + report paths + context]
-[Ledger: Task 2: dispatched (BASE d4e5f6a, implementer Impl2)]
+[Ledger: Task 2: dispatched (BASE e5f6a7b, implementer Impl2, worktree /home/me/.omp/wt/app-feature-plan-task-2)]
 
 Implementer: [No questions]
   - Added verify/repair modes
   - 8/8 tests passing
   - Committed
 
-[Run review-package PLAN_FILE BASE HEAD; dispatch sdd-reviewer with the printed path]
+[Run review-package PLAN_FILE BASE sdd/feature-plan/task-2; dispatch sdd-reviewer with the printed path]
 sdd-reviewer: spec_compliance: issues · task_quality: needs_fixes
   spec_issues: ["Missing: progress reporting (spec says 'report every 100 items')"]
   findings: [{severity: Important, location: src/recovery.js:7, body: "Magic number (100)"}]
@@ -829,19 +975,20 @@ sdd-reviewer: spec_compliance: issues · task_quality: needs_fixes
 Implementer: Added progress reporting, extracted PROGRESS_INTERVAL constant.
   Re-ran test/recovery.test.js — 10/10 passing. Fix report appended.
 
-[Run review-package PLAN_FILE FIX_BASE HEAD; dispatch sdd-rereviewer]
+[Run review-package PLAN_FILE FIX_BASE sdd/feature-plan/task-2; dispatch sdd-rereviewer]
 sdd-rereviewer: round_verdict: all_addressed
   finding_verdicts: [{Missing progress reporting: ADDRESSED, src/recovery.js:41},
                      {Magic number: ADDRESSED, src/recovery.js:7}]
   new_breakage: [] · out_of_scope: []
 
-[Ledger: Task 2: fix round 1/3 (2 addressed, 0 open; commits d4e5f6a..b7c8d9e)]
-[Ledger: Task 2: complete (commits d4e5f6a..b7c8d9e, review clean)]
+[Ledger: Task 2: fix round 1/3 (2 addressed, 0 open; commits e5f6a7b..b7c8d9e)]
+[Merge sdd/feature-plan/task-2 the same way; Ledger: Task 2: merged (c3d4e5f)]
+[Ledger: Task 2: complete (commits e5f6a7b..b7c8d9e, review clean)]
 
 ...
 
-[After all tasks]
-[Run review-package PLAN_FILE MERGE_BASE HEAD; dispatch sdd-final-reviewer]
+[After the last wave]
+[Run review-package PLAN_FILE MERGE_BASE HEAD; dispatch sdd-final-reviewer naming Task 2's class, and Tasks 1, 3, 4 as review at final]
 [Read the full result at agent://<id>]
 sdd-final-reviewer: Ledger triage: deferred minors — none block merge. **Mergeable:** yes
 

package/skills/subagent-driven-development/implementer-prompt.md

@@ -47,7 +47,14 @@ Use this template when dispatching an implementer subagent.
     5. Self-review (see below)
     6. Report back
 
-    Work from: [directory]
+    Work from: [directory — for a wave task, its worktree's absolute path]
+
+    Work only under that directory. Your session may have started in a
+    different checkout, so give every file tool (`read`, `write`, `edit`,
+    `grep`, `glob`, `lsp`) absolute paths under it, set the `bash` tool's
+    `cwd` to it for every command, and commit on the branch checked out
+    there. The brief and the report file are the exception: use the paths
+    given for them.
 
     **While you work:** If you encounter something unexpected or unclear, **ask questions**.
     It's always OK to pause and clarify. Don't guess or make assumptions.
@@ -60,12 +67,12 @@ Use this template when dispatching an implementer subagent.
     Do all of this task's work yourself. Never spawn a subagent to
     implement part of the task, and above all never spawn a reviewer to
     check your work. Self-review (below) means reading your own diff.
-    Review is the controller's job: after you report, it dispatches a
-    fresh reviewer against your diff. A reviewer you spawn duplicates
-    that review at full cost, and its approval counts for nothing in
-    the process. If you catch yourself thinking "an independent review
-    would strengthen my report" — that review is already scheduled.
-    Report instead.
+    Review is the controller's job: after you report, it reviews or tests
+    your work, and a whole-branch review at the end covers every task. A
+    reviewer you spawn duplicates that review at full cost, and its
+    approval counts for nothing in the process. If you catch yourself
+    thinking "an independent review would strengthen my report" — that
+    review is already scheduled. Report instead.
 
     ## Code Organization
 
@@ -126,13 +133,21 @@ Use this template when dispatching an implementer subagent.
 
     ## After Review Findings
 
-    If the task review finds issues, you will be resumed with the findings.
+    If the task review, or the controller's own run of your covering tests,
+    finds issues, you will be resumed with the findings.
     Fix them, re-run the tests that cover the amended code, and append a fix
     report to your report file: what you changed, the covering tests you
     ran, the command, and the output. Reviewers will not re-run tests for
     you — your report is the test evidence. Then reply with the same short
     status contract as your first report.
 
+    You may also be resumed because your branch would not merge into the
+    plan branch: the message names the plan branch and, when tests failed
+    on the merged tree, the file holding their output. Rebase onto the
+    plan branch, fix what the merge exposed, re-run your covering tests,
+    append what you did to your report file, and reply with the same short
+    status contract.
+
     ## Report Format
 
     Write your full report to [REPORT_FILE]:

package/skills/subagent-driven-development/re-review-prompt.md

@@ -38,6 +38,7 @@ that the fix itself broke nothing.
     **Fix base:** [FIX_BASE_SHA] (the head the previous review saw)
     **Head:** [HEAD_SHA]
     **Diff file:** [DIFF_FILE]
+    [CHECKOUT_LINE]
 
     Read the diff file in full, with an explicit range: `[DIFF_FILE]:1-3000`
     (a bare read returns only the first 300 lines; while the footer says
@@ -115,6 +116,8 @@ that the fix itself broke nothing.
 - `[FIX_BASE_SHA]` — the head the previous review saw
 - `[HEAD_SHA]` — current commit
 - `[DIFF_FILE]` — the path `bash scripts/review-package PLAN_FILE FIX_BASE HEAD` printed
+- `[CHECKOUT_LINE]` — same as the task reviewer's: the worktree line for a wave
+  task that has not merged yet, omitted otherwise
 
 **Re-reviewer returns** (structured): `finding_verdicts[]` (ADDRESSED /
 NOT_ADDRESSED with file:line), `new_breakage[]` for the fix diff only,

package/skills/subagent-driven-development/task-reviewer-prompt.md

@@ -38,6 +38,7 @@ more, nothing less) and is well-built (clean, tested, maintainable)
     **Base:** [BASE_SHA]
     **Head:** [HEAD_SHA]
     **Diff file:** [DIFF_FILE]
+    [CHECKOUT_LINE]
 
     Read the diff file in full, with an explicit range: `[DIFF_FILE]:1-3000`
     (a bare read returns only the first 300 lines; while the footer says
@@ -206,6 +207,10 @@ more, nothing less) and is well-built (clean, tested, maintainable)
 - `[DIFF_FILE]` — REQUIRED: the path the controller wrote the review
   package to (`bash scripts/review-package PLAN_FILE BASE HEAD` prints the unique
   path it wrote; the package never enters the controller's context)
+- `[CHECKOUT_LINE]` — for a wave task that has not merged yet: `**Checkout:**
+  <worktree absolute path> — the task's code lives here, not in your
+  session's checkout; read changed files and their call sites under this
+  path.` Omit the line otherwise.
 
 **Reviewer returns** (structured): `spec_compliance`, `spec_issues[]`,
 `cannot_verify[]`, `strengths[]`, `findings[]` (Critical/Important/Minor with

package/skills/using-git-worktrees/SKILL.md

@@ -78,7 +78,7 @@ Rules, each measured on omp 18.4.10:
 - **In vibe mode the session cannot follow a worktree.** Vibe refuses `/move` and `/wt` ("Exit vibe mode first."), and leaving vibe mode kills every worker. A vibe director (your tools include `vibe_spawn` but not `task`) has no `bash`; a worker can run `omp worktree add`, but the session cannot follow it while vibe is on. So ask your human partner to create the worktree and `/move` into it before `/vibe`; otherwise put the worktree's absolute path in every worker brief and `read` files there by absolute path.
 - **Cleanup.** A finished worktree is removed with `git worktree remove <path>` from the repo — that also deletes the directory. `omp worktree clear` only sweeps *orphaned* entries (its own words: "parent repo no longer tracks this worktree"); a live worktree survives it. **`omp worktree clear --all` removes every entry under the worktree directory** — live worktrees and `/wt` session worktrees included — and force-removes them even with uncommitted changes, without asking (the branches survive). Never run it unless your human partner asked for exactly that, and preview any `clear` with `--dry-run`. Never `rm -rf` a registered worktree.
 
-This is the whole-session layer. Per-*subagent* isolation is a separate switch, `task.isolation.enabled` (default off); subagent-driven-development dispatches its implementers one at a time and does not use it.
+This is the whole-session layer. Per-*subagent* isolation is a separate switch, `task.isolation.enabled` (default off), and subagent-driven-development does not use it: when it runs independent tasks in parallel, it gives each task its own worktree with this same `omp worktree add`, and merges each task's branch back itself.
 
 Then skip to Step 2.
 

package/skills/using-superpowers/references/pi-tools.md

@@ -18,7 +18,7 @@ Batch shape (the `task.batch` setting, on by default): one call carries `{ conte
 
 Agent types: pick the most specific one per item from the roster in the `task` tool's own description. Commonly available: `scout` (read-only research — use for investigation), `reviewer`, `security-reviewer`, `sonic` (strictly mechanical work), `task` (general-purpose, full capabilities). The exact roster depends on installed and configured agents, so read the tool description rather than assuming.
 
-The tool is lowercase `task`; `Task` does not exist. `task.isolation.enabled` (default off) only lets a dispatch mark items `isolated: true`; isolated work comes back as an applied patch (default `task.isolation.merge: patch`), and an isolated subagent cannot be messaged afterwards. Superpowers SDD does not use it.
+The tool is lowercase `task`; `Task` does not exist. `task.isolation.enabled` (default off) only lets a dispatch mark items `isolated: true`. Under the default `task.isolation.merge: patch`, isolated work comes back as an applied, uncommitted patch. Under `merge: branch`, omp cherry-picks the subagent's commits onto your branch when it finishes, under new commit ids, and deletes the task branch; a conflict leaves `omp/task/<id>` for you to resolve. Never send an isolated subagent a follow-up. Measured on omp 18.11.0: its result says it "cannot be resumed or messaged", yet `write agent://<id>` answers `Delivered`, and the work it does then never reaches your branch while the session runs; after the session ended it sat on a leftover `omp/task/<id>` branch that also repeats the already-merged commit. Dispatch a fresh subagent instead. If a follow-up already went out, cherry-pick only its new commits from that branch, never merge the branch. Superpowers SDD does not use isolation.
 
 ### Model selection on omp
 

package/skills/writing-plans/SKILL.md

@@ -33,13 +33,29 @@ This structure informs the task decomposition. Each task should produce self-con
 
 ## Task Right-Sizing
 
-A task is the smallest unit that carries its own test cycle and is worth a
-fresh reviewer's gate. When drawing task boundaries: fold setup,
+A task is the smallest unit that carries its own test cycle and its own
+commit range. When drawing task boundaries: fold setup,
 configuration, scaffolding, and documentation steps into the task whose
-deliverable needs them; split only where a reviewer could meaningfully
-reject one task while approving its neighbor. Each task ends with an
+deliverable needs them; split only where one task could be rejected
+while its neighbor stands. Each task ends with an
 independently testable deliverable.
 
+Tasks that share no file and no interface can run in parallel under
+subagent-driven-development. Where a shared file is avoidable, keep it in
+one task.
+
+## Review Marks
+
+Every task is reviewed in the whole-branch review at the end of the plan.
+A task also gets its own fresh reviewer when a shipped mistake there is
+costly or hard to see in a whole-branch diff: security or authentication,
+concurrency, a data migration or persisted format, money, a destructive
+operation. Mark such a task under its heading, naming the class:
+
+`**Review:** per-task — concurrency`
+
+Leave every other task unmarked.
+
 ## Step Granularity
 
 **Each step is one action with a checkable result:**
@@ -94,6 +110,8 @@ owns the code, in that task's own step style.]
 ````markdown
 ### Task N: [Component Name]
 
+**Review:** per-task — [class; this line only on a task Review Marks covers]
+
 **Files:**
 - Create: `exact/path/to/file.py`
 - Modify: `exact/path/to/existing.py:123-145`
@@ -174,33 +192,45 @@ After writing the complete plan, look at the spec with fresh eyes and check the
 
 **5. Proportion:** Compare the plan's length to the spec's. A plan several times longer than the spec it implements is a transcript of the program, not a plan. If code blocks are most of the document, replace bodies with signatures, test names and assertions, and check that each step is still unambiguous.
 
+**6. Review marks:** Every task touching security, authentication, concurrency, a data migration or persisted format, money, or a destructive operation carries a `**Review:** per-task` mark; no other task does.
+
 If you find issues, fix them inline. No need to re-review — just fix and move on. If you find a spec requirement with no task, add the task.
 
 ## Execution Handoff
 
-After saving and self-reviewing the plan, link it for your human partner
-to read. If they have already explicitly supplied an execution method, ask
-them to review the plan and confirm it captures what they want; wait for that
-review before implementation, then use the preserved method. Otherwise, ask
-them to review the plan and choose an execution method before implementation.
-
-**When no execution method has already been supplied:**
+After saving and self-reviewing the plan, choose the execution method
+yourself, unless your human partner already named one:
 
-**"Plan complete and saved to `docs/plans/<filename>.md`. Please review the plan. Which execution approach would you prefer?**
+- **Subagent-driven** (superpowers:subagent-driven-development) - A fresh subagent implements each task, independent tasks run in parallel in their own worktrees, the tasks marked `**Review:** per-task` get a fresh reviewer each, and one whole-branch review at the end covers every task. Fastest for several tasks whose interfaces the plan settles; costs a fresh context per task.
+- **Native** (superpowers:executing-plans) - I implement every task myself in this session, the way this harness runs work, then one fresh reviewer on the most capable model checks the whole branch. Cheapest, and fastest for a few tightly coupled tasks; no independent review until the end. Runs well with a mid-tier session model, since the plan carries the design.
 
-- **Subagent-driven** - A fresh subagent implements each task and a fresh reviewer checks it before the next one starts, then a whole-branch review at the end. Most thorough; costs a fresh context per task and per review.
-- **Native** - I implement every task myself in this session, the way this harness runs work, then one fresh reviewer on the most capable model checks the whole branch. Cheapest and fastest; no independent review until the end. Runs well with a mid-tier session model, since the plan carries the design.
+A plan with any `**Review:** per-task` mark runs Subagent-driven unless your
+human partner says otherwise: Native has no task reviews. If you still
+choose Native, name the marked tasks in the approval and say they get no
+review before the final one.
 
-**For this plan I recommend <one of the two>, because <one sentence from the plan: how much the tasks depend on each other's interfaces, how many there are, what a shipped mistake would cost>. Does the plan capture what you want, and which approach should we use?"**
+Then ask for ONE approval that covers everything they have not approved
+yet: the design document when this plan came straight from brainstorming,
+the plan, the method, and where the work runs. Do not ask them to pick the
+method; name the one you chose and why, and they can swap it in the same
+reply. Name the workspace too: a new branch in this checkout unless they
+already said otherwise, so the run needs no `/move` from them, and this
+approval is the consent superpowers:using-git-worktrees would otherwise
+ask for. They can answer `/wt <branch>` instead to move the session into
+its own worktree:
 
-**On omp in vibe mode** (your tools include `vibe_spawn` but not `task`), both approaches run in one `good` worker you brief, not in your own session; the chosen skill's vibe note says how. Say so when you offer them.
+**"Design: `docs/specs/<filename>.md`. Plan: `docs/plans/<filename>.md`, <N> tasks. I'll run it <method> on a new branch `<branch>` in this checkout, because <one sentence from the plan: how much the tasks depend on each other's interfaces, how many there are, what a shipped mistake would cost>. Calls I made for you: <the decisions marked as your call, one line each>. Approve both, or tell me what to change, the method included; reply `/wt <branch>` if you want it in its own worktree."**
 
-**When an execution method has already been supplied:**
+Leave out the Design line when there is no new design document, and the
+calls line when you made none. When they already named the method, use
+theirs and say so instead of the because-sentence. Wait for that one
+answer. If they change the design, update both documents before you ask
+again; if they change only the method or the workspace, start with theirs.
 
-**"Plan complete and saved to `docs/plans/<filename>.md`. Please review the plan. Does it capture what you want?"**
+**On omp in vibe mode** (your tools include `vibe_spawn` but not `task`), both approaches run in one `good` worker you brief, not in your own session; the chosen skill's vibe note says how. Say so in the approval message.
 
-**If Subagent-driven chosen:**
+**Once approved, Subagent-driven:**
 - **REQUIRED SUB-SKILL:** Use superpowers:subagent-driven-development
 
-**If Native chosen:**
+**Once approved, Native:**
 - **REQUIRED SUB-SKILL:** Use superpowers:executing-plans