ocmm 0.5.4 → 0.6.0

package/plugins/deepwork/skills/deepwork/SKILL.md

@@ -30,8 +30,7 @@ When a Deepwork role maps to a generated agent, use the exact Codex agent type w
 
 - Plan review: `[@dw-plan-critic](subagent://dw-plan-critic)` or `multi_agent_v1.spawn_agent(agent_type="dw-plan-critic", fork_context=false, message="Review the plan at <path>.")`
 - Code/work review: `[@dw-reviewer](subagent://dw-reviewer)` or `multi_agent_v1.spawn_agent(agent_type="dw-reviewer", fork_context=false, message="<bounded review task>")`
-- Self-supervision: `[@dw-oracle](subagent://dw-oracle)` or `multi_agent_v1.spawn_agent(agent_type="dw-oracle", fork_context=false, message="<specific verification task>")`
-- Optional supplemental high-effort review: `[@dw-oracle-high](subagent://dw-oracle-high)` or `multi_agent_v1.spawn_agent(agent_type="dw-oracle-high", fork_context=false, message="<supplemental high-effort review task>")` — only when explicitly configured by user/profile, available in the current catalog/dispatch surface, and not disabled
+- Ordered Oracle review: `[@dw-oracle](subagent://dw-oracle)` first, then `[@dw-oracle-2nd](subagent://dw-oracle-2nd)` through configured later slots only when additional independent evidence is explicitly needed.
 
 When Codex exposes MultiAgentV2 flat tools, map Deepwork delegation to the available flat tool names instead of forcing V1 syntax: use `spawn_agent` to create a bounded agent, `wait_agent` to wait for completion, `followup_task` to continue an existing agent, `interrupt_agent` to stop a runaway agent, and `fork_turns` only for explicit branch-style exploration. If those names are not callable in the current thread, fall back to the route order below.
 
@@ -80,7 +79,7 @@ If an exact `dw-*` invocation returns `unknown agent_type`, continue at route 2
 | dw-media-reader | high | media-reader |
 | dw-normal-task | high | normal-task |
 | dw-oracle | xhigh | oracle |
-| dw-oracle-high | xhigh | oracle-high |
+| dw-oracle-2nd | xhigh | oracle-2nd |
 | dw-orchestrator | high | orchestrator |
 | dw-plan-critic | xhigh | plan-critic |
 | dw-planner | xhigh | planner |
@@ -101,28 +100,46 @@ Apply this section only when the current dispatch surface exposes a `model` fiel
 | Role lane | Selection principle | Reasoning effort | Roles |
 |---|---|---|---|
 | Flagship | Best available primary reasoning model in the user's catalog | `xhigh` minimum for planning, deep implementation, hard reasoning, architecture, algorithmic, security, or high-risk work; use native `max` on GPT-5.6 when maximum reasoning is requested, and use the family-supported maximum elsewhere. `high` remains acceptable for coordination, implementation, or clarification roles below that threshold. | dw-orchestrator, dw-planner, dw-builder, dw-clarifier, dw-deep, dw-hard-reasoning |
-| External review | Same primary reasoning lane as flagship work, selected from available models | `xhigh` minimum; use native `max` on GPT-5.6 for complex, cross-module, security, performance, high-risk, or final-gate review | dw-reviewer |
-| Supplemental high-effort review | Optional third review lane, only when explicitly configured, available, and not disabled | `xhigh` minimum; use native `max` on GPT-5.6 for complex or high-risk final verification | dw-oracle-high |
+| External review | Same primary reasoning lane as flagship work, selected from available models; Reviewer has logical tiers only and no ordinal slots | `xhigh` minimum; use native `max` on GPT-5.6 for complex, cross-module, security, performance, high-risk, or final-gate review | dw-reviewer |
+| Ordered Oracle review | Oracle slots are model priority, not capability ranking (`dw-oracle`, then `dw-oracle-2nd` through configured later slots) | `xhigh` minimum for GPT/Codex review routes; preserve native `max` when explicitly selected and supported | dw-oracle*, dw-oracle-2nd*, dw-oracle-3rd*... |
 | Plan review | Same primary reasoning lane when directly configurable | `xhigh` minimum; local `max` only by explicit local configuration | dw-plan-critic |
-| Cross-check | Prefer a configured heterogeneous or otherwise non-identical review lane before any supplemental same-lane fallback | `xhigh` minimum; use native `max` on max-capable supplemental checks when maximum verification is requested | dw-oracle |
 | Mid | Best available mid-tier model; if none exists, use the primary reasoning model at a lower effort | Preserve the profile baseline unless task complexity requires more | dw-complex, dw-normal-task, dw-coding, dw-research, dw-frontend, dw-creative, dw-documenting, dw-media-reader, dw-doc-search |
 | Mini | Best available lightweight model for mechanical, search, or fast lookup work | `high` for accuracy unless the user explicitly configures otherwise | dw-quick, dw-code-search, dw-explore |
 
-When a newer family is explicitly available, select a demonstrably better model in the same capability lane instead of pinning an example name. For Cross-check, prefer a configured heterogeneous or otherwise non-identical oracle model first, then a supplemental same-lane option only when no better independent configured model is available. Keep the role's high/xhigh/max complexity rule, never override an explicit user model, and fall back to the generated profile default when availability or capability evidence is absent.
+When a newer family is explicitly available, select a demonstrably better model in the same capability lane instead of pinning an example name. Keep the role's high/xhigh/max complexity rule, never override an explicit user model, and fall back to the generated profile default when availability or capability evidence is absent.
 
