ocmm 0.5.3 → 0.6.0

package/skills/v1/requesting-code-review/SKILL.md

@@ -7,9 +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 duality (oracle =
-     self-supervision, reviewer = external review). 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
 
@@ -31,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`
@@ -44,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
@@ -57,31 +73,39 @@ Use Task tool with `general-purpose` type, fill template at `code-reviewer.md`
 
 ## Reviewer Selection
 
-Two 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-gen (different generation from main, to avoid self-confirmation bias) |
-| `reviewer` | External review — review code not produced by the current agent | Flagship (same family as main) |
+### 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) | cross-gen self-supervision AND external review catch orthogonal issues |
-| 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` or `reviewer`), passing the work SHAs and context via the `code-reviewer.md` template.
-- Both reviewers: dispatch two subagents in parallel (one `oracle`, one `reviewer`), each with the same SHAs and context. Collect both 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 both when the orchestrator judges the task complex or large.
+- 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.
 
-**GPT/Codex reasoning policy:** `reviewer` and `oracle` use `xhigh` minimum. For complex or high-risk review or verification, request local `max`; the adapter maps it to the target's maximum supported effort (currently `xhigh` for GPT/Codex). `plan-critic` remains `xhigh`.
+**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
 
@@ -90,14 +114,16 @@ Two 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/skills/v1/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/skills/v1/subagent-driven-development/SKILL.md

@@ -11,12 +11,13 @@ description: Use when executing implementation plans with independent tasks in t
      inline in v1); final code review uses requesting-code-review skill only.
      Synced v6.1.1+: Model Selection rewrite (explicit model dispatch, turn-count
      beats token price, tiered guidance); Constructing Reviewer Prompts section
-     (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). 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:
+      (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 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
      ledger (v1 uses TodoWrite); File Handoffs/Durable Progress sections
      (depend on scripts).
@@ -48,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.
@@ -76,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.
 
@@ -151,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
@@ -195,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.
@@ -209,24 +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.
+
+- 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 | Signal | Reviewer(s) |
+| 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) |
+| 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 both.
+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 baseline dispatch: use the selected first available Oracle, and add `reviewer` only when the complexity table says so.
 
-For both-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 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/skills/v1/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]