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

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

@@ -47,25 +47,39 @@ 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]
+    [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, 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
 
     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 +140,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]:
@@ -156,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

@@ -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
@@ -112,9 +113,13 @@ 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
 
 **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
@@ -202,10 +203,16 @@ 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)
+- `[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
 
@@ -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

@@ -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,48 @@ 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:**
-
-**"Plan complete and saved to `docs/plans/<filename>.md`. Please review the plan. Which execution approach would you prefer?**
-
-- **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.
-
-**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?"**
-
-**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.
-
-**When an execution method has already been supplied:**
-
-**"Plan complete and saved to `docs/plans/<filename>.md`. Please review the plan. Does it capture what you want?"**
-
-**If Subagent-driven chosen:**
+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 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
+choose Native, name the marked tasks in the approval and say they get no
+review before the final one.
+
+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. 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."**
+
+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.
+
+**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.
+
+**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