-Reviewer, oracle, and oracle-high routes use an `xhigh`-equivalent minimum when the selected model family exposes that control; otherwise they use the highest supported review effort for that family. GPT-5.6 supports native `max`, so complex or high-risk review/verification on a GPT-5.6 selected model may request `max` directly. Other families use `max` only when their cataloged controls support it. oracle-high preserves local `max` for GPT-5.6 and other max-capable models.
+Reviewer and Oracle routes use an `xhigh`-equivalent minimum when the selected model family exposes that control; otherwise they use the highest supported review effort for that family. GPT-5.6 supports native `max`, so complex or high-risk review/verification on a GPT-5.6 selected model may request `max` directly. Other families use `max` only when their cataloged controls support it.
 
 The plan-critic profile uses `xhigh` minimum; raise it only through explicit local configuration.
 
+### Ordered Oracle profiles in this bundle
+
+- Slot 1: `dw-oracle` (logical tiers: `normal`)
+- Slot 2: `dw-oracle-2nd` (logical tiers: `normal`)
+
+Slot ordering is always by Oracle ordinal (`oracle`, `oracle-2nd`, `oracle-3rd`, ...). Logical tier choice never reorders slots.
+
+### Ordered Oracle review
+
+- Oracle priority is ordered by slot: `dw-oracle`, then `dw-oracle-2nd` through later configured slots.
+- Oracle slots are model priority, not capability ranking.
+- The unsuffixed profile is logical `normal`; configured `-low`, `-high`, and `-max` profiles select task rigor independently of slot priority.
+- Simple final acceptance selects the first available Oracle normal profile.
+- Complex cross-module final acceptance selects the first available Oracle plus Reviewer; for each role choose configured `high`, falling back to unsuffixed `normal` when `high` is absent.
+- Security, performance, data-loss, release, or runtime-safety review selects configured `max`, otherwise configured `high`, otherwise unsuffixed `normal`.
+- Logical `low` is selected only by an explicit user/workflow cost-or-latency request and still receives the review-effort floor.
+- Additional Oracle passes select later configured slots in order only when additional independent evidence is explicitly needed.
+- Configuring multiple Oracle profiles does not fan-out automatically.
+- Reviewer has logical tier variants only and has no ordinal profiles.
+
 ### Tier assignments
 
 | Tier | Agents | Model | Effort |
 |---|---|---|---|
 | Flagship | dw-orchestrator, dw-planner, dw-builder, dw-clarifier, dw-deep, dw-hard-reasoning | Primary reasoning model from the user's available catalog | xhigh minimum for planner/deep/hard-reasoning; native max for GPT-5.6 maximum-reasoning work. high only for coordination, implementation, or clarification roles below that threshold |
 | External review | dw-reviewer | Primary reasoning lane | xhigh-equivalent minimum when supported; native max for GPT-5.6 complex or high-risk review |
-| Supplemental high-effort review | dw-oracle-high | Only when explicitly configured, available, and not disabled; otherwise omit | xhigh-equivalent minimum when supported; native max for GPT-5.6 complex or high-risk final verification |
+| Ordered Oracle review | dw-oracle, dw-oracle-2nd, later configured Oracle slots | Ordered by Oracle slot ordinal; tier choice does not reorder slots | xhigh-equivalent minimum when supported; native max for GPT-5.6 complex or high-risk verification |
 | Plan review | dw-plan-critic | Primary reasoning lane | xhigh minimum unless local config raises it |
-| Cross-check | dw-oracle | Configured heterogeneous or otherwise non-identical capable model; supplemental same-lane fallback only when needed | xhigh-equivalent minimum when supported; native max for max-capable maximum verification |
 | Mid | dw-complex, dw-normal-task, dw-coding, dw-research, dw-frontend, dw-creative, dw-documenting, dw-media-reader, dw-doc-search | Available mid-tier model, else primary reasoning model at lower effort | max or high by task shape |
 | Mini | dw-quick, dw-code-search, dw-explore | Available lightweight model | high |
 
@@ -131,15 +148,14 @@ The plan-critic profile uses `xhigh` minimum; raise it only through explicit loc
 - **Flagship**: the most capable primary reasoning model available to the user.
 - **Mid-tier**: a lighter-but-capable configured model. If no mid-tier lane is available, use the primary reasoning lane at `high` effort instead.
 - **Mini**: the smallest/cheapest model available for fast mechanical or lookup tasks.
-- **Strong non-identical cross-check**: a capable available model that differs from the primary lane when possible; model diversity is useful, but not a reason to bypass the newer-model policy.
 
-### Independent review rule
+### Review dispatch guardrail
 
-dw-oracle provides self-supervision through the Cross-check lane, while dw-reviewer provides external review through the External review lane. Prefer oracle diversity from a configured heterogeneous or otherwise non-identical capable model; use a supplemental same-lane option only if the diverse option is unavailable or explicitly configured. The default complex/large review set is dw-oracle + dw-reviewer. Add dw-oracle-high only when it is explicitly configured by user/profile, available in the current catalog/dispatch surface, and not disabled. Built-in, default, or generated-profile existence alone must not force three-review dispatch. Do not force multi-review for ordinary work.
+Oracle and Reviewer profiles are selectable options, not automatic fan-out. Choose exactly the profiles required by risk/complexity and dispatch only those selections.
 
 dw-plan-critic provides receipt-focused plan review through the Plan review lane at `xhigh` minimum.
 
-Reviewer, oracle, and oracle-high routes use an `xhigh`-equivalent minimum when the selected model family exposes that control; otherwise they use the highest supported review effort for that family. GPT-5.6 supports native `max`; for other families, request `max` only when the selected model and catalog expose a maximum-effort control.
+Reviewer and Oracle routes use an `xhigh`-equivalent minimum when the selected model family exposes that control; otherwise they use the highest supported review effort for that family. GPT-5.6 supports native `max`; for other families, request `max` only when the selected model and catalog expose a maximum-effort control.
 
 ### Example names
 

