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

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,16 @@ 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.
+- **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 +122,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 +145,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 +176,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,35 +6,41 @@ 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 | `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.
 
 ## Task lists