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

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

@@ -13,7 +13,7 @@ Write implementation plans for an engineer who has not seen this codebase or thi
 
 **Context:** If working in an isolated worktree, it should have been created via the `superpowers:using-git-worktrees` skill at execution time.
 
-**Save plans to:** `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md`
+**Save plans to:** `docs/plans/YYYY-MM-DD-<feature-name>.md`
 - (User preferences for plan location override this default)
 
 ## Scope Check
@@ -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/superpowers/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/superpowers/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