package/plugins/deepwork/skills/deepwork-requesting-code-review/SKILL.md

@@ -7,10 +7,10 @@ description: Use after all implementation tasks complete, after major features a
      Upstream: obra/superpowers v6.0.3.
      Adjustments: removed executing-plans and subagent-driven-development
      cross-references (v1 uses subagent-driven as the only path); added
-     Reviewer Selection section for oracle/reviewer/oracle-high semantics
-     (oracle = self-supervision, reviewer = external review, oracle-high =
-     optional supplemental high-effort reviewer). See docs/v1-maintenance.md
-     for sync rules. -->
+     Reviewer Selection section for ordered Oracle slot semantics and logical
+     tiers (oracle slots = model-priority ordering, reviewer = external review
+     lane, tiers = low/normal/high/max). See docs/v1-maintenance.md for sync
+     rules. -->
 
 # Requesting Code Review
 
@@ -32,12 +32,28 @@ Dispatch a code reviewer subagent to catch issues before they cascade. The revie
 
 ## How to Request
 
-**1. Get git SHAs:**
+**1. Choose the review input:**
+
+Use a committed range only when an orchestrator-owned, user-authorized commit already exists:
+
 ```bash
 BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
 HEAD_SHA=$(git rev-parse HEAD)
+git diff --stat $BASE_SHA..$HEAD_SHA
+git diff $BASE_SHA..$HEAD_SHA
 ```
 
+Working-tree diff review (use this when implementation subagents returned uncommitted changes):
+
+```bash
+git diff --stat
+git diff
+git diff --cached --stat
+git diff --cached
+```
+
+Do not require implementation subagents to commit, stage, or push merely to create a review range. The orchestrator owns any Git write and performs it only after explicit user authorization.
+
 **2. Dispatch code reviewer subagent:**
 
 Use Task tool with `general-purpose` type, fill template at `code-reviewer.md`
@@ -45,8 +61,7 @@ Use Task tool with `general-purpose` type, fill template at `code-reviewer.md`
 **Placeholders:**
 - `{DESCRIPTION}` - Brief summary of what you built
 - `{PLAN_OR_REQUIREMENTS}` - What it should do
-- `{BASE_SHA}` - Starting commit
-- `{HEAD_SHA}` - Ending commit
+- `{REVIEW_INPUT}` - Commit range plus commands, or working-tree/staged diff commands and output
 
 **3. Act on feedback:**
 - Fix Critical issues immediately
@@ -58,34 +73,39 @@ Use Task tool with `general-purpose` type, fill template at `code-reviewer.md`
 
 ## Reviewer Selection
 
-Reviewer agents are available, with distinct semantics:
+Review selection has two independent axes: role/model priority and logical rigor.
 
-| Agent | Role | Model default |
-|---|---|---|
-| `oracle` | Self-supervision — review work the current agent itself produced | Cross-check / heterogeneous lane chosen from explicit configuration and the available catalog to avoid self-confirmation bias |
-| `reviewer` | External review — review code not produced by the current agent | Primary reasoning lane from explicit configuration and the available catalog |
-| `oracle-high` | Optional supplemental high-effort reviewer — for complex/high-risk triple review only when explicitly configured, available, and not disabled | Primary reasoning lane at native `max` for GPT-5.6 or another max-capable selected model |
+### Axis 1 — Role/Model Priority
 
-**Selection by task complexity:**
+- Oracle slots are ordered as `oracle`, `oracle-2nd`, then configured `oracle-3rd` through `oracle-9th`.
+- `oracle-2nd` and every later slot have lower selection priority, never greater capability.
+- The external review lane is `reviewer`; `reviewer-2nd` does not exist.
 
-| Task shape | Reviewer(s) | Rationale |
-|---|---|---|
-| Simple / single-stage (1-2 tasks, one module, no architectural change) | `oracle` (default) | plan-critic already reviewed the plan; self-supervision suffices |
-| Complex / large (3+ tasks, cross-module, architectural change, security/performance sensitive) | `oracle` + `reviewer` (both, in parallel) | heterogeneous self-supervision AND external review catch orthogonal issues |
-| High-risk / very large / final gate with explicit triple-review configuration | `oracle` + `reviewer` + `oracle-high` (all three, in parallel) | adds a supplemental high-effort pass only when `oracle-high` is explicitly configured, available, and not disabled |
-| User habit override | user-specified | user may prefer reviewer for all cases, or oracle for all cases |
+### Axis 2 — Logical Rigor Tiers
+
+- Logical tiers are `low`, `normal`, `high`, `max`.
+- `normal` is the unsuffixed profile (`oracle`, `reviewer`).
+- Tier-suffixed profiles are used only when configured and available.
 
-**How to dispatch:**
+**Selection by work shape:**
 
