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

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

@@ -9,6 +9,12 @@ Use this template when dispatching an implementer subagent.
   agent: "sdd-implementer",  # REQUIRED — carries model, thinking level, tools.
                              # Fix round 3 / a ruled strongest-tier exception:
                              # "sdd-escalation-implementer". Never plain "task".
+  solutionSpace: "one task: requirements and exact values are in the brief",
+                             # REQUIRED by omp's task schema: one line on how open the
+                             # problem is. A first implementation on the escalation
+                             # seat: "design open across files: interfaces given,
+                             # approach to choose" (and say it is a first
+                             # implementation: no report file, no findings).
   task: |
     You are implementing Task N: [task name]
 
@@ -88,8 +94,8 @@ Use this template when dispatching an implementer subagent.
 
     **How to escalate:** Report back with status BLOCKED or NEEDS_CONTEXT. Describe
     specifically what you're stuck on, what you've tried, and what kind of help you need.
-    The controller can provide more context, re-dispatch with a more capable model,
-    or break the task into smaller pieces.
+    The controller can provide more context, hand the task to a stronger seat
+    (`sdd-escalation-implementer`), or break the task into smaller pieces.
 
     ## Before Reporting Back: Self-Review
 

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

@@ -11,8 +11,11 @@ that the fix itself broke nothing.
 { context: "<one line: plan name, branch, read-only re-review of one fix round>",
   tasks: [ {
   name: "ReReviewTaskNRoundR",
-  agent: "sdd-rereviewer",   # REQUIRED — the cheap seat: low thinking,
-                             # read/grep only (no file writes, no shell), four-call budget.
+  agent: "sdd-rereviewer",   # REQUIRED — the verdict-only seat: read/grep only (no
+                             # edit, bash, or file-write tool), four working calls
+                             # plus the final yield.
+  solutionSpace: "verdicts only: the findings and the fix diff are given; nothing to design",
+                             # REQUIRED by omp's task schema: one line on how open the problem is.
   task: |
     You are re-reviewing one task's fix round. A previous review produced
     findings; an implementer has attempted to fix them. Your job is to
@@ -20,7 +23,7 @@ that the fix itself broke nothing.
 
     ## The Task
 
-    Read the task brief: [BRIEF_FILE]
+    Read the task brief (explicit range: `[BRIEF_FILE]:1-3000`): [BRIEF_FILE]
 
     ## The Findings Under Verification
 
@@ -28,19 +31,26 @@ that the fix itself broke nothing.
 
     ## The Fix
 
-    Read the implementer's report (fix reports are appended at the end):
-    [REPORT_FILE]
+    Read the implementer's report to its last line — the fix reports are
+    appended at the end, past a bare read's 300 lines (explicit range:
+    `[REPORT_FILE]:1-3000`): [REPORT_FILE]
 
     **Fix base:** [FIX_BASE_SHA] (the head the previous review saw)
     **Head:** [HEAD_SHA]
     **Diff file:** [DIFF_FILE]
 
-    Read the diff file once — it contains the fix commits, a stat summary,
-    and the fix diff with surrounding context. You have no shell; if the
-    diff file is missing, report that as a gap and stop.
+    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
+    `[Showing lines … of N. Use :M to continue]`, continue with the next
+    range). It contains the fix commits, a stat summary, and the fix diff
+    with surrounding context. You have no bash tool; if the diff file is
+    missing, report that as a gap and stop.
 
     Your review is read-only on this checkout. Do not mutate the working
-    tree, the index, HEAD, or branch state in any way.
+    tree, the index, HEAD, or branch state in any way, and never call an
+    `xd://` device or an extension, MCP, or memory tool that executes code,
+    writes files, or changes external state — your `tools:` list does not
+    stop those, this instruction does.
 
     ## You Do Not Dispatch Subagents
 
@@ -65,10 +75,11 @@ that the fix itself broke nothing.
     The implementer re-ran the tests covering the amended code and appended
     the results to the report file. Treat the report as unverified claims:
     confirm the fix report names the covering tests and shows their output,
-    and verify the claims against the diff. You have no shell: if reading
+    and verify the claims against the diff. You have no bash tool: if reading
     the code raises a specific doubt that no existing run answers, name the
     focused test you would run in that finding's evidence and verdict on
-    what the diff shows.
+    what the diff shows — the controller runs that test before it accepts
+    `all_addressed`.
 
     ## Output
 

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

@@ -11,8 +11,11 @@ more, nothing less) and is well-built (clean, tested, maintainable)
 { context: "<one line: plan name, branch, read-only task review>",
   tasks: [ {
   name: "ReviewTaskN",
-  agent: "sdd-reviewer",     # REQUIRED — read/grep/glob only, no shell: the
-                             # review package IS its view of the change.
+  agent: "sdd-reviewer",     # REQUIRED — read/grep/glob only, no edit, bash, or
+                             # file-write tool: the review package IS its view of
+                             # the change.
+  solutionSpace: "review only: the brief and the diff are given; nothing to design",
+                             # REQUIRED by omp's task schema: one line on how open the problem is.
   task: |
     You are reviewing one task's implementation: first whether it matches its
     requirements, then whether it is well-built. This is a task-scoped gate,
@@ -21,14 +24,14 @@ more, nothing less) and is well-built (clean, tested, maintainable)
 
     ## What Was Requested
 
-    Read the task brief: [BRIEF_FILE]
+    Read the task brief (explicit range: `[BRIEF_FILE]:1-3000`): [BRIEF_FILE]
 
     Global constraints from the spec/design that bind this task:
     [GLOBAL_CONSTRAINTS]
 
     ## What the Implementer Claims They Built
 
-    Read the implementer's report: [REPORT_FILE]
+    Read the implementer's report (explicit range: `[REPORT_FILE]:1-3000`): [REPORT_FILE]
 
     ## Diff Under Review
 
@@ -36,13 +39,16 @@ more, nothing less) and is well-built (clean, tested, maintainable)
     **Head:** [HEAD_SHA]
     **Diff file:** [DIFF_FILE]
 
-    Read the diff file once — it contains the commit list, a stat summary,
-    and the full diff with surrounding context, and it is your view of the
-    change. The diff's context lines ARE the changed files: do not Read a
-    changed file separately unless a hunk you must judge is cut off
-    mid-function — and say so in your report. You have no shell; if the
-    diff file is missing, report that as a gap and stop — do not
-    reconstruct the diff from files.
+    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
+    `[Showing lines … of N. Use :M to continue]`, continue with the next
+    range). It contains the commit list, a stat summary, and the full diff
+    with surrounding context, and it is your view of the change. The diff's
+    context lines ARE the changed files: do not Read a changed file
+    separately unless a hunk you must judge is cut off mid-function — and
+    say so in your report. You have no bash tool; if the diff file is
+    missing, report that as a gap and stop — do not reconstruct the diff
+    from files.
     Do not crawl the broader codebase. Inspect code outside the diff only
     to evaluate a concrete risk you can name — one focused check per named
     risk, and name both the risk and what you checked in your report.
