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

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.4] - 2026-10-16
+
+### Fixed
+
+Found by an independent review of 7.0.0-omp.3; a second review checked these fixes. Checked live on omp 18.11.1 with a three-task Python plan (an editable install in `.venv`). On the default workspace the controller ran `git status`, created the approved branch in place with no `/move`, ran tasks 1 and 2 in parallel worktrees, removed and recreated each cloned `.venv` and checked the import from `/` before dispatching, then merged both. Resumed from a ledger left mid-wave (task 1 merged but not ledgered, task 2 with no commits), it ledgered task 1 merged after the commit-count and ancestor checks, and re-dispatched task 2. The released 7.0.0-omp.3 text happened not to lose work in the same resume: its controller checked task 2's history before acting on the ancestor test.
+
+- **Resuming mid-wave no longer marks unstarted tasks as merged.** subagent-driven-development's resume rule ledgered a wave task `merged` when its branch tip was an ancestor of the plan branch, and a branch with no commits yet passes that test (`git merge-base --is-ancestor` exits 0). After a compaction or restart mid-wave, every unstarted sibling would have been ledgered merged and complete, its branch deleted, and its later work never merged. A wave task now counts as merged only when its branch also has commits past its BASE, and that check runs for every unfinished wave task, whatever its last ledger line. Resume then goes by each task's last line and covers `rebased` and `fix round` lines (read the agent first), review-list lines, `merge stuck`, a merge interrupted before its commit (`MERGE_HEAD`), and a wave whose suite has not passed. executing-plans finishes an open wave task under subagent-driven-development's rules instead of redoing it in place.
+- **The default workspace gets created.** writing-plans' approval names a new branch in this checkout, but both executors' Setup still sent the controller to make a worktree and wait for `/move`, or let it work on `main`, where the final review package comes out empty. Setup now creates the approved branch in place, runs project setup and baseline tests there, and ledgers the branch, so a resumed run only switches back to it. A change to a tracked file or anything staged goes back to the partner to commit or stash first, because a run in place commits from that index and tests that working tree; writing-plans' approval message says so up front, and implementers stage their own files by path. finishing-a-development-branch switches to the base branch before deleting a branch made in this checkout.
+- **Task worktrees test their own code.** A cloned in-project virtualenv keeps absolute paths into the plan checkout, through its scripts' interpreter and any editable install, so a wave task's tests ran the plan checkout's code (reproduced with a `uv` project: the cloned interpreter imported the package from the plan checkout, a recreated one from the worktree). Every task worktree, including one reused on resume, now runs the project's install step with a cloned virtualenv removed first (the venv's own pip, not the one on `PATH`); the controller checks from outside the worktree that the code resolves there, and records what the install wrote so it is not sent back to the implementer.
+- **Wave merges and their failures have a defined path.** A merge that git refuses to start (an untracked file in the way) is the controller's to clear and costs the task no round. In a wave of two or more, implementers run only their covering tests (the template and the `sdd-implementer` seat agree), and the controller runs the full suite once each wave merges, the last one included, and ledgers the result. Round 3 of a merge failure goes to the escalation seat, whose agent file now knows a merge round, with the plan branch and the worktree; a task whose rounds were spent in review still gets that one merge round; a task that still will not merge stops the run instead of being parked, and so does a wave suite still red after its one fix, both now in the skill's list of stops. A `review per-task` task whose rebase changed code gets its full task review again, over a merge-base SHA. A fix on the plan checkout gets its own brief and report file, its seat and its follow-up suite run. The reviewer templates take a wave task's branch-tip SHA as its head and next FIX_BASE, never the branch name. An implementer that had to change a file outside its brief reports DONE_WITH_CONCERNS ("or scope" is back, in the review-list trigger too), and the task merges after its wave's others.
+- **Small changes keep their guard.** A fully specified request on the never-small list is no longer built straight away as a "quick task". The small-change path asks before starting when something is already staged, runs the suite before changing anything so an existing failure is reported instead of mistaken for its own, commits only its own hunks of a file that already had edits, and stops before committing when the change grows into a project.
+- writing-plans no longer calls Native "fastest for a few tightly coupled tasks", a plan executing-plans and subagent-driven-development both turn away. The README's file list and upstream-sync notes now include this fork's executing-plans, requesting-code-review and finishing-a-development-branch edits.
+
 ## [7.0.0-omp.3] - 2026-10-16
 
 ### Changed
@@ -103,7 +116,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.3...HEAD
+[Unreleased]: https://github.com/LoneExile/omp-superpowers/compare/v7.0.0-omp.4...HEAD
+[7.0.0-omp.4]: https://github.com/LoneExile/omp-superpowers/releases/tag/v7.0.0-omp.4
 [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

package/README.md

@@ -161,12 +161,14 @@ 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
-- `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
+- `skills/brainstorming/` — a defined small-change path: after the in-chat approval the session builds it itself on a branch: the full suite before changing anything, test first, the covering tests and the suite again, then one commit of only its own files and hunks, 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, and none of them takes the quick-task route however complete the request); 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/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 with the project's install step re-run there, merged back with `--no-ff` after their covering tests pass on the merged tree; a task that still will not merge after round 3 stops the run); Setup creates the approved branch in this checkout instead of a worktree; resume reads each task's last ledger line, and treats a wave task as merged only when its branch has commits past BASE; 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/` — the description, *Why inline*, *When to Use* and the "Prefer subagent-driven-development" paragraph say the partner approved inline execution at the handoff and that SDD reviews per task only where a plan marks it; Setup creates the approved branch in this checkout; a ledger with `Wave` lines resumes under SDD. Additive omp paragraphs: 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 for vibe mode, where a director hands the whole run to one `good` worker
+- `skills/requesting-code-review/` — *Mandatory* says a review follows each task on subagent-driven-development's review list, and once on the whole branch at the end, instead of after every task
 - `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/` — *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
+- `skills/writing-plans/` — *Execution Handoff* picks the method itself and asks for one approval of the design, the plan, the method and the workspace (a new branch in this checkout by default, which answers using-git-worktrees' consent question); *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
+- `skills/finishing-a-development-branch/` — one line in the discard path: in a normal repo (a branch made in this checkout), switch to the base branch before `git branch -D`, which git refuses on the checked-out branch
 - `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
@@ -185,7 +187,7 @@ git rebase upstream/main
 git push --force-with-lease origin main
 ```
 
-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.
+Expect conflicts in `skills/subagent-driven-development/`, `skills/brainstorming/`, `skills/writing-plans/`, `skills/executing-plans/`, `skills/requesting-code-review/SKILL.md`, `skills/finishing-a-development-branch/SKILL.md`, `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). A sync that takes upstream's side of executing-plans or requesting-code-review brings back "review after every task" text that contradicts subagent-driven-development's review list: keep the fork's lines. 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.
 

package/agents/sdd-escalation-implementer.md

@@ -13,12 +13,13 @@ thinkingLevel: max
 readSummarize: false
 ---
 
-You own one task from a Superpowers plan. Your dispatch names the brief (requirements, exact values verbatim), the report file, and which of two cases this is:
+You own one task from a Superpowers plan. Your dispatch names the brief (requirements, exact values verbatim), the report file, and which of three cases this is:
 
 - **Takeover:** a prior implementer attempted the task and either could not clear the review findings across two fix rounds, or reported `BLOCKED`. The dispatch lists the open findings, or the blocker that implementer reported. Read the report file first — it records what was tried and, for findings, what the reviewer rejected.
 - **First implementation:** the controller ruled the task needs the strongest seat from the start. No report file exists, no review has happened, and there are no findings: start from the brief and implement it test-first, as `sdd-implementer` would.
+- **Merge round:** the task's branch would not merge into the plan branch, or its covering tests failed on the merged tree, and its earlier rounds did not clear that. The dispatch names the plan branch, the task's worktree, and the conflict or the failing output file. Work in that worktree: rebase the task's branch onto the plan branch, make its covering tests pass on the result, and append what you did to the report file.
 
-If the dispatch does not say which case it is, the report file settles it: it exists for a takeover and not for a first implementation.
+If the dispatch does not say which case it is, the report file settles takeover against first implementation: it exists for a takeover and not for a first implementation. A dispatch that names a plan branch to rebase onto is a merge round.
 
 <contract>
 - Takeover: understand why the previous attempt did not converge before touching code. A loop that survives two resumes usually means the implementer could not see its own problem — look for the framing error, not just the diff; for a blocker, find what actually stopped it. Then fix the open findings, or clear the blocker and finish the task (test-first, as for a first implementation); re-run the covering tests (name them) and append your fix report to the same report file.

package/agents/sdd-implementer.md

@@ -24,5 +24,5 @@ You implement exactly one task from a Superpowers plan. Your dispatch names a br
 </contract>
 
 <budget>
-Read the changed files' context once; do not re-read files you already hold. While iterating, run the focused test for what you are changing; run the full suite once before you commit, not after every edit. A fix round re-runs only the tests that cover the amended code. Every extra turn is wall-clock the controller waits on.
+Read the changed files' context once; do not re-read files you already hold. While iterating, run the focused test for what you are changing; run the full suite once before you commit, not after every edit — unless your dispatch says the task runs in a wave with other tasks, in which case run only the covering tests your brief names. A fix round re-runs only the tests that cover the amended code. Every extra turn is wall-clock the controller waits on.
 </budget>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@loneexile/omp-superpowers",
-  "version": "7.0.0-omp.3",
+  "version": "7.0.0-omp.4",
   "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

@@ -20,7 +20,9 @@ Before you reply, ask yourself: what do I know about what they want, and
 why?
 
 - **Everything that matters is in the request** ("make the icon cornflower
-  blue"). This is a quick, clear task. Do it, and say what you did.
+  blue"). This is a quick, clear task. Do it, and say what you did. Nothing
+  on the never-small list (Size the Work) is a quick task, however complete
+  the request.
 - **Something non-trivial is missing.** Start the conversation.
 
 ## Your First Message
@@ -155,9 +157,13 @@ public API), or a new dependency.
 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
+1. Run `git status --short` first and note anything that isn't yours. If
+   anything is staged (`git diff --cached --quiet` exits non-zero), ask
+   before you start: a commit takes the whole index. 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.
+   Run the full suite once before you change anything: a failure there
+   isn't yours. Report it with the rest; don't fix it unasked.
 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:
@@ -165,6 +171,9 @@ For software:
    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`.
+   A file step 1 showed as changed also holds someone else's edits:
+   stage only your hunks (`git apply --cached` with a patch of just them;
+   `git add -p` needs a terminal), or ask.
 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
@@ -173,7 +182,9 @@ For software:
 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 it grows mid-task, stop before committing, say so, and step up a size:
+say what the uncommitted work holds, and ask whether the design should
+keep it or start clean. A plan never starts on top of it uncommitted.
 
 If this is really several independent projects, say so, agree on an
 order, and brainstorm them one at a time.

package/skills/executing-plans/SKILL.md

@@ -124,10 +124,23 @@ digraph process {
 
 ## Setup
 
-Ensure the work happens in an isolated workspace: use
-superpowers:using-git-worktrees to create one or verify the existing one.
-Never start implementation on a main/master branch without your human
-partner's explicit consent.
+Ensure the work happens in an isolated workspace. If the plan's approval
+named a new branch in this checkout (writing-plans' default), that approval
+was your human partner's answer to superpowers:using-git-worktrees' consent
+question: work in place, with no worktree. With a ledger for this plan
+(below), `git switch` to the branch its `Setup:` line names and resume.
+On a first run, run `git status --porcelain`: a change to a tracked file,
+or anything staged, goes back to your human partner to commit or stash
+first, since your commits and tests would include it; untracked files may
+stay, and stay out of every commit. If a branch with the approved name
+already exists, ask, or name another. Then `git switch -c <branch>`, run
+using-git-worktrees' Step 2 (project setup) and Step 3 (baseline tests)
+here, and, once the ledger exists, ledger `Setup: branch <branch> in this
+checkout; untracked before start: <paths | none>`. Commit your own files
+by path, never with `-a` or `-A`. Otherwise use
+superpowers:using-git-worktrees to create a worktree or verify the
+existing one. Never start implementation on a main/master branch without
+your human partner's explicit consent.
 
 Conversation memory does not survive compaction. An inline executor that
 loses its place re-implements tasks whose commits already exist — the same
@@ -151,7 +164,11 @@ and the new one resumes from the same ledger.
   commits exist in git even when your context no longer remembers making
   them: after compaction, trust the ledger and `git log` over your own
   recollection. A ledger whose first line names a different plan file is
-  another plan's progress: leave it and start your own, fresh.
+  another plan's progress: leave it and start your own, fresh. A wave task
+  (its `dispatched` line names a worktree) with no `merged` or `complete`
+  line after it is still open in its worktree: finish it under
+  subagent-driven-development's resume rules and Complete the task before
+  continuing here. Finished waves need nothing.
 - Create the ledger with its identity as the first line:
   `# SDD ledger — plan: <plan file path>`.
 - `git clean -fdx` will destroy the workspace (it's git-ignored scratch);
@@ -388,7 +405,7 @@ Use superpowers:finishing-a-development-branch.
 ```
 You: I'm using the executing-plans skill to implement this plan inline.
 
-[Setup: worktree verified]
+[Setup: the approval named a new branch feat/hooks in this checkout — git switch -c feat/hooks, project setup and baseline tests in place]
 [Read plan once: docs/plans/feature-plan.md; spec read]
 [Resolve workspace: sdd-workspace docs/plans/feature-plan.md — no ledger inside, fresh start]
 [Pre-flight scan: 2 shared-interface rows, 4 self-consistency rows, clean; written to ledger]

package/skills/finishing-a-development-branch/SKILL.md

@@ -150,9 +150,13 @@ MAIN_ROOT=$(git -C "$(git rev-parse --git-common-dir)/.." rev-parse --show-tople
 cd "$MAIN_ROOT"
 ```
 
-Then clean up the worktree (Step 6) and force-delete the branch:
+Then clean up the worktree (Step 6) and force-delete the branch. In a
+normal repo (`GIT_DIR == GIT_COMMON`, for example a branch made in this
+checkout) the branch is still checked out here, and git refuses to delete
+it, so switch away first:
 
 ```bash
+git switch <base-branch>   # normal repo only
 git branch -D <feature-branch>
 ```
 

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

@@ -29,7 +29,9 @@ 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. This skill's own wave merges into the plan branch, and the task
-worktrees it creates and removes, are not among them.
+worktrees it creates and removes, are not among them. It adds two stops of
+its own: a wave task that still will not merge after its rounds (`merge
+stuck`), and a wave suite still red after its one fix.
 
 **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
@@ -153,12 +155,29 @@ digraph process {
 
 ## Setup
 
-Ensure the work happens in an isolated workspace: use
-superpowers:using-git-worktrees to create one or verify the existing one.
-Never start implementation on a main/master branch without your human
-partner's explicit consent.
-
-**On omp, the session must be in the worktree before you dispatch.** A
+Ensure the work happens in an isolated workspace. If the plan's approval
+named a new branch in this checkout (writing-plans' default), that approval
+was your human partner's answer to superpowers:using-git-worktrees' consent
+question: work in place, with no worktree and no `/move`.
+
+- **A ledger for this plan exists** (below): `git switch` to the branch its
+  `Setup:` line names, and resume from the ledger. Run nothing else here.
+- **First run:** run `git status --porcelain`. If it lists a change to a
+  tracked file, or anything staged, ask your human partner to commit or
+  stash it first: a run in place commits from this index and tests this
+  working tree, so their uncommitted work would land in task commits and in
+  every test result. Untracked files may stay; note them, and they stay out
+  of every commit. If a branch with the approved name already exists, ask,
+  or name another. Then `git switch -c <branch>`, run
+  using-git-worktrees' Step 2 (project setup) and Step 3 (baseline tests)
+  here, and, once the ledger exists, ledger `Setup: branch <branch> in this
+  checkout; untracked before start: <paths | none>`.
+
+Otherwise use superpowers:using-git-worktrees to create a worktree or
+verify the existing one. Never start implementation on a main/master branch
+without your human partner's explicit consent.
+
+**On omp, a session worktree needs `/move` before you dispatch.** A
 subagent starts in the session's cwd (the `task` tool has no `cwd`
 argument), so after `omp worktree add` every SDD subagent still works in the
 ORIGINAL checkout until your human partner runs `/move <path>`. Get `/move`
@@ -193,19 +212,43 @@ a ledger file, not only in todos.
   working directory at the repo root — the scripts call `git rev-parse`.
   The invocation lines in this skill stay as upstream wrote them.
 - Check for this plan's ledger at `<workspace>/progress.md`. If its first
-  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 (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
+  line names your plan file, first find wave tasks that merged before the
+  ledger caught up: for every wave task whose branch still exists and that
+  has no `merged` line, whatever its last line, the merge happened when the
+  branch has commits past its BASE (`git rev-list --count <BASE>..<branch>`
+  is 1 or more) AND its tip is an ancestor of the plan branch (`git
+  merge-base --is-ancestor <branch> HEAD`); ledger `merged` for it. A
+  branch with no commits past BASE also passes the ancestor test; it is an
+  unstarted or lost task, never a merged one. Then take each task by its
+  last ledger line:
+  - `complete`: DONE — do not re-dispatch it; resume at the first task
+    without one.
+  - `merged`: clean up its worktree and branch (Complete the task) and
+    write its `complete` line.
+  - `dispatched` or `re-dispatched`: mid-implementation. Check `git log`
+    from its BASE (on its task branch, for a wave task whose line names a
+    worktree) and read `agent://<id>` before you dispatch anything.
+  - `fix round` or `rebased`: read `agent://<id>` first, and wait for a
+    round still running. A `rebased` round that reported goes back to its
+    merge; a `fix round` line with findings open goes to the next round,
+    and one with none open completes the task. The two kinds of line
+    together count toward the task's three rounds.
+  - `review per-task — <class or reason>`: with no `dispatched` line before
+    it, the task has not started; after one, the task reported and awaits
+    that review.
+  - `merge stuck`: the run is stopped; wait for your human partner.
+  - A worktree that exists for a task with no `dispatched` line is reused,
+    not added again, and gets the install step and its check again
+    (Dispatch the implementer).
+
+  Then check the plan checkout. A merge in progress (`git rev-parse -q
+  --verify MERGE_HEAD` prints a commit) was interrupted: run `git merge
+  --abort` and redo that task's merge (Complete the task). A wave of two or
+  more whose tasks are all complete still needs its suite run, or its fix
+  and rerun, before the next wave or the final review unless its last
+  `Wave <K>:` line is `suite pass`.
+
+  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
   plan's progress: leave it in place and start your own, fresh.
 - Create the ledger with its identity as the first line:
@@ -253,8 +296,8 @@ 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.
+— <reason>`, when its report is DONE_WITH_CONCERNS about correctness or
+scope, 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,
@@ -267,7 +310,8 @@ time (a fixed port, a database, a cache directory). Ledger
 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.
+them committed or stashed. Untracked files keep waves on, but git refuses
+to start a merge that would overwrite one (Complete the task).
 
 ## Agent Selection
 
@@ -531,20 +575,36 @@ the wave's BASE.
 
   `<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.
+  `~/.omp/wt/`. Then, in each new worktree and before dispatching, run the
+  project's install step there (`npm ci`, `uv sync`, the plan's setup
+  command), even when the clone succeeded. A clone that fell back to a
+  plain checkout has no `node_modules` or other build output at all, and a
+  successful clone copies an in-project virtualenv (`.venv`) that keeps
+  absolute paths into the plan checkout — its scripts' interpreter, any
+  editable install — so tests run with it would run the plan checkout's
+  code. Remove a cloned in-project virtualenv before the install step
+  recreates it (`uv sync`, or `python3 -m venv .venv` and `.venv/bin/python
+  -m pip install -e .` — the venv's own pip, not the one on `PATH`). Then
+  check that the code resolves in the worktree, with `cwd` outside it (`/`)
+  so the current directory is not on the import path: for Python,
+  `<worktree>/.venv/bin/python -c 'import <package>;
+  print(<package>.__file__)'` must print a path under the worktree. Record
+  `git -C <worktree> status --porcelain` after the install: files the
+  install wrote are not the implementer's (DONE compares against this). 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
+  worktree's absolute path: the implementer template's `Work from:` line
+  and its wave line (in a wave of two or more, the implementer runs only
+  the covering tests before committing; you run the full suite after the
+  wave merges), 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
@@ -561,7 +621,8 @@ Implementer subagents report one of four statuses. Handle each appropriately:
 **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
+--porcelain` lists nothing beyond what it listed after the install; other
+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.
@@ -569,7 +630,7 @@ the review list.
 - **`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.
+**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, and put a `review at final` task on the review list (`Task <N>: review per-task — <concern>`). A wave task that changed a file outside its brief's Files list broke its wave's independence: merge it after its wave's other tasks, and run their covering tests too on the merged tree. If the concerns are 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.
 
@@ -741,7 +802,9 @@ covering test files in the fix message — a one-line fix does not need the
 whole suite.
 
 **The re-review is scoped.** Run `bash scripts/review-package PLAN_FILE FIX_BASE HEAD`
-where FIX_BASE is the head the previous review saw, and dispatch
+where FIX_BASE is the head the previous review saw, as a commit SHA (for a
+wave task, its branch tip then: `git rev-parse sdd/<plan>/task-<N>`; never
+the branch name, which moves with the fix), and dispatch
 `sdd-rereviewer` with [re-review-prompt.md](re-review-prompt.md): the
 findings list, the brief, the report file, and the printed diff path. It
 has no bash, edit, or file-write tool and a four-call working budget plus its
@@ -801,18 +864,37 @@ git merge --no-ff --no-commit "sdd/<plan>/task-<N>"
 git commit --no-edit
 ```
 
+If git refuses to start the merge (`untracked working tree files would be
+overwritten`, or local changes to a file the merge touches), no merge is
+in progress, so `git merge --abort` has nothing to abort, and the fault is
+in your checkout, not the task: move the named untracked file out of the
+way (it is yours if setup or a script made it; otherwise ask), or commit or
+stash a tracked change of yours, then merge again. That costs the task no
+round.
+
 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.
+toward the task's three rounds, with the fix loop's seats: round 3 is a
+fresh `sdd-escalation-implementer` whose dispatch names the plan branch,
+the worktree, and the conflict or the failing output file, framed as
+"rebase this task's branch onto the plan branch and make its covering
+tests pass on the result". A task whose three rounds were already spent in
+its review loop still gets one merge round, on that seat. Ledger each round
+as `Task <N>: rebased (<conflict | failing test>)`. A task that still
+conflicts or fails after its last round is never parked and never merged:
+ledger `Task <N>: merge stuck (<conflict | failing test>)`, merge the wave's
+other tasks, start no new wave, and stop and ask. A `review per-task` task
+whose rebase changed code gets its task review again, not a scoped
+re-review (there are no open findings to check, and the rebase may have
+changed anything): `review-package PLAN_FILE "$(git merge-base
+<plan-branch> sdd/<plan>/task-<N>)" sdd/<plan>/task-<N>` — a SHA, since the
+plan branch moves when a sibling merges — then `sdd-reviewer`, at `effort:
+"hi"` when `task.enableEffort` is on. A failure that belongs to a task
+already merged, not to this one: abort this merge, get a fix on the plan
+checkout (below), 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
@@ -821,11 +903,24 @@ remove the task's worktree and branch: `git worktree remove <path>`, then
 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.
+in the plan checkout, output to a workspace file, and ledger `Wave <K>:
+suite pass` or `Wave <K>: suite fail (<failing tests>)`. Implementers ran
+only their covering tests, in worktrees without their siblings, so this is
+the first full run on the combined tree. Any failure here gets a fix on the
+plan checkout before the next wave or the final review — the last wave's
+suite runs too.
+
+**A fix on the plan checkout:** write a brief,
+`<workspace>/wave-<K>-fix-brief.md`: the failing tests, the output file, the
+test command to make pass, and the wave's merge commits; when one merged
+task owns the failure, that task's brief and report paths. Dispatch a fresh
+`sdd-implementer` with the implementer template, task `Wave <K> fix`,
+`Work from:` the plan checkout, that brief, and
+`<workspace>/wave-<K>-fix-report.md` as its report file, and ledger `Wave
+<K>: fix dispatched (implementer <id>)`. Merge nothing else while it works.
+When it reports, run the full suite yourself and ledger `Wave <K>: fix
+(<failing tests>; commits <a7>..<b7>)`, then `Wave <K>: suite pass`, or
+`Wave <K>: suite fail (after fix: <failing tests>)` and stop and ask.
 
 Then append the completion line to the ledger in the same message as your
 other bookkeeping:
@@ -927,7 +1022,7 @@ Use superpowers:finishing-a-development-branch.
 ```
 You: I'm using Subagent-Driven Development to execute this plan.
 
-[Setup: worktree verified; on omp, session moved into it with /move]
+[Setup: the approval named a new branch feat/hooks in this checkout — git switch -c feat/hooks, project setup and baseline tests in place, no worktree, no /move]
 [Read plan file once: docs/plans/feature-plan.md]
 [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>]
@@ -936,7 +1031,7 @@ You: I'm using Subagent-Driven Development to execute this plan.
 
 Wave 1: Task 1 (hook installation script) and Task 3 (help text)
 
-[Two worktrees: omp worktree add -b sdd/feature-plan/task-1 …, and task-3]
+[Two worktrees: omp worktree add -b sdd/feature-plan/task-1 …, and task-3; npm ci in each, and a check that the code resolves in the worktree]
 [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)]
 
@@ -954,7 +1049,7 @@ Implementer: [Later]
 [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 3 likewise; its merge was the wave's last, so the full suite runs once in the plan checkout — Ledger: Wave 1: suite pass]
 
 Wave 2: Task 2 (recovery modes, review per-task) and Task 4
 

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

@@ -48,19 +48,26 @@ Use this template when dispatching an implementer subagent.
     6. Report back
 
     Work from: [directory — for a wave task, its worktree's absolute path]
+    [WAVE_LINE — only for a task in a wave of two or more: "Other tasks
+    run in parallel with this one: before committing, run only the
+    covering tests your brief names, not the full suite; the controller
+    runs the full suite once the wave merges."]
 
     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.
+    there, staging your own files by path, never with `git add -A`,
+    `git add .` or `git commit -a`: the checkout may hold changes that
+    aren't yours. 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.
 
     While iterating, run the focused test for what you're changing; run the
-    full suite once before committing, not after every edit.
+    full suite once before committing (unless a wave line above says
+    otherwise), not after every edit.
 
     ## You Do Not Dispatch Subagents
 
@@ -171,7 +178,8 @@ Use this template when dispatching an implementer subagent.
     If BLOCKED or NEEDS_CONTEXT, put the specifics in the final message
     itself — the controller acts on it directly.
 
-    Use DONE_WITH_CONCERNS if you completed the work but have doubts about correctness.
+    Use DONE_WITH_CONCERNS if you completed the work but have doubts about correctness,
+    or had to change a file your brief's Files list does not name (say which).
     Use BLOCKED if you cannot complete the task. Use NEEDS_CONTEXT if you need
     information that wasn't provided. Never silently produce work you're unsure about.
   } ] }

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

@@ -113,8 +113,10 @@ that the fix itself broke nothing.
 - `[FINDINGS]` — the Critical/Important findings and spec gaps from the
   previous review, copied verbatim, one per bullet
 - `[REPORT_FILE]` — the implementer's report file (fix reports appended)
-- `[FIX_BASE_SHA]` — the head the previous review saw
-- `[HEAD_SHA]` — current commit
+- `[FIX_BASE_SHA]` — the head the previous review saw: the `[HEAD_SHA]` you
+  gave it, as a SHA, never a branch name (a branch moves with the fix)
+- `[HEAD_SHA]` — current commit; for a wave task that has not merged yet,
+  its branch tip (`git rev-parse sdd/<plan>/task-<N>`)
 - `[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

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

@@ -203,7 +203,9 @@ more, nothing less) and is well-built (clean, tested, maintainable)
 - `[REPORT_FILE]` — REQUIRED: the file the implementer wrote its detailed
   report to
 - `[BASE_SHA]` — commit before this task
-- `[HEAD_SHA]` — current commit
+- `[HEAD_SHA]` — current commit; for a wave task that has not merged yet,
+  its branch tip (`git rev-parse sdd/<plan>/task-<N>`). Record this SHA:
+  it is the next re-review's FIX_BASE
 - `[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)

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

@@ -52,7 +52,7 @@ The rule is prompt text, not a tool block. It applies to every subagent at task
 - a vibe `good` worker told "fix sum.js so sum(2, 3) returns 5, then commit" ran no test;
 - the same brief plus "This assignment explicitly instructs you to run the tests yourself (`npm test`), before and after the fix" ran both.
 
-So every dispatch that needs a check names the command and when to run it. SDD's implementer template already instructs its test runs: the focused test while iterating, the full suite once before committing.
+So every dispatch that needs a check names the command and when to run it. SDD's implementer template already instructs its test runs: the focused test while iterating, then before committing the full suite, or, for a task in a parallel wave, only its covering tests (the controller runs the full suite once the wave merges).
 
 ## Task lists
 

package/skills/writing-plans/SKILL.md

@@ -202,7 +202,7 @@ After saving and self-reviewing the plan, choose the execution method
 yourself, unless your human partner already named one:
 
 - **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.
+- **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 small tasks; 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
@@ -214,10 +214,13 @@ 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:
+already said otherwise. Approving it answers superpowers:using-git-worktrees'
+consent question with "no new worktree", so the run needs no `/move` from
+them; the execution skill creates the branch at its Setup. If `git status
+--porcelain` lists a change to a tracked file or anything staged, say so in
+the same message: a run in place needs those committed or stashed first.
+They can answer `/wt <branch>` instead to move the session into its own
+worktree:
 
 **"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."**