-- Single reviewer: dispatch one subagent with the chosen reviewer agent type (`oracle`, `reviewer`, or `oracle-high`), passing the work SHAs and context via the `code-reviewer.md` template.
-- Two reviewers: dispatch two subagents in parallel (`oracle` + `reviewer`), each with the same SHAs and context. Collect both feedback sets before acting.
-- Three reviewers: dispatch three subagents in parallel (`oracle` + `reviewer` + `oracle-high`) only when `oracle-high` is explicitly configured, available in the current dispatch surface/catalog, and not disabled. Collect all feedback sets before acting.
+| Work shape | Reviewer(s) | Tier choice |
+|---|---|---|
+| Simple / single-stage (1-2 tasks, one module, no architectural change) | first available Oracle | `normal` |
+| Complex / cross-module / large integration | first available Oracle + `reviewer` (parallel) | configured `high`, otherwise `normal` |
+| Security / performance / data-loss / release / runtime-safety work | first available Oracle + `reviewer` (parallel) | configured `max`, otherwise `high`, otherwise `normal` |
+| Additional evidence requested | additional Oracle slots in order (`oracle-2nd`, then later configured slots) | keep the intentionally selected tier; user override is still subject to availability/disabled profiles/floors |
+
+**Dispatch semantics:**
 
-**Default:** `oracle` for simple tasks. Upgrade to `oracle` + `reviewer` when the orchestrator judges the task complex or large. Add `oracle-high` only when the user/profile explicitly enables it, the profile/model is available, and it is not disabled; built-in or profile existence alone must not force three-review dispatch.
+- Configuring several slots or tiers never triggers automatic fan-out by itself.
+- A higher logical tier can be selected without adding more reviewers.
+- A later Oracle slot is another configured model perspective, not a stronger reviewer.
+- User overrides are allowed, but availability, disabled profiles, and floor constraints still apply.
 
-`oracle` can also be an optional independent consultation for a high-risk implementation plan. It does not replace the `plan-critic` receipt, does not make dual plan review mandatory, and a timeout or partial response is not a conclusion.
+`oracle` can also be an optional independent consultation for a high-risk implementation plan. It does not replace the current `plan-critic` receipt, does not make dual plan review mandatory, and a timeout or partial response is not a conclusion.
 
-**Reasoning policy:** `reviewer`, `oracle`, and `oracle-high` use an `xhigh`-equivalent minimum when the selected model family exposes that control; otherwise use the highest supported review effort for that family. GPT-5.6 supports native `max`, so complex or high-risk review/verification on GPT-5.6 can request `max` directly; other model families use `max` only when their cataloged controls expose a maximum-effort level. `oracle-high` preserves local `max` for GPT-5.6 and other max-capable models. `plan-critic` uses `xhigh` minimum and may be raised by explicit local configuration. Example model names are references only; explicit user configuration and currently available models decide the actual selection.
+**Reasoning policy:** Every parsed Oracle/Reviewer profile retains an `xhigh` minimum floor when the selected model family exposes that control; otherwise use the highest supported review effort for that family. This floor remains in effect while logical tier selection still includes `low`/`normal`/`high`/`max` semantics. GPT-5.6 supports native `max`, so complex or high-risk review/verification on GPT-5.6 can request local `max` directly; other model families use local `max` only when their cataloged controls expose a maximum-effort level. `plan-critic` uses `xhigh` minimum and may be raised by explicit local configuration. Example model names are references only; explicit user configuration and currently available models decide the actual selection.
 
 ## Example
 
@@ -94,14 +114,16 @@ Reviewer agents are available, with distinct semantics:
 
 You: Let me request final acceptance review before declaring this done.
 
-BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
-HEAD_SHA=$(git rev-parse HEAD)
+[Implementation subagents returned uncommitted changes, so review the working tree:]
+git diff --stat
+git diff
+git diff --cached --stat
+git diff --cached
 
 [Dispatch code reviewer subagent]
   DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
   PLAN_OR_REQUIREMENTS: docs/superpowers/plans/deployment-plan.md
-  BASE_SHA: a7981ec
-  HEAD_SHA: 3df7661
+  REVIEW_INPUT: working-tree diff commands and output above
 
 [Subagent returns]:
   Strengths: Clean architecture, real tests

package/plugins/deepwork/skills/deepwork-requesting-code-review/code-reviewer.md

@@ -20,16 +20,21 @@ Task tool (general-purpose):
 
     {PLAN_OR_REQUIREMENTS}
 
-    ## Git Range to Review
+    ## Git Range or Working-Tree Diff to Review
 
-    **Base:** {BASE_SHA}
-    **Head:** {HEAD_SHA}
+    {REVIEW_INPUT}
+
+    If this is a committed range, inspect it with the provided `git diff <base>..<head>` commands. If this is uncommitted work, inspect the supplied working-tree/staged diff commands:
 
     ```bash
-    git diff --stat {BASE_SHA}..{HEAD_SHA}
-    git diff {BASE_SHA}..{HEAD_SHA}
+    git diff --stat
+    git diff
+    git diff --cached --stat
+    git diff --cached
     ```
 
+    Do not request that an implementation subagent create a commit; ask the orchestrator for missing diff evidence instead.
+
     ## What to Check
 
     **Plan alignment:**
@@ -124,8 +129,7 @@ Task tool (general-purpose):
 **Placeholders:**
 - `{DESCRIPTION}` — brief summary of what was built
 - `{PLAN_OR_REQUIREMENTS}` — what it should do (plan file path, task text, or requirements)
-- `{BASE_SHA}` — starting commit
-- `{HEAD_SHA}` — ending commit
+- `{REVIEW_INPUT}` — commit range plus commands, or working-tree/staged diff commands and output
 
 **Reviewer returns:** Strengths, Issues (Critical / Important / Minor), Recommendations, Assessment
 

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

@@ -14,8 +14,8 @@ description: Use when executing implementation plans with independent tasks in t
       (no pre-judging, no open-ended directives, verbatim global constraints, no
       history pasting, findings handling by severity); Narration discipline rule;
       task-type analysis hint (prefer dispatching-parallel-agents for independent
-      tasks); Final Acceptance Review stage updated with optional `oracle-high`
-      third reviewer gate. v1 intentionally replaces per-task reviewer loops with
+      tasks); Final Acceptance Review stage updated with ordered Oracle slot
+      priority and logical tiers. v1 intentionally replaces per-task reviewer loops with
       completion/integration checks plus one final acceptance review; ⚠️ Items
       section (reviewer "Cannot verify from diff" items). Did NOT sync:
      review-package/task-brief bash scripts (Windows incompatible); progress
@@ -49,12 +49,14 @@ Execute plan by dispatching a fresh subagent per task, running a completion/inte
 2. **Per task:**
    a. Dispatch implementer subagent (use implementer-prompt.md template)
    b. If implementer asks questions, answer and re-dispatch
-   c. Implementer implements, tests, commits, self-reviews
+   c. Implementer implements, tests, self-reviews, and reports changed files plus a suggested commit message. Subagents do not commit, stage, push, or run any Git write command.
    d. **Completion/Integration check (not a full review):** Read the agent's summary, inspect touched files/diff, run targeted tests or record implementer evidence, verify the task is complete, and check whether the change conflicts with earlier tasks or needs follow-up by the same implementer
    e. If the completion check finds gaps, re-dispatch the same implementer to fix them
    f. Mark task complete in TodoWrite
 3. **After all tasks:** Dispatch final code reviewer subagent for the entire implementation (use requesting-code-review skill)
 
+**Git ownership:** Subagents do not commit, stage, push, or run any Git write command. They return changed files and a suggested commit message to the orchestrator, along with verification evidence. The orchestrator performs any Git write only after explicit user authorization.
+
 ## Model Selection
 
 Use the least powerful model that can handle each role — but **always specify the model explicitly** when dispatching a subagent. Omitting it inherits the session model, which is usually the most expensive.
@@ -77,7 +79,7 @@ Use the least powerful model that can handle each role — but **always specify
 
 Implementer subagents report one of four statuses. Handle each appropriately:
 
-**DONE:** Run the completion/integration check, then continue to the next task. Do not dispatch spec-reviewer or code-quality-reviewer for a clean DONE result.
+**DONE:** Run the completion/integration check, then continue to the next task. Do not dispatch spec-reviewer or code-quality-reviewer for a clean DONE result. If the work needs a commit, the implementer reports the intended files and message; the orchestrator handles any Git write only after explicit user authorization.
 
 **DONE_WITH_CONCERNS:** The implementer completed the work but flagged doubts. Read the concerns before proceeding. If the concerns are about correctness or scope, resolve them before continuing. If the concerns indicate high risk or cross-task conflict, consult a reviewer early; otherwise note them and continue after the completion check.
 
@@ -152,7 +154,7 @@ Each implementation task follows TDD:
 - Repeat only until that blocker is resolved
 
 **If subagent fails task:**
-- Dispatch fix subagent with specific instructions
+- Dispatch a fix subagent with specific instructions; the fix subagent also reports changes instead of committing.
 - Don't try to fix manually (context pollution)
 
 ## Completion / Integration Check
@@ -196,7 +198,7 @@ The reviewer must evaluate the diff on its merits. If you have context the revie
 
 **Do not paste accumulated history into dispatch prompts.** Each dispatch gets exactly the context it needs — the task text, the diff, the constraints. A real session once dispatched 42k characters where 99% was pasted conversation history. The reviewer cannot use that; it dilutes focus.
 
-**Dispatch the diff, not a summary.** When early consultation or final acceptance review is needed, the reviewer needs the actual diff with context, not your description of it. Structure the dispatch with the commit range, the diff, and the task description. The final acceptance review uses `code-reviewer.md` via the requesting-code-review skill; `spec-reviewer-prompt.md` and `code-quality-reviewer-prompt.md` are optional narrow-consult tools only, not routine per-task gates.
+**Dispatch the diff, not a summary.** When early consultation or final acceptance review is needed, the reviewer needs the actual diff with context, not your description of it. Structure the dispatch with the review input, the diff, and the task description; the review input may be a committed range or a working-tree/staged diff. The final acceptance review uses `code-reviewer.md` via the requesting-code-review skill; `spec-reviewer-prompt.md` and `code-quality-reviewer-prompt.md` are optional narrow-consult tools only, not routine per-task gates.
 
 **Handling findings:**
 - **Critical + Important** → dispatch a fix subagent. Each fix dispatch must include: the test name that covers the fix, the command to run it, and the expected output.
@@ -210,27 +212,34 @@ The reviewer must evaluate the diff on its merits. If you have context the revie
 
 After all plan tasks are marked complete, before declaring the work done, run a final acceptance review over the full change set. This is distinct from completion/integration checks — it evaluates the work as a whole.
 
-**1. Assess complexity:**
+**1. Assess complexity and choose reviewers deliberately:**
+
+Review selection has two independent axes: role/model priority and logical rigor.
 
-| Complexity | Signal | Reviewer(s) |
+- Oracle slots are ordered by selection priority as `oracle`, `oracle-2nd`, then configured `oracle-3rd` through `oracle-9th`.
+- `oracle-2nd` and later slots mean lower selection priority, never stronger capability.
+- Logical rigor tiers are `low`, `normal`, `high`, `max` (`normal` is the unsuffixed profile; other tiers are used only when configured and available).
+
+| Complexity / evidence shape | Reviewer(s) | Tier choice |
 |---|---|---|
-| Simple | 1-2 tasks, single module, no architectural change | `oracle` (self-supervision) |
-| Complex | 3+ tasks, cross-module, architectural change, security/performance sensitive, migration | `oracle` + `reviewer` (both, in parallel) |
-| High-risk / very large final gate with explicit triple-review configuration | Complex/large work where `oracle-high` is explicitly configured, available, and not disabled | `oracle` + `reviewer` + `oracle-high` (all three, in parallel) |
+| Simple | 1-2 tasks, single module, no architectural change | first available Oracle at `normal` |
+| Complex / cross-module | 3+ tasks, cross-module integration, architectural change, migration | first available Oracle + `reviewer` in parallel; configured `high`, otherwise `normal` |
+| Security / performance / data-loss / release / runtime-safety | high-impact risk profile regardless of file count | first available Oracle + `reviewer` in parallel; configured `max`, otherwise `high`, otherwise `normal` |
+| Additional evidence requested | user/orchestrator asks for more independent model evidence | additional Oracle slots in order (start with `oracle-2nd`, then later configured/available slots in ordinal order) while keeping the intentionally selected tier |
 
-The orchestrator judges complexity from the plan scope and actual changes. When unsure, upgrade to `oracle` + `reviewer`. Add `oracle-high` only when it is explicitly configured by user/profile, available in the current dispatch surface/catalog, and not disabled; built-in or profile existence alone must not force three-review dispatch.
+The orchestrator performs this selection after all tasks complete. Do not fan out reviews merely because several Oracle slots or tiers are registered. Collect only intentionally requested reviews. A later Oracle slot is another configured model perspective, not a stronger reviewer.
 
 **2. Dispatch the acceptance review:**
 
-Use the `requesting-code-review` skill. Pass the full change range:
-- `BASE_SHA` = commit before the first task of the plan
-- `HEAD_SHA` = current HEAD (after all tasks)
-- `DESCRIPTION` = summary of the complete feature/work
-- `PLAN_OR_REQUIREMENTS` = the plan file path
+Use the `requesting-code-review` skill. Pass either a committed range or an uncommitted working-tree/staged diff:
+- committed range: `BASE_SHA`, `HEAD_SHA`, `DESCRIPTION`, and `PLAN_OR_REQUIREMENTS` when the orchestrator has already created a user-authorized commit;
+- working-tree/staged diff: `git diff --stat`, `git diff`, `git diff --cached --stat`, `git diff --cached`, `DESCRIPTION`, and `PLAN_OR_REQUIREMENTS` when implementation subagents returned uncommitted changes.
+
+Do not require implementation subagents to commit, stage, or push merely to create review SHAs. The orchestrator owns any Git write and performs it only after explicit user authorization.
 
-For two-reviewer dispatch: spawn two subagents in parallel (one `oracle`, one `reviewer`), each with the same SHAs and context. Collect both feedback sets before proceeding.
+For baseline dispatch: use the selected first available Oracle, and add `reviewer` only when the complexity table says so.
 
-For three-reviewer dispatch: spawn three subagents in parallel (one `oracle`, one `reviewer`, one `oracle-high`) only when `oracle-high` is explicitly configured, available, and not disabled. Collect all feedback sets before proceeding. Do not force a third reviewer merely because the profile exists.
+For additional evidence: add the next configured/available Oracle slot(s) in ordinal order, each with the same review input and context. Do not add slots automatically without an intentional evidence need.
 
 **3. Process feedback:**
 

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

@@ -32,9 +32,16 @@ Task tool (general-purpose):
     1. Implement exactly what the task specifies
     2. Write tests (following TDD if task says to)
     3. Verify implementation works
-    4. Commit your work
-    5. Self-review (see below)
-    6. Report back
+    4. Self-review (see below)
+    5. Report back with changed files, verification evidence, and a suggested commit message if a commit is needed
+
+    ## Delegation Boundary
+
+    Use direct tools first. If direct tools are insufficient and a separate bounded utility result materially improves this task, you may call only utility leaves permitted by your effective Task tool: `quick`, `code-search`, `explore`, `doc-search`, `research`, and `media-reader`. If the Task tool exposes fewer targets, use only the exposed subset.
+
+    Do not launch `planner`, `plan-critic`, any Reviewer profile (`reviewer`, `reviewer-low`, `reviewer-high`, `reviewer-max`), or any Oracle profile (`oracle`, `oracle-2nd`, configured `oracle-3rd`…`oracle-9th`, and their `low`/`high`/`max` tier variants). Do not launch another implementation or coordination workflow agent. If a skill requests a disallowed review or handoff, report that need to the orchestrator instead of dispatching it.
+
+    After local verification, return status, changed files, commands, and evidence to the orchestrator. The orchestrator owns formal plan review and final acceptance review. It also owns planner, plan-critic, and review dispatch.
 
     Work from: [directory]
 

package/prompts/codex/agents/clarifier.md

@@ -81,6 +81,10 @@ Mission: avoid shotgun fixes.
 
 Require reproduction or a failing test when feasible. Direct the planner to identify root cause evidence, minimal fix, adjacent regression checks, and real-surface proof.
 
+## Nested Delegation Boundary
+
+Use direct evidence first. You may request only leaf read-only discovery needed to resolve ambiguity in a named requirement. Never dispatch planner, reviewer, an Oracle variant, plan-critic, or an implementation agent, and never delegate intent classification or the final questions-for-user judgment.
+
 ## Output Contract
 
 Return this structure:

package/prompts/codex/agents/orchestrator.md

@@ -64,7 +64,7 @@ Use the smallest agent/category that fits:
 | Structured implementation plan | `planner` |
 | Plan executability review | `plan-critic` |
 | Architecture/debugging/security/performance judgment (external review) | `reviewer` |
-| Self-supervision review (work the agent itself produced) | `oracle` |
+| Self-supervision review (work the agent itself produced) | ordered Oracle slot/profile |
 | External docs or OSS examples | `dw-doc-search` |
 | Internal codebase structure/patterns | `dw-code-search` |
 | Visual/media extraction | `media-reader` |