@@ -51,7 +57,10 @@ more, nothing less) and is well-built (clean, tested, maintainable)
     checking the call sites is the right method.
 
     Your review is read-only on this checkout. Do not mutate the working
-    tree, the index, HEAD, or branch state in any way.
+    tree, the index, HEAD, or branch state in any way, and never call an
+    `xd://` device or an extension, MCP, or memory tool that executes code,
+    writes files, or changes external state — your `tools:` list does not
+    stop those, this instruction does.
 
     ## You Do Not Dispatch Subagents
 
@@ -74,7 +83,7 @@ more, nothing less) and is well-built (clean, tested, maintainable)
     ## Tests
 
     The implementer already ran the tests and reported results with TDD
-    evidence for exactly this code. You have no shell and cannot re-run
+    evidence for exactly this code. You have no bash tool and cannot re-run
     anything: verify their claims against the diff. If reading the code
     raises a specific doubt that no existing run answers, name the focused
     test you would run in that finding's body and verdict on what the diff

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

@@ -44,7 +44,7 @@ Has the user already indicated their worktree preference in your instructions? I
 
 Honor any existing declared preference without asking. If the user declines consent, work in place and skip to Step 2.
 
-**On omp, the user has a one-line answer:** `/wt <branch>` moves *this session* into a new worktree on a new branch off `HEAD`, carrying uncommitted changes with it (clone-first, so `node_modules`/`target` come along). Only the user can run it — it is a slash command, refused while you are streaming. If they do, re-run the detection above: `GIT_DIR != GIT_COMMON` now holds, so skip to Step 2. (`worktree.cleanSource: true` additionally runs `git reset --hard` + `git clean` on the *original* checkout afterwards; it is off by default.)
+**On omp, your human partner has a one-line answer:** `/wt <branch>` moves *this session* into a new worktree on a new branch off `HEAD`, carrying uncommitted changes with it (clone-first, so `node_modules`/`target` come along). Only your human partner can run it — it is a slash command, refused while you are streaming. If they do, re-run the detection above: `GIT_DIR != GIT_COMMON` now holds, so skip to Step 2. (`worktree.cleanSource: true` additionally runs `git reset --hard` + `git clean` on the *original* checkout afterwards; it is off by default.)
 
 ## Step 1: Create Isolated Workspace
 
