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

package/.pi/extensions/superpowers.ts

@@ -104,7 +104,11 @@ To resume an idle subagent with new input, message it with \`write agent://<id>\
 
 The \`task\` tool has NO \`model:\` field — a template's \`model:\` line is inert; the agent TYPE carries the model, thinking level, and tools. For subagent-driven-development use this plugin's own agents: \`sdd-implementer\` (implementation, fix rounds 1-2), \`sdd-escalation-implementer\` (fix round 3, and tasks ruled to need the strongest tier), \`sdd-reviewer\` (task review), \`sdd-rereviewer\` (scoped re-review), \`sdd-final-reviewer\` (whole-branch review). Each agent file sets a default model and thinking level; a host re-points any seat with \`task.agentModelOverrides\`. Never use the bundled \`task\` agent for an SDD seat: it lacks the seat's tools, output contract and no-subagent rule.
 
-omp ships a built-in task-list tool: \`todo\` (\`init\`, \`start\`, \`done\`, \`rm\`, \`drop\`, \`block\`, \`unblock\`, \`append\`, \`view\`). Use it for all task tracking. Do not track work in plan files or a repo-local \`TODO.md\`. Treat older \`TodoWrite\` references as the \`todo\` tool.`;
+omp ships a built-in task-list tool: \`todo\` (\`init\`, \`start\`, \`done\`, \`rm\`, \`drop\`, \`block\`, \`unblock\`, \`append\`, \`view\`). Use it for all task tracking. Do not track work in plan files or a repo-local \`TODO.md\`. Treat older \`TodoWrite\` references as the \`todo\` tool.
+
+From omp 18.4.12 every subagent is told to leave builds, tests and smoke runs to the main agent unless its assignment explicitly instructs them: name the checks a subagent must run in its dispatch.
+
+If your tools include \`vibe_spawn\` but not \`task\`, omp's vibe mode is on and you are its director: you have none of the \`task\`, \`bash\`, \`edit\` or \`write\` tools named above. Read the "Vibe mode" section of \`skill://using-superpowers/references/pi-tools.md\` before acting on them.`;
 }
 
 function messageContainsBootstrap(message: unknown): boolean {

package/CHANGELOG.md

@@ -6,6 +6,17 @@ A version is `<upstream version>-omp.<n>`: the upstream release this fork is syn
 
 ## [Unreleased]
 
+## [6.4.2-omp.4] - 2026-10-03
+
+### Added
+
+- **omp vibe mode support.** In `/vibe` the session is a director with `read`, `todo`, the `vibe_*` tools and any MCP tools, but no `task`, `bash`, `edit` or `write`, and its `fast` and `good` workers are the bundled `sonic` and `task` agents, not SDD seats. subagent-driven-development and executing-plans now tell a director (tools include `vibe_spawn` but not `task`) to hand the whole run to one `good` worker, which keeps the ledger and dispatches the `sdd-*` seats through its own `task` tool. Each controller brief explicitly instructs the worker to run the tests, builds and scripts the skill calls for. using-git-worktrees says vibe refuses `/move` and `/wt` and leaving vibe kills every worker, so the worktree and `/move` come first. writing-plans' handoff says both approaches run in a worker. `pi-tools.md` gains a *Vibe mode* section: the action-to-`vibe_*` table, what workers have, and the request-budget note. Checked end to end on omp 18.4.12, with the director and worker on sonnet-5-5:low and the seats on haiku-4-5:low: a single `/vibe` prompt to execute a one-task plan led the director to read executing-plans' vibe note and brief one `good` worker with both rules; the worker resolved the scripts with `realpath`, created the workspace and ledger, ran `task-start`, ran `npm test` RED then GREEN, committed, ran `task-done` and `review-package`, and dispatched `sdd-final-reviewer` through its own `task` tool; the reviewer found nothing to fix, and the director reported the branch mergeable.
+- **The injected mapping points a vibe director at that section.** Its last paragraph tells a session whose tools include `vibe_spawn` but not `task` that it is a director without the `task`, `bash`, `edit` or `write` tools the mapping names, and to read the section before acting on them. Live check 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>`.
+
+### Fixed
+
+- **Subagents on omp 18.4.12 skip their checks unless told.** From 18.4.12 every subagent's system prompt, plugin agents and vibe workers alike, carries a hand-off rule: the main agent verifies once after all subagents land, and a subagent must not verify its changes (builds, tests, linters, formatters, smoke runs) unless its assignment explicitly instructs it. 18.4.10 allowed scoped proof instead. The rule is prompt text, not a tool block. The injected mapping now tells a dispatching session to name the checks a subagent must run, and `pi-tools.md` gains a *Checks* subsection that quotes the rule and says every dispatch that needs a check names the command and when to run it. 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 to fix `sum.js` and commit ran no test; the same brief plus an explicit instruction to run `npm test` before and after the fix ran both.
+
 ## [6.4.2-omp.3] - 2026-10-02
 
 ### Fixed
@@ -60,7 +71,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/v6.4.2-omp.3...HEAD
+[Unreleased]: https://github.com/LoneExile/omp-superpowers/compare/v6.4.2-omp.4...HEAD
+[6.4.2-omp.4]: https://github.com/LoneExile/omp-superpowers/releases/tag/v6.4.2-omp.4
 [6.4.2-omp.3]: https://github.com/LoneExile/omp-superpowers/releases/tag/v6.4.2-omp.3
 [6.4.2-omp.2]: https://github.com/LoneExile/omp-superpowers/releases/tag/v6.4.2-omp.2
 [6.4.2-omp.1]: https://github.com/LoneExile/omp-superpowers/releases/tag/v6.4.2-omp.1

package/README.md

@@ -48,6 +48,8 @@ The skills drive themselves once loaded. The usual path:
 
 On omp the agent invokes a skill by reading it (`read skill://<name>`); you can also invoke one explicitly with `/skill:<name>`.
 
+**Vibe mode.** After `/vibe` the session is a director of `fast`/`good` workers and has no `task`, `bash` or file-writing tool, so it cannot run subagent-driven-development or executing-plans itself. Both skills tell it to hand the whole run to one `good` worker, which dispatches the `sdd-*` seats through its own `task` tool. Each worker brief names the tests to run, because omp 18.4.12 workers skip them otherwise. Vibe refuses `/move` and `/wt`, so create the worktree and `/move` into it first; for a long plan set `task.softRequestBudget: 0`. Details are in the *Vibe mode* section of [`pi-tools.md`](skills/using-superpowers/references/pi-tools.md).
+
 ### What subagent-driven-development does per task
 
 ```mermaid
@@ -150,13 +152,14 @@ Rules that are easy to get wrong:
 
 ## What changed from upstream
 
-- `.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
+- `.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
+- `skills/using-superpowers/references/pi-tools.md` — same, as the reference doc; it also gains a *Checks* subsection (the 18.4.12 subagent hand-off rule, and why every dispatch names its checks) and a *Vibe mode* section: what a director keeps and lacks, how skill actions map onto `vibe_*` and workers, and the worktree and request-budget limits
 - `agents/sdd-*.md` — new. Each seat's `model:` is a pin plus a role fallback (`@task` or `@slow`), and all set `readSummarize: false`. `sdd-final-reviewer` reviews the whole branch for both ways of running a plan. It reads `requesting-code-review/code-reviewer.md` at run time and applies its What to Check, Calibration, severity definitions and Critical Rules, while carrying upstream's vision-document and Declined-to-judge rules in its own body. Descriptions name roles, never models
-- `skills/subagent-driven-development/` — *Model Selection* → *Agent Selection*; fix-loop cap 5 → 3 with a round-3 escalation seat; a proven-trivial-fix route that replaces a re-review with a one-command proof; implementers run one at a time; the scripts directory resolves via `realpath skill://subagent-driven-development/scripts`; fix rounds resume the implementer with `write agent://<id>` (id ledgered) and full results are read at `agent://<id>`; task review scales with risk through `effort: "hi"`; the controller checks reviewer results; templates show omp's real `{ context, tasks: [{ agent, task, solutionSpace }] }` wire shape and the reviewers' structured fields
-- `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>`
-- `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
+- `skills/subagent-driven-development/` — *Model Selection* → *Agent Selection*; fix-loop cap 5 → 3 with a round-3 escalation seat; a proven-trivial-fix route that replaces a re-review with a one-command proof; implementers run one at a time; the scripts directory resolves via `realpath skill://subagent-driven-development/scripts`; fix rounds resume the implementer with `write agent://<id>` (id ledgered) and full results are read at `agent://<id>`; task review scales with risk through `effort: "hi"`; the controller checks reviewer results; templates show omp's real `{ context, tasks: [{ agent, task, solutionSpace }] }` wire shape and the reviewers' structured fields; one omp paragraph for vibe mode, where a director (no `task` or `bash`) hands the whole run to one `good` worker that dispatches the seats itself
+- `skills/executing-plans/` — one additive omp paragraph in *Final Review*: the `task` tool has no `model:` field, so the final review goes to `sdd-final-reviewer` (its model is what the host maps that agent to), told that no task was reviewed; it also resolves the scripts directory with `realpath` and reads full results at `agent://<id>`; one more omp paragraph for vibe mode, where a director hands the whole run to one `good` worker
+- `skills/using-git-worktrees/` — additive omp section: `/wt` is the user's one-line answer to the consent question (moves the session, carries WIP); when the agent creates the worktree itself it uses `omp worktree add` under `~/.omp/wt/` (the only place `omp worktree list`/`clear` manage), knows that command leaves uncommitted changes behind, and asks for `/move <path>` because `cd` never moves the tools' cwd. Also: clone-first falls back to a plain checkout without `node_modules` (no copy-on-write, or in-repo targets); setup and tests use the bash tool's `cwd` parameter until `/move`; `omp worktree clear --all` is warned against, since it force-removes every worktree, uncommitted work included; omp's bash rewrites a literal `git worktree add` into `omp worktree add` only without shell expansion; vibe mode refuses `/move` and `/wt`, so the worktree and `/move` come before `/vibe`, or every worker brief carries the absolute path
+- `skills/writing-plans/` — one added line in *Execution Handoff*: in vibe mode both execution approaches run in one `good` worker the director briefs, not in its own session
 - `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
@@ -191,7 +194,7 @@ gh release create "v$v" --target main --title "v$v" --notes-file /tmp/notes.md
 
 ### New omp versions
 
-Before trusting a new omp release, re-check the harness facts this fork depends on — against the **running binary**, not an npm source tree that may lag it. `~/.bun/install/global/node_modules/@oh-my-pi/pi-coding-agent/src` routinely lags `omp --version` (a 17.4.2 tree sat beside an 18.1.17 binary while this README was written, and the isolation setting had been renamed in between). The fork was last verified against omp 18.4.10. To read the exact running version's source, pack it into a temp dir: `cd "$(mktemp -d)" && npm pack @oh-my-pi/pi-coding-agent@$(omp --version | cut -d/ -f2) && tar xzf *.tgz` (source under `package/src`). The live oracles are `omp config list --json` (every setting and its default), the `task` tool's own description in a session (agent roster, item fields), a `session_init.resolvedModel` line in a subagent transcript (what actually resolved), and `grep -a` on the binary for an exact string when you need to know whether a code path exists.
+Before trusting a new omp release, re-check the harness facts this fork depends on — against the **running binary**, not an npm source tree that may lag it. `~/.bun/install/global/node_modules/@oh-my-pi/pi-coding-agent/src` routinely lags `omp --version` (a 17.4.2 tree sat beside an 18.1.17 binary while this README was written, and the isolation setting had been renamed in between). The fork was last verified against omp 18.4.10; its vibe-mode text and the subagent check rule were re-checked against 18.4.12. To read the exact running version's source, pack it into a temp dir: `cd "$(mktemp -d)" && npm pack @oh-my-pi/pi-coding-agent@$(omp --version | cut -d/ -f2) && tar xzf *.tgz` (source under `package/src`). The live oracles are `omp config list --json` (every setting and its default), the `task` tool's own description in a session (agent roster, item fields), a `session_init.resolvedModel` line in a subagent transcript (what actually resolved), and `grep -a` on the binary for an exact string when you need to know whether a code path exists.
 
 ## License
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@loneexile/omp-superpowers",
-  "version": "6.4.2-omp.3",
+  "version": "6.4.2-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/executing-plans/SKILL.md

@@ -42,6 +42,22 @@ 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.
 
+**On omp in vibe mode** (your tools include `vibe_spawn` but not `task`)
+you are the director, and you cannot execute the plan "yourself": you have
+no `bash`, `edit` or `write`. Hand the whole run to ONE `good` worker. It
+executes the plan, including the final review it dispatches to
+`sdd-final-reviewer` through its own `task` tool. Its brief tells it to
+`read skill://executing-plans` and execute `<plan>` in `<worktree>`, and
+gives two rules. First, run every test, build and script the skill calls
+for: the brief must say so explicitly, because an omp 18.4.12 worker skips
+checks unless its assignment explicitly instructs them. Second, when the
+skill says to stop and ask your human partner, end the turn with the
+question. The worker has no `todo`, so the ledger is its record. You keep
+the todo list from its ledger (`<workspace>/progress.md`), take its
+questions to your human partner, and `vibe_send` the answers. The
+worktree and budget limits are in "Vibe mode" in
+`skill://using-superpowers/references/pi-tools.md`.
+
 ## When to Use
 
 - You have a plan from superpowers:writing-plans and your human partner

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

@@ -30,6 +30,22 @@ 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.
 
+**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
+no `task` or `bash`, and the `fast` and `good` workers are not SDD seats.
+Hand the whole run to ONE `good` worker. Its brief tells it to
+`read skill://subagent-driven-development` and execute `<plan>` as the
+controller in `<worktree>`, and gives two rules. First, run every test,
+build and script the skill calls for: the brief must say so explicitly,
+because an omp 18.4.12 worker skips checks unless its assignment
+explicitly instructs them. Second, when the skill says to stop and ask
+your human partner, end the turn with the question. The worker has no
+`todo`, so the ledger is its record. It dispatches the `sdd-*` seats
+through its own `task` tool. You keep the todo list from its ledger
+(`<workspace>/progress.md`), take its questions to your human partner, and
+`vibe_send` the answers. The worktree and budget limits are in "Vibe mode"
+in `skill://using-superpowers/references/pi-tools.md`.
+
 ## When to Use
 
 ```dot

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

@@ -75,6 +75,7 @@ Rules, each measured on omp 18.4.10:
 - **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 is a separate switch, `task.isolation.enabled` (default off); subagent-driven-development dispatches its implementers one at a time and does not use it.

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

@@ -42,6 +42,38 @@ Never use the bundled `task` agent for an SDD seat: it lacks the seat's tools, o
 
 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?"**