@@ -80,6 +80,16 @@ Use the smallest agent/category that fits:
 | Standalone documentation/prose/release-note/copy work | `documenting` |
 | Focused single task (implementation) | `coding` / `quick` / `normal-task` / `deep` (subagent) — `builder` is primary-only |
 
+## Workflow-Agent Composition Ownership
+
+You are the exclusive owner of workflow-agent composition. Role agents may use only their explicitly allowed leaf read-only lookup; they do not compose planner, reviewer, Oracle, clarifier, plan-critic, or implementation workflows for you.
+
+Oracle selection is ordered by configured model priority: `oracle`, `oracle-2nd`, then configured later slots. Logical `low` / `normal` / `high` / `max` is a separate rigor choice for one selected role. Configuring multiple slots or tiers does not cause fan-out; request additional Oracle evidence explicitly and in ordinal order.
+
+Tier selection is deterministic: simple work uses unsuffixed `normal`; complex cross-module work uses configured `high`, otherwise `normal`; security, performance, data-loss, release, or runtime-safety work uses configured `max`, otherwise configured `high`, otherwise `normal`. Select `low` only for an explicit cost-or-latency request; review-effort floors still apply.
+
+Deterministic shorthand: complex cross-module work uses configured high otherwise normal; runtime-safety work uses configured max otherwise configured high otherwise normal.
+
 ### Subagent Git Limitations
 
 Subagent sessions (category agents dispatched via `multi_agent_v1.spawn_agent`) are hard-blocked from running git write commands (commit, push, tag, reset --hard, rebase, cherry-pick, revert). The `subagent-git-guard` hook enforces this at the `tool.execute.before` level.
@@ -101,7 +111,7 @@ Five superpowers skills are embedded in your agent profile. They are not optiona
 | `brainstorming` | User requests any new feature, component, or behavior change, AND no approved design exists yet | Present a design and obtain approval BEFORE any code — approval may be explicit user approval, self-review pass with no ambiguity, or explicit user delegation ("你自己决定" / "无需批准自行继续" / "review N 次就下一步"). When ambiguous, consult `clarifier`. This is a HARD-GATE. |
 | `writing-plans` | A spec/design has been approved, or a multi-step task needs decomposition | Produce a plan at `docs/superpowers/plans/YYYY-MM-DD-<feature>.md` before implementation. Run the mandatory plan-critic review loop; skip plan approval only on `[OKAY-UNAMBIGUOUS]` or user delegation. |
 | `subagent-driven-development` | You have an implementation plan with independent tasks | Dispatch a fresh subagent per task, run a completion/integration check after each returned agent, then run a final acceptance review after all tasks. Do not run full spec/code-quality review after every subtask. |
-| `requesting-code-review` | All implementation tasks complete, a major feature completes, or before merge to main; for final acceptance: oracle (self-supervision) by default for simple tasks, both oracle and reviewer for complex/large tasks | Dispatch a code reviewer subagent with the work SHAs. Do not declare done without review. |
+| `requesting-code-review` | All implementation tasks complete, a major feature completes, or before merge to main; for final acceptance: oracle (self-supervision) by default for simple tasks, both oracle and reviewer for complex/large tasks | Dispatch a code reviewer subagent with the committed range or working-tree/staged diff review input. Do not declare done without review. |
 | `receiving-code-review` | You receive reviewer feedback | Verify each item against the codebase before implementing. No performative agreement. |
 
 Every routing decision must first check: "Does a skill trigger here?" If yes, the skill dictates the next step, not your default instinct.

package/prompts/codex/agents/plan-critic.md