@@ -60,7 +60,7 @@ Only proceed to Step 1b if you have no native worktree tool available.
 
 #### On omp: `omp worktree add`
 
-omp exposes no worktree *tool* to the agent — `/wt` and `/move` are slash commands only the user can type. The native mechanism you can run is the CLI, from `bash`:
+omp exposes no worktree *tool* to the agent — `/wt` and `/move` are slash commands only your human partner can type. The native mechanism you can run is the CLI, from `bash`:
 
 ```bash
 repo=$(basename "$(git rev-parse --show-toplevel)")
@@ -68,14 +68,17 @@ path=~/.omp/wt/"$BRANCH_NAME-$repo"
 omp worktree add -b "$BRANCH_NAME" "$path"      # optional trailing commit-ish, default HEAD
 ```
 
-Rules, each measured on omp 18.1:
+Rules, each measured on omp 18.4.10:
 
 - **Put it under `~/.omp/wt/`** (or the configured `worktree.base`). That is the registry `omp worktree list` / `omp worktree clear` manage; a worktree created elsewhere is a valid git worktree that omp cannot see — the phantom state this step exists to avoid. Do not use `.worktrees/` on omp.
-- **It does not carry uncommitted changes.** It is clone-first (ignored build artifacts like `node_modules` come along), but a dirty tree stays behind. If the user has work in flight, either commit/stash it first or ask them to use `/wt <branch>`, which does carry it.
-- **Your working directory does not follow.** `cd` in `bash` is per call, and `read`/`edit`/`glob` resolve relative paths against the *session* cwd. After creating the worktree, ask the user to run `/move <path>` so the session follows you — until then, use absolute paths for everything under the worktree.
-- **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, and `--all` also takes the user's PR checkouts. Preview with `omp worktree clear --dry-run`. Never `rm -rf` a registered worktree.
+- **It does not carry uncommitted changes.** It is clone-first (ignored build artifacts like `node_modules` come along, unless the clone falls back — next rule), but a dirty tree stays behind. If your human partner has work in flight, either commit/stash it first or ask them to use `/wt <branch>`, which does carry it.
+- **Clone-first can fall back to a plain checkout.** Cloning needs a filesystem that supports copy-on-write clones (measured: APFS clones, HFS+ does not) and a target outside the source checkout (measured on APFS: an in-repo target such as Step 1b's `.worktrees/` fails to clone). When it cannot, omp prints `warning: worktree clone fell back to plain checkout: …` and still exits 0; the worktree then lacks `node_modules`, `target`, and other ignored artifacts, so run Step 2's install as for any fresh checkout. `worktree.clone: false` turns clone-first off.
+- **Your working directory does not follow.** `cd` in `bash` is per call, and `read`/`edit`/`glob` resolve relative paths against the *session* cwd. After creating the worktree, ask your human partner to run `/move <path>` so the session follows you. Until then, use absolute paths for everything under the worktree, and run commands there with the `bash` tool's `cwd` parameter set to the worktree path — or `cd <path> && <cmd>` in the same call (a leading `cd <path> &&` is lifted into `cwd`; the `cd` does not carry to the next call).
+- **Subagents start in the session cwd, not your `cd`.** The `task` tool has no `cwd` argument, so until `/move` a subagent works in the ORIGINAL checkout, not the worktree (measured: after `omp worktree add`, a dispatched subagent's `pwd` was the original checkout). Get `/move` done before dispatching any subagent — implementer, reviewer, or scout. If you cannot, put the worktree's absolute path in every dispatch and tell the subagent to use absolute paths and the `bash` tool's `cwd` parameter throughout.
+- **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 for parallel SDD waves is a separate switch, `task.isolation.enabled` (default off) — see the subagent-driven-development skill.
+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.
 
 Then skip to Step 2.
 
@@ -120,6 +123,8 @@ git worktree add "$path" -b "$BRANCH_NAME"
 cd "$path"
 ```
 
+**On omp,** the `bash` tool rewrites a literal `git worktree add` into `omp worktree add` (clone-first; `worktree.clone` is on by default), so a rewritten run prints `Cloned from … via …`, or the fallback warning from the clone rule above. Only a flat command of the shape `git [-C dir] worktree add [-b|-B branch] [--detach] [-q] [--] path [commit]` is rewritten, and only when it holds no shell-expansion characters: a `$variable`, backtick, `~`, or glob in the command, or any other flag (`--lock`, `--no-checkout`, `--force`), sends it to plain git untouched. The block above, with its `"$path"` and `"$BRANCH_NAME"`, therefore runs as plain git; write the path and branch out literally to get clone-first. A target inside the repo, such as the default `.worktrees/`, cannot be cloned and falls back to a plain checkout with that warning. An extension that rewrites the command before omp sees it also prevents the rewrite: neither a `Cloned from` line nor the warning means plain git ran.
+
 **Sandbox fallback:** If `git worktree add` fails with a permission error (sandbox denial), tell the user the sandbox blocked worktree creation and you're working in the current directory instead. Then run setup and baseline tests in place.
 
 ## Step 2: Project Setup
@@ -141,6 +146,8 @@ if [ -f pyproject.toml ]; then poetry install; fi
 if [ -f go.mod ]; then go mod download; fi
 ```
 
+**On omp, until `/move`** the session cwd is still the original checkout. Run these commands, and Step 3's tests, in the worktree with the `bash` tool's `cwd` parameter set to its path, or `cd <path> && <cmd>` in one call.
+
 ## Step 3: Verify Clean Baseline
 
 Run tests to ensure workspace starts clean:
@@ -170,9 +177,11 @@ Ready to implement <feature-name>
 | In a submodule | Treat as normal repo (Step 0 guard) |
 | Native worktree tool available | Use it (Step 1a) |
 | No native tool | Git worktree fallback (Step 1b) |
-| omp, user typed `/wt <branch>` | Session already moved, WIP carried — re-run Step 0, skip to Step 2 |
+| omp, your human partner typed `/wt <branch>` | Session already moved, WIP carried — re-run Step 0, skip to Step 2 |
 | omp, you create it | `omp worktree add -b <branch> ~/.omp/wt/<branch>-<repo>`; then ask for `/move <path>` |
-| omp, dirty tree | Commit/stash first, or ask the user for `/wt` — `omp worktree add` leaves WIP behind |
+| omp, dirty tree | Commit/stash first, or ask your human partner for `/wt` — `omp worktree add` leaves WIP behind |
+| omp, setup or tests before `/move` | `bash` with `cwd=<worktree path>`, or `cd <path> && <cmd>` in one call |
+| omp, tidy up | `git worktree remove <path>`; `omp worktree clear --all` force-removes every worktree, live ones included — only on request |
 | `.worktrees/` exists | Use it (verify ignored) |
 | `worktrees/` exists | Use it (verify ignored) |
 | Both exist | Use `.worktrees/` |

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

@@ -6,36 +6,74 @@ Skills speak in actions ("dispatch a subagent", "create a todo", "read a file").
 | --- | --- |
 | Dispatch a subagent (`Subagent (general-purpose):` template) | The built-in `task` tool |
 | Dispatch N subagents in parallel | ONE `task` call with N entries in `tasks[]` |
+| Resume or message an idle subagent | `write agent://<id>` |
+| Read a long subagent result | `read agent://<id>` (structured fields at `agent://<id>/<field>`) |
 | Task tracking ("create a todo", "mark complete") | The built-in `todo` tool |
 
 ## Subagents
 
 omp ships a built-in `task` tool. Use it for every Superpowers subagent workflow — never conclude that subagent capability is missing.
 
-Batch shape: one call carries `{ context, tasks[] }`, one subagent per item, run concurrently (capped by the `task.maxConcurrency` setting). Dispatch parallel agents as multiple entries in a single call, never as sequential calls.
+Batch shape (the `task.batch` setting, on by default): one call carries `{ context, tasks[] }`, one subagent per item, run concurrently (capped by the `task.maxConcurrency` setting). Every item also needs `solutionSpace`, one line on how open the problem is. Dispatch parallel agents as multiple entries in a single call, never as sequential calls.
 
 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. Optional: `task.isolation.enabled` runs each subagent in an isolated checkout copy and integrates the result, replacing manual `git worktree` plumbing.
+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.
 
 ### Model selection on omp
 
-The `task` tool has **no `model:` field**. Every `model: [...]` line in a Superpowers template is inert here — the agent TYPE carries model, thinking level, and tool set. Choosing `task` "because it can do everything" means the slowest tier over the widest tool set on every dispatch.
+The `task` tool has **no `model:` field**. Every `model: [...]` line in a Superpowers template is inert here — the agent TYPE carries model, thinking level, and tool set. The bundled `task` is a general agent with the widest tool set and whatever `modelRoles.task` names, not an SDD seat's contract.
 
 This fork ships SDD-specific agents (they appear in the `task` roster once the plugin is installed):
 
-| Superpowers role | `agent:` | What it pins |
-| --- | --- | --- |
-| Implementer, fix rounds 1-2 | `sdd-implementer` | sonnet-5 · medium; edit/test tools; no subagents |
-| Task reviewer | `sdd-reviewer` | sonnet-5 · high; `read`/`grep`/`glob` — no file writes, no shell (`hub start` can still launch a process; the harness cannot remove `hub`) |
-| Scoped re-review | `sdd-rereviewer` | sonnet-5 · low; `read`/`grep`; ≤4 calls |
-| Fix round 3 / ruled strongest-tier task | `sdd-escalation-implementer` | opus-5 · xhigh; same tools as the implementer |
-| Final whole-branch review (subagent-driven-development or executing-plans) | `sdd-final-reviewer` | opus-5 · xhigh; read-only + focused bash |
+| Superpowers role | `agent:` | Shipped default · thinking | Tools |
+| --- | --- | --- | --- |
+| Implementer, fix rounds 1-2 | `sdd-implementer` | claude-sonnet-5-5 · medium | edit/test tools; no subagents |
+| Task reviewer | `sdd-reviewer` | claude-sonnet-5-5 · high | `read`, `grep`, `glob` — no bash, edit, or file-writing tool |
+| Scoped re-review | `sdd-rereviewer` | claude-sonnet-5-5 · low | `read`/`grep`; ≤4 working calls plus the final `yield` |
+| Fix round 3 / ruled strongest-tier task | `sdd-escalation-implementer` | claude-opus-5-5 · max | same tools as the implementer |
+| Final whole-branch review (subagent-driven-development or executing-plans) | `sdd-final-reviewer` | claude-opus-5-5 · max | read-only + focused bash |
 
-Shipped defaults are Anthropic; the tiers are a thinking ladder (low / medium / high / xhigh). Re-point any seat per host with `task.agentModelOverrides` in `~/.omp/agent/config.yml` (or `/agents`) — it beats the agent file's `model:`, applies on the next dispatch, and a bare model keeps the agent's `thinkingLevel:` while an explicit `:level` replaces it.
+Shipped defaults are Anthropic; the tiers are a thinking ladder (low / medium / high / max). Re-point any seat per host with `task.agentModelOverrides` in `~/.omp/agent/config.yml` (or `/agents`) — it beats the agent file's `model:`, applies on the next dispatch, and a bare model keeps the agent's `thinkingLevel:` while an explicit `:level` replaces it. Turn on `task.showResolvedModelBadge` (default off) to see the model each subagent actually ran.
 
-Never use the bundled `task` agent for an SDD seat: it resolves to `modelRoles.task` (else the session model), which may be weaker than `sdd-implementer`. If `task.enableEffort` is on, `effort: "hi"` on a dispatch raises that one subagent's thinking without changing its model — the only accepted values are `"lo"`, `"med"`, `"hi"`.
+Never use the bundled `task` agent for an SDD seat: it lacks the seat's tools, output contract and no-subagent rule, and runs whatever `modelRoles.task` names (else the session model). If `task.enableEffort` is on, `effort: "hi"` on a dispatch raises that one subagent's thinking without changing its model — the only accepted values are `"lo"`, `"med"`, `"hi"`. `"hi"` maps to the model's top supported level, capped by `task.maxEffort`.
+
+### Tool boundary
+
+An agent's `tools:` list limits built-in tools only. Extension tools and MCP tools (mounted as `xd://` devices and run through a device-only `write` that refuses file paths) still attach to every subagent; memory tools attach only when the agent's `tools:` list names them. On omp 18.4.10 a read/grep/glob reviewer ran a shell command through an MCP device. Read-only seats are read-only by instruction, not by sandbox.
+
+### Checks
+
+From omp 18.4.12, every subagent's system prompt carries a hand-off rule ahead of the agent body (read in 18.4.12's `src/prompts/system/system-prompt.md`). It says the main agent verifies once after all subagents land, and: "NEVER verify your changes (builds, tests, linters, formatters, smoke runs) unless your assignment explicitly instructs it." It also tells the subagent to yield when its changes are complete and to name the checks the main agent should run. omp 18.4.10 allowed scoped proof instead: a single test file, a targeted repro, a smoke run.
+
+The rule is prompt text, not a tool block. It applies to every subagent at task depth > 0: plugin agents and vibe workers alike. An explicit instruction in the dispatch wins. Measured on 18.4.12 with haiku-4-5:low, a weak proxy for the real seats:
+
+- an `sdd-implementer` given the implementer template ran `npm test` before and after its fix, and reported RED/GREEN;
+- 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.
 
 ## Task lists
 
 omp ships a built-in `todo` tool (`init`, `start`, `done`, `rm`, `drop`, `block`, `unblock`, `append`, `view`). Use it for all task tracking. Do not use Superpowers plan files, Markdown checklists, or a repo-local `TODO.md` for this. Older Superpowers docs may refer to `TodoWrite`; treat that as the `todo` tool.
+
+## Vibe mode
+
+`/vibe` makes the session a director of worker sessions. You are the director when your tools include `vibe_spawn` but not `task` (a hidden `<vibe-mode>` block before each prompt also says "Vibe mode ON. You are DIRECTOR"). The director keeps `read`, `todo`, the `vibe_*` tools (`vibe_spawn`, `vibe_send`, `vibe_wait`, `vibe_kill`, `vibe_list`) and any MCP tools. It has no `task`, `bash`, `edit`, `write`, `grep`, `glob` or `ask`. MCP tools stay, but omp's vibe rule still applies (never edit, run, grep or build yourself), so do not run commands through an MCP tool either. Every instruction that needs a missing tool goes to a worker.
+
+| Action skills request | Vibe director's equivalent |
+| --- | --- |
+| Dispatch a subagent | `vibe_spawn` a worker. `vibe_spawn` takes only `cli`, a name and a prompt. `cli: "fast"` is omp's bundled `sonic` agent on the `modelRoles.smol` model; `cli: "good"` is the bundled `task` agent on the `modelRoles.task` model. It cannot start any other agent type |
+| Message or resume it | `vibe_send` to the same worker session |
+| Read a long result | The worker writes it to a file; you `read` the file |
+| Run a command, edit, commit | A worker does it |
+| Verify a claim | A worker you explicitly tell to run the command saves the full output and exit code to a file; you `read` that file |
+| Task tracking ("create a todo", "mark complete") | `todo`, which only the director has |
+
+A worker is an ordinary omp subagent. It has the normal coding tools, including `task`, `wait` and `write agent://`, but no `todo`, `ask` or `vibe_*`, and it starts in the session's cwd. It never gets this plugin's bootstrap (the extension skips subagent sessions), so a brief names the skill to `read` (`read skill://<name>`). Workers get the 18.4.12 hand-off rule too (see *Checks*), so a brief that needs a test, build or smoke run names it. A worker is never an SDD seat: `fast` and `good` are the bundled `sonic` and `task` agents, and overrides for their models are `task.agentModelOverrides.sonic` and `task.agentModelOverrides.task`. A long worker result reaches you as a cut-off `<vibe-turn>` response, and its full text at `agent://<id>` comes back as a single line that `read` cuts at 768 characters. Have workers write long reports to a file, and `read` the file.
+
+- **subagent-driven-development and executing-plans:** hand the whole run to ONE `good` worker. Its brief names the skill to read, the plan path and the worktree path, and gives two rules. First, run every test, build and script the skill calls for: the brief must say so explicitly, because an 18.4.12 worker skips checks otherwise (see *Checks*). Second, when the skill says to stop and ask your human partner, end the turn with the question. That worker is the controller. It runs the scripts, keeps the ledger, and dispatches the SDD seats through its own `task` tool, so each seat keeps its model, tools and output contract (measured on omp 18.4.10: a `good` worker ran `read skill://subagent-driven-development`, dispatched `sdd-rereviewer` through its own `task` tool, and the seat ran on its `task.agentModelOverrides` model, returned its structured output to the worker, and was resumed with `write agent://<id>`). The worker has no `todo`; the ledger (`<workspace>/progress.md`) is its record. You keep `todo` from the ledger, take its questions to your human partner, and `vibe_send` the answers.
+- **Worktrees:** while vibe is on, `/move`, `/wt`, `/new` and fork are refused ("Exit vibe mode first."), and leaving vibe mode kills every worker. Create the worktree and `/move` into it before `/vibe`. Otherwise every brief carries the worktree's absolute path, and you `read` files there by absolute path.
+- **Long runs:** a worker's first turn runs under omp's soft request budget, `task.softRequestBudget`: 200 by default, and the `fast` worker's `sonic` agent caps at 100. At the budget the worker gets a wrap-up notice; at 1.5x it is stopped and must yield. A long plan's controller can cross the budget. Set `task.softRequestBudget: 0` (it disables the budget for every subagent), or `vibe_send` the stopped worker "continue from the ledger": omp's source runs a `vibe_send` turn without the budget and keeps a budget-stopped worker idle and resumable (read in 18.4.12's source, not run).
+- **The rest:** brainstorming's questions, the plan handoff and finishing a branch's options are conversation, and stay with the director. A worker writes the files and runs git and the tests its brief names.

package/skills/writing-plans/SKILL.md

@@ -193,6 +193,8 @@ them to review the plan and choose an execution method before implementation.
 
 **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/superpowers/plans/<filename>.md`. Please review the plan. Does it capture what you want?"**