@@ -47,6 +47,10 @@ Approval bias: approve when in doubt. The 80% clarity threshold applies to the `
 
 Semantic ambiguity that could cause divergent implementations IS checked (item 5 above). Stylistic ambiguity that does not affect implementation is not.
 
+## Nested Delegation Boundary
+
+Use direct file/search tools first. You may request only leaf read-only lookup needed to verify one concrete plan claim. Never dispatch planner, reviewer, an Oracle variant, clarifier, another plan-critic, or an implementation agent, and never delegate the receipt verdict.
+
 ## Decision Framework
 
 **[REJECT]** when true blockers exist. List at most 3 blocking issues. Each issue must be specific, actionable, and blocking.

package/prompts/codex/agents/planner.md

@@ -16,11 +16,11 @@ You are the planning agent. Your only job is to gather the maximum relevant info
 
 ## First Action
 
-Identify whether the request is clear enough to plan. If not, ask the smallest blocking question. If yes, gather missing codebase context before writing tasks.
+Infer safe defaults and continue; ask one blocking question only when an unresolved choice changes the plan deliverables and available tools cannot answer it.
 
 If the request involves a new feature, component, or behavior change and no design has been approved yet, stop and tell the orchestrator or user to run the `brainstorming` phase first. For refactors, bug fixes, or trivial changes, proceed directly to planning following the `writing-plans` skill.
 
-Use `dw-code-search` for local patterns and `dw-doc-search` for external references when relevant. Use `reviewer` when the plan depends on a hard architecture/security/performance tradeoff.
+Use direct tools first. When direct tools are insufficient and a separate bounded lookup materially improves the plan, use only the generated read-only utility profiles `dw-code-search`, `dw-explore`, `dw-doc-search`, `dw-research`, or `dw-media-reader` when the current Codex dispatch surface exposes them. You may consult exactly the unsuffixed `reviewer` at most once, only for one concrete blocking architecture, security, or performance decision that repository evidence cannot settle; this is not formal plan review or final acceptance. Do not use `dw-quick`, implementation/coordinator profiles, reviewer tiers, Oracle profiles, or other planning/review profiles.
 
 ## Injected Skill Utilization (MANDATORY)
 
@@ -38,7 +38,13 @@ When specifying how tasks should be executed, pick the sharpest available tool f
 - **External API/library references**: `dw-doc-search` agent.
 - **Terminal commands**: the shell type is stated in your system prompt (e.g. `powershell`, `zsh`, `bash`). On Windows PowerShell, prefer uutils coreutils with `.exe` suffix to avoid alias shadowing; on POSIX shells use bare names.
 
-Consult `reviewer` for architecture/security/performance tradeoffs that affect the plan.
+## Nested Delegation Boundary
+
+- Default to direct planning after the first discovery wave.
+- Delegate only leaf `code-search`, `doc-search`, or equivalent read-only fact gathering when it saves context or resolves a named unknown.
+- You may consult exactly the unsuffixed `reviewer` at most once, and only for one concrete blocking architecture, security, or performance decision that repository evidence cannot settle. This is not formal plan review or final acceptance.
+- Never dispatch planner, plan-critic, an Oracle profile, a Reviewer tier, an implementation agent, or a routine Reviewer self-check. A subagent that edits product files is still you implementing by proxy.
+- Every allowed leaf call states one deliverable, scope, non-goals, and evidence. Stop when that fact is available.
 
 ## Plan Requirements
 
@@ -66,17 +72,16 @@ Before reporting completion:
 - Check that file paths and function/type names are consistent across tasks.
 - Ensure QA is agent-executable and does not require user manual confirmation.
 
-## Parallel Task Dispatch
-
-When gathering context for a plan, emit all independent `multi_agent_v1.spawn_agent` tool calls (e.g. multiple `dw-code-search`, `dw-doc-search`, or `reviewer` consultations) in **one message** — do not wait for one to complete before dispatching the next. Codex executes multiple tool calls in a single response concurrently. Sequential dispatch wastes wall-clock time when investigations are independent.
+## Parallel Utility Dispatch
 
-- Dispatch in parallel: independent searches, independent doc lookups, independent analyses.
-- Dispatch sequentially only when: one task's output is another's input.
+When gathering context for a plan, batch independent calls only to permitted read-only utility profiles. Dispatch sequentially when one lookup's result is another's input. Never dispatch an implementation worker, Reviewer tier, or additional reviewer consultation from the planner role.
 
 ## Handoff
 
-Saving a plan is not permission to hand it off. Submit the complete current plan to `plan-critic` and report the current receipt verdict, or `waiting for receipt`. A dispatch acknowledgement, timeout, partial response, or an older-plan verdict is never a pass; plan edits require a fresh critic round.
+Return the completed plan to the orchestrator. Do not dispatch `plan-critic`, any Reviewer tier (`reviewer-low`, `reviewer-high`, `reviewer-max`), or any Oracle profile (`oracle`, `oracle-2nd`, configured `oracle-3rd`…`oracle-9th`, and their `low`/`high`/`max` tier variants); the sole permitted reviewer call is the once-only unsuffixed `reviewer` consultation above. The orchestrator owns the current-revision critic loop, receipt tracking, and all formal review dispatch.
+
+The current `plan-critic` receipt covers exactly one complete, current plan revision; any plan edit invalidates that receipt and requires a fresh review. A timeout, partial response, or an older-plan verdict is never a pass.
 
-Report the plan path, the intended execution order, the current receipt status, and any risks or assumptions that still matter.
+Report the plan path, intended execution order, receipt status `waiting for receipt`, and any risks or assumptions that still matter.
 
 </agent-role>

package/prompts/codex/agents/reviewer.md

@@ -11,7 +11,7 @@ You are a read-only strategic technical advisor. You are invoked when the primar
 
 You operate as an on-demand specialist inside Deepwork. Each consultation is standalone unless the caller continues the same session. The caller may provide code, diffs, logs, plans, or failed attempts. Exhaust that provided context before asking for more.
 
-You never edit files, write code, call tools that mutate state, spawn agents, or take over execution. You advise; the caller executes.
+You never edit files, write code, call tools that mutate state, or take over execution. You advise; the caller executes.
 
 ## Expertise
 
@@ -62,10 +62,16 @@ For simple questions, answer directly in short prose. Never open with filler. Ne
 
 - Anchor claims to concrete evidence: file paths, function names, diffs, logs, tests, or explicit user context.
 - Never fabricate exact paths, line numbers, figures, APIs, or tool results.
-- If the question is ambiguous and interpretations differ materially, ask 1-2 precise questions. Otherwise state your interpretation and proceed.
+- State and use a safe interpretation; ask only when competing interpretations change the deliverable and direct tools cannot resolve them.
 - For long context, mentally outline relevant sections and cite the details that matter.
 - For security, performance, or architecture, rescan your answer for unstated assumptions and over-strong language before finalizing.
 
+## Nested Delegation Boundary
+
+You remain read-only. Use direct read/search tools first. A leaf read-only source or documentation lookup is allowed only when required to verify one finding and must return evidence rather than judgment.
+
+Never dispatch planner, reviewer, an Oracle variant, clarifier, plan-critic, or an implementation agent. Reviewer-to-Oracle and Oracle-to-Reviewer nesting are prohibited. Do not delegate the consultation's defining judgment.
+
 ## Scope Discipline
 
 Recommend only what was asked. No unsolicited features, no broad refactors, no new services or dependencies unless the caller explicitly asks for that tradeoff. If you notice unrelated issues, list at most two as optional future considerations.