claudecode-omc 5.6.8 → 5.9.1

package/bundled/upstream/oh-my-claudecode/skills/plan/SKILL.md

@@ -13,25 +13,28 @@ Plan creates comprehensive, actionable work plans through intelligent interactio
 </Purpose>
 
 <Use_When>
+
 - User wants to plan before implementing -- "plan this", "plan the", "let's plan"
 - User wants structured requirements gathering for a vague idea
 - User wants an existing plan reviewed -- "review this plan", `--review`
 - User wants multi-perspective consensus on a plan -- `--consensus`, "ralplan"
 - Task is broad or vague and needs scoping before any code is written
-</Use_When>
+  </Use_When>
 
 <Do_Not_Use_When>
+
 - User wants autonomous end-to-end execution -- use `autopilot` instead
 - User wants to start coding immediately with a clear task -- use `ralph` or delegate to executor
 - User asks a simple question that can be answered directly -- just answer it
 - Task is a single focused fix with obvious scope -- use an execution skill instead of running it from this planning module
-</Do_Not_Use_When>
+  </Do_Not_Use_When>
 
 <Why_This_Exists>
 Jumping into code without understanding requirements leads to rework, scope creep, and missed edge cases. Plan provides structured requirements gathering, expert analysis, and quality-gated plans so that execution starts from a solid foundation. The consensus mode adds multi-perspective validation for high-stakes projects.
 </Why_This_Exists>
 
 <Execution_Policy>
+
 - Auto-detect interview vs direct mode based on request specificity
 - Ask one question at a time during interviews -- never batch multiple questions
 - Gather codebase facts via `explore` agent before asking the user about them
@@ -39,18 +42,20 @@ Jumping into code without understanding requirements leads to rework, scope cree
 - Consensus mode runs fully automated by default; add `--interactive` to enable user prompts at draft review and final approval steps
 - Consensus mode uses RALPLAN-DR short mode by default; switch to deliberate mode with `--deliberate` or when the request explicitly signals high risk (auth/security, data migration, destructive/irreversible changes, production incident, compliance/PII, public API breakage)
 - **Planning/execution boundary:** planning modes inspect context and produce plans/specs/proposals only. They MUST mark artifacts as `pending approval` unless the user has explicitly opted into execution in the current turn or via the structured approval UI. Before explicit execution approval, planning modes MUST NOT run mutation-oriented shell commands, edit source files, commit, push, open PRs, invoke execution skills, or delegate implementation tasks.
-</Execution_Policy>
+- **Goal workflow boundary:** when a plan compares Claude Code `/goal`, Ralph, Team, UltraQA, or artifact-only Ultragoal, identify exactly one primary loop authority and use the deterministic conflict policies `refuse`, `adopt_existing`, and `artifact_only` rather than non-deterministic warning handling. `/goal` facts must cite Claude Code/Anthropic sources only (Claude Code `/goal` docs: https://code.claude.com/docs/en/goal; Anthropic Claude Code changelog: https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md), and plans MUST NOT claim the `/goal` evaluator independently runs commands or reads files; require surfaced proof evidence before any completion claim.
+- **Goal workflow doc target:** for user-facing comparisons, keep examples aligned with `docs/shared/mode-selection-guide.md#goal-oriented-workflow-selection` and `docs/REFERENCE.md#goal-workflow-ux-goal-ralph-team-ultraqa-ultragoal`.
+  </Execution_Policy>
 
 <Steps>
 
 ### Mode Selection
 
-| Mode | Trigger | Behavior |
-|------|---------|----------|
-| Interview | Default for broad requests | Interactive requirements gathering |
-| Direct | `--direct`, or detailed request | Skip interview, generate plan directly |
-| Consensus | `--consensus`, "ralplan" | Planner -> Architect -> Critic loop until agreement with RALPLAN-DR structured deliberation (short by default, `--deliberate` for high-risk); add `--interactive` for user prompts at draft and approval steps |
-| Review | `--review`, "review this plan" | Critic evaluation of existing plan |
+| Mode      | Trigger                         | Behavior                                                                                                                                                                                                       |
+| --------- | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Interview | Default for broad requests      | Interactive requirements gathering                                                                                                                                                                             |
+| Direct    | `--direct`, or detailed request | Skip interview, generate plan directly                                                                                                                                                                         |
+| Consensus | `--consensus`, "ralplan"        | Planner -> Architect -> Critic loop until agreement with RALPLAN-DR structured deliberation (short by default, `--deliberate` for high-risk); add `--interactive` for user prompts at draft and approval steps |
+| Review    | `--review`, "review this plan"  | Critic evaluation of existing plan                                                                                                                                                                             |
 
 ### Interview Mode (broad/vague requests)
 
@@ -72,11 +77,13 @@ Jumping into code without understanding requirements leads to rework, scope cree
 **RALPLAN-DR modes**: **Short** (default, bounded structure) and **Deliberate** (for `--deliberate` or explicit high-risk requests). Both modes keep the same Planner -> Architect -> Critic sequence and the same `AskUserQuestion` gates.
 
 **Provider overrides (supported when the provider CLI is installed):**
+
 - `--architect codex` — replace the Claude Architect pass with `omc ask codex --agent-prompt architect "..."` for implementation-heavy architecture review
 - `--critic codex` — replace the Claude Critic pass with `omc ask codex --agent-prompt critic "..."` for an external review pass before execution
 - If the requested provider is unavailable, briefly note that and continue with the default Claude Architect/Critic step for that stage
 
 **State lifecycle**: The persistent-mode stop hook uses `ralplan-state.json` to enforce continuation during the consensus loop. The skill **MUST** manage this state:
+
 - **On entry**: Call `state_write(mode="ralplan", active=true, session_id=<current_session_id>)` before step 1
 - **On handoff to execution** (approval → ralph/team): Call `state_write(mode="ralplan", active=false, session_id=<current_session_id>)`. Do NOT use `state_clear` here — `state_clear` writes a 30-second cancel signal that disables stop-hook enforcement for ALL modes, leaving the newly launched execution mode unprotected.
 - **On true terminal exit** (rejection, non-interactive plan output, error/abort): Call `state_clear(mode="ralplan", session_id=<current_session_id>)` — no execution mode follows, so the cancel signal window is harmless.
@@ -90,11 +97,11 @@ Without cleanup, the stop hook blocks all subsequent stops with `[RALPLAN - CONS
    - **Viable Options** (>=2) with bounded pros/cons for each option
    - If only one viable option remains, an explicit **invalidation rationale** for the alternatives that were rejected
    - In **deliberate mode**: a **pre-mortem** (3 failure scenarios) and an **expanded test plan** covering **unit / integration / e2e / observability**
-2. **User feedback** *(--interactive only)*: If running with `--interactive`, **MUST** use `AskUserQuestion` to present the draft plan **plus the RALPLAN-DR Principles / Decision Drivers / Options summary for early direction alignment** with these options:
+2. **User feedback** _(--interactive only)_: If running with `--interactive`, **MUST** use `AskUserQuestion` to present the draft plan **plus the RALPLAN-DR Principles / Decision Drivers / Options summary for early direction alignment** with these options:
    - **Proceed to review** — send to Architect and Critic for evaluation
    - **Request changes** — return to step 1 with user feedback incorporated
    - **Skip review** — go directly to final approval (step 7)
-   If NOT running with `--interactive`, automatically proceed to review (step 3).
+     If NOT running with `--interactive`, automatically proceed to review (step 3).
 3. **Architect** reviews for architectural soundness using `Task(subagent_type="oh-my-claudecode:architect", ...)`. Architect review **MUST** include: strongest steelman counterargument (antithesis) against the favored option, at least one meaningful tradeoff tension, and (when possible) a synthesis path. In deliberate mode, Architect should explicitly flag principle violations. **Wait for this step to complete before proceeding to step 4.** Do NOT run steps 3 and 4 in parallel.
 4. **Critic** evaluates against quality criteria using `Task(subagent_type="oh-my-claudecode:critic", ...)`. Critic **MUST** verify principle-option consistency, fair alternative exploration, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. Critic **MUST** explicitly reject shallow alternatives, driver contradictions, vague risks, or weak verification. In deliberate mode, Critic **MUST** reject missing/weak pre-mortem or missing/weak expanded test plan. Run only after step 3 is complete.
 5. **Re-review loop** (max 5 iterations): If Critic rejects, execute this closed loop:
@@ -109,18 +116,18 @@ Without cleanup, the stop hook blocks all subsequent stops with `[RALPLAN - CONS
    b. Deduplicate and categorize the suggestions
    c. Update the plan file in `.omc/plans/` with the accepted improvements (add missing details, refine steps, strengthen acceptance criteria, ADR updates, etc.)
    d. Note which improvements were applied in a brief changelog section at the end of the plan
-7. On Critic approval (with improvements applied): mark the plan status as `pending approval` unless explicit execution approval has already been captured. *(--interactive only)* If running with `--interactive`, use `AskUserQuestion` to present the plan with these options:
+7. On Critic approval (with improvements applied): mark the plan status as `pending approval` unless explicit execution approval has already been captured. _(--interactive only)_ If running with `--interactive`, use `AskUserQuestion` to present the plan with these options:
    - **Approve execution via team** (Recommended) — explicit opt-in to proceed via coordinated parallel team agents (`/team`). Team is the canonical orchestration surface since v4.1.7.
    - **Approve execution via ralph** — explicit opt-in to proceed via ralph+ultrawork (sequential execution with verification)
-   - **Approve execution after clearing context** — explicit opt-in to compact the context window first (recommended when context is large after planning), then start fresh implementation via ralph with the saved plan file
+   - **Compact then return for execution approval** — explicit opt-in to compact the context window first (recommended when context is large after planning), then stop at the saved pending-approval plan and ask again before launching execution
    - **Request changes** — return to step 1 with user feedback
    - **Reject** — discard the plan entirely
-   If NOT running with `--interactive`, output the final plan marked `pending approval`, call `state_clear(mode="ralplan", session_id=<current_session_id>)`, and stop. Do NOT auto-execute.
-8. *(--interactive only)* User chooses via the structured `AskUserQuestion` UI (never ask for approval in plain text). If user selects **Reject**, call `state_clear(mode="ralplan", session_id=<current_session_id>)` and stop.
+     If NOT running with `--interactive`, output the final plan marked `pending approval`, call `state_clear(mode="ralplan", session_id=<current_session_id>)`, and stop. Do NOT auto-execute.
+8. _(--interactive only)_ User chooses via the structured `AskUserQuestion` UI (never ask for approval in plain text). If user selects **Reject**, call `state_clear(mode="ralplan", session_id=<current_session_id>)` and stop.
 9. On user approval (--interactive only): Call `state_write(mode="ralplan", active=false, session_id=<current_session_id>)` **before** invoking the execution skill (ralph/team), so the stop hook does not interfere with the execution mode's own enforcement. Do NOT use `state_clear` here — it writes a cancel signal that disables enforcement for the newly launched mode.
    - **Approve execution via team**: **MUST** invoke `Skill("oh-my-claudecode:team")` with the approved plan path from `.omc/plans/` as context. Do NOT implement directly. The team skill coordinates parallel agents across the staged pipeline for faster execution on large tasks. This is the recommended default execution path.
    - **Approve execution via ralph**: **MUST** invoke `Skill("oh-my-claudecode:ralph")` with the approved plan path from `.omc/plans/` as context. Do NOT implement directly. Do NOT edit source code files in the planning agent. The ralph skill handles execution via ultrawork parallel agents.
-   - **Approve execution after clearing context**: First invoke `Skill("compact")` to compress the context window (reduces token usage accumulated during planning), then invoke `Skill("oh-my-claudecode:ralph")` with the approved plan path from `.omc/plans/`. This path is recommended when the context window is 50%+ full after the planning session.
+   - **Compact then return for execution approval**: First invoke `Skill("compact")` to compress the context window (reduces token usage accumulated during planning), then return with the saved pending-approval plan path and require a fresh explicit execution approval before any ralph/team launch. This path is recommended when the context window is 50%+ full after the planning session.
 
 ### Review Mode (`--review`)
 
@@ -131,6 +138,7 @@ Without cleanup, the stop hook blocks all subsequent stops with `[RALPLAN - CONS
 ### Plan Output Format
 
 Every plan includes:
+
 - Requirements Summary
 - Acceptance Criteria (testable)
 - Implementation Steps (with file references)
@@ -144,6 +152,7 @@ Plans are saved to `.omc/plans/`. Drafts go to `.omc/drafts/`.
 </Steps>
 
 <Tool_Usage>
+
 - Use `AskUserQuestion` for preference questions (scope, priority, timeline, risk tolerance) -- provides clickable UI
 - Use plain text for questions needing specific values (port numbers, names, follow-up clarifications)
 - Use `explore` agent (Haiku, 30s timeout) to gather codebase facts before asking the user
@@ -155,9 +164,9 @@ Plans are saved to `.omc/plans/`. Drafts go to `.omc/drafts/`.
 - In consensus mode with `--interactive`: use `AskUserQuestion` for the user feedback step (step 2) and the final approval step (step 7) -- never ask for approval in plain text. Without `--interactive`, skip both prompts, mark the plan `pending approval`, output the final plan, and stop.
 - In consensus mode with `--interactive`, on explicit user approval **MUST** invoke `Skill("oh-my-claudecode:ralph")` or `Skill("oh-my-claudecode:team")` for execution (step 9) -- never implement directly in the planning agent
 - Before explicit execution approval, planning mode MUST NOT run mutation-oriented shell commands, edit files, commit, push, open PRs, invoke execution skills, or delegate implementation tasks; it may only inspect context and draft/update plan/spec/proposal artifacts.
-- When user selects "Approve execution after clearing context" in step 7 (--interactive only): call `state_write(mode="ralplan", active=false, session_id=<current_session_id>)` first, then invoke `Skill("compact")` to compress the accumulated planning context, then immediately invoke `Skill("oh-my-claudecode:ralph")` with the plan path -- the compact step is critical to free up context before the implementation loop begins
+- When user selects "Compact then return for execution approval" in step 7 (--interactive only): keep the plan marked `pending approval`, call `state_write(mode="ralplan", active=false, current_phase="pending_approval", session_id=<current_session_id>)`, then invoke `Skill("compact")` to compress the accumulated planning context. After compact, require a fresh explicit execution approval before any ralph/team launch; never auto-start implementation from compact continuation
 - **CRITICAL — Consensus mode state lifecycle**: Always deactivate ralplan state before stopping or handing off to execution. Use `state_write(active=false)` for handoff paths (approval → ralph/team) and `state_clear` for true terminal exits (rejection, error). Never use `state_clear` before launching an execution mode — its cancel signal disables stop-hook enforcement for 30 seconds.
-</Tool_Usage>
+  </Tool_Usage>
 
 <Examples>
 <Good>
@@ -210,14 +219,16 @@ Why bad: Decision fatigue. Present one option with trade-offs, get reaction, the
 </Examples>
 
 <Escalation_And_Stop_Conditions>
+
 - Stop interviewing when requirements are clear enough to plan -- do not over-interview
 - In consensus mode, stop after 5 Planner/Architect/Critic iterations and present the best version. Do NOT clear ralplan state here — the user may still select "Request changes" in the subsequent step. State is cleared only on the user's final choice (approval/rejection) or when outputting the plan in non-interactive mode.
 - Consensus mode without `--interactive` outputs the final plan marked `pending approval` and stops; with `--interactive`, requires explicit user approval before any implementation begins. **Always** call `state_clear(mode="ralplan", session_id=<current_session_id>)` before stopping.
 - If the user says "just do it" or "skip planning" without explicitly naming an execution path, treat it as a request to end planning: output the current plan/spec/proposal as `pending approval` and ask for explicit execution approval via the structured approval UI. Do NOT invoke `Skill("oh-my-claudecode:ralph")`, mutate files, delegate implementation, commit, push, or open a PR from the planning module until that approval exists.
 - Escalate to the user when there are irreconcilable trade-offs that require a business decision
-</Escalation_And_Stop_Conditions>
+  </Escalation_And_Stop_Conditions>
 
 <Final_Checklist>
+
 - [ ] Plan has testable acceptance criteria (90%+ concrete)
 - [ ] Plan references specific files/lines where applicable (80%+ claims)
 - [ ] All risks have mitigations identified
@@ -228,7 +239,7 @@ Why bad: Decision fatigue. Present one option with trade-offs, get reaction, the
 - [ ] In deliberate consensus mode: pre-mortem (3 scenarios) + expanded test plan (unit/integration/e2e/observability) included
 - [ ] In consensus mode with `--interactive`: user explicitly approved before any execution; without `--interactive`: plan output marked `pending approval` only, no auto-execution
 - [ ] In consensus mode: ralplan state deactivated on every exit path — `state_write(active=false)` for handoff to execution, `state_clear` for terminal exits (rejection, error, non-interactive stop)
-</Final_Checklist>
+      </Final_Checklist>
 
 <Advanced>
 ## Design Option Presentation
@@ -243,6 +254,7 @@ When presenting design choices during interviews, chunk them:
 6. **Recommendation** (only after options discussed)
 
 Format for each option:
+
 ```
 ### Option A: [Name]
 **Approach:** [1 sentence]
@@ -256,21 +268,21 @@ What's your reaction to this approach?
 
 Before asking any interview question, classify it:
 
-| Type | Examples | Action |
-|------|----------|--------|
-| Codebase Fact | "What patterns exist?", "Where is X?" | Explore first, do not ask user |
-| User Preference | "Priority?", "Timeline?" | Ask user via AskUserQuestion |
-| Scope Decision | "Include feature Y?" | Ask user |
-| Requirement | "Performance constraints?" | Ask user |
+| Type            | Examples                              | Action                         |
+| --------------- | ------------------------------------- | ------------------------------ |
+| Codebase Fact   | "What patterns exist?", "Where is X?" | Explore first, do not ask user |
+| User Preference | "Priority?", "Timeline?"              | Ask user via AskUserQuestion   |
+| Scope Decision  | "Include feature Y?"                  | Ask user                       |
+| Requirement     | "Performance constraints?"            | Ask user                       |
 
 ## Review Quality Criteria
 
-| Criterion | Standard |
-|-----------|----------|
-| Clarity | 80%+ claims cite file/line |
-| Testability | 90%+ criteria are concrete |
-| Verification | All file refs exist |
-| Specificity | No vague terms |
+| Criterion    | Standard                   |
+| ------------ | -------------------------- |
+| Clarity      | 80%+ claims cite file/line |
+| Testability  | 90%+ criteria are concrete |
+| Verification | All file refs exist        |
+| Specificity  | No vague terms             |
 
 ## Deprecation Notice
 

package/bundled/upstream/oh-my-claudecode/skills/ralph/SKILL.md

@@ -14,26 +14,30 @@ Ralph is a PRD-driven persistence loop that keeps working on a task until ALL us
 </Purpose>
 
 <Use_When>
+
 - Task requires guaranteed completion with verification (not just "do your best")
 - User says "ralph", "don't stop", "must complete", "finish this", or "keep going until done"
 - Work may span multiple iterations and needs persistence across retries
 - Task benefits from structured PRD-driven execution with reviewer sign-off
-</Use_When>
+  </Use_When>
 
 <Do_Not_Use_When>
+
 - User wants a full autonomous pipeline from idea to code -- use `autopilot` instead
 - User wants to explore or plan before committing -- use `plan` skill instead
 - User wants a quick one-shot fix -- delegate directly to an executor agent
 - User wants manual control over completion -- use `ultrawork` directly
-</Do_Not_Use_When>
+- User already has an active Claude Code `/goal` and only wants that native goal loop monitored -- adopt the existing `/goal` explicitly or use artifact-only Ultragoal notes instead of starting Ralph as a competing persistence loop
+  </Do_Not_Use_When>
 
 <Why_This_Exists>
 Complex tasks often fail silently: partial implementations get declared "done", tests get skipped, edge cases get forgotten. Ralph prevents this by:
+
 1. Structuring work into discrete user stories with testable acceptance criteria (prd.json)
 2. Iterating story-by-story until each one passes
 3. Tracking progress and learnings across iterations (progress.txt)
 4. Requiring fresh reviewer verification against specific acceptance criteria before completion
-</Why_This_Exists>
+   </Why_This_Exists>
 
 <PRD_Mode>
 By default, ralph operates in PRD mode. A scaffold `prd.json` is auto-generated when ralph starts if none exists. Active transient PRD state is session-scoped at `.omc/state/sessions/{sessionId}/prd.json` when a session ID is available; legacy project-level `prd.json` / `.omc/prd.json` files are read as startup migration inputs.
@@ -46,12 +50,14 @@ By default, ralph operates in PRD mode. A scaffold `prd.json` is auto-generated
 </PRD_Mode>
 
 <Execution_Policy>
+
 - Fire independent agent calls simultaneously -- never wait sequentially for independent work
 - Use `run_in_background: true` for long operations (installs, builds, test suites)
 - Always pass the `model` parameter explicitly when delegating to agents
 - Read `docs/shared/agent-tiers.md` before first delegation to select correct agent tiers
 - Deliver the full implementation: no scope reduction, no partial completion, no deleting tests to make them pass
-</Execution_Policy>
+- If a Claude Code `/goal` is mentioned, treat it as a native session-loop handoff/evidence source only and use the deterministic conflict policies `refuse`, `adopt_existing`, and `artifact_only` rather than non-deterministic warning handling. Ralph remains the OMC loop authority for this run; do not claim `/goal` independently ran tests or read files, and do not treat evaluator success as a substitute for Ralph reviewer verification.
+  </Execution_Policy>
 
 <Steps>
 1. **PRD Setup** (first iteration only):
@@ -94,7 +100,7 @@ By default, ralph operates in PRD mode. A scaffold `prd.json` is auto-generated
 7. **Reviewer verification** (tiered, against acceptance criteria):
    - <5 files, <100 lines with full tests: STANDARD tier minimum (architect-medium / Sonnet)
    - Standard changes: STANDARD tier (architect-medium / Sonnet)
-   - >20 files or security/architectural changes: THOROUGH tier (architect / Opus)
+   - > 20 files or security/architectural changes: THOROUGH tier (architect / Opus)
    - If `--critic=critic`, use the Claude `critic` agent for the approval pass
    - If `--critic=codex`, run `omc ask codex --agent-prompt critic "..."` for the approval pass. The Codex critic prompt MUST include:
      1. The full list of acceptance criteria from prd.json for verification
@@ -106,23 +112,26 @@ By default, ralph operates in PRD mode. A scaffold `prd.json` is auto-generated
    - **On APPROVAL: immediately proceed to Step 7.5 in the same turn. Do NOT pause to report the verdict to the user — reporting happens only at Step 8 (`/oh-my-claudecode:cancel`) or on rejection (Step 9). Treating an approved verdict as a reporting checkpoint is a polite-stop anti-pattern.**
 
 7.5 **Mandatory Deslop Pass** (runs unconditionally after Step 7 approval, unless `{{PROMPT}}` contains `--no-deslop`):
-   - **Invoke the `ai-slop-cleaner` skill via the Skill tool: `Skill("ai-slop-cleaner")`.** Run in standard mode (not `--review`) on the files changed during the current Ralph session only.
-   - **ai-slop-cleaner is a SKILL, not an agent.** Do NOT call it via `Task(subagent_type="oh-my-claudecode:ai-slop-cleaner")` — that subagent type does not exist and the call will fail with "Agent type not found". If you see that error, retry with the Skill tool — do NOT substitute a similarly-named agent like `code-simplifier` as a "closest match".
-   - Keep the scope bounded to the Ralph changed-file set; do not broaden the cleanup pass to unrelated files.
-   - If the reviewer approved the implementation but the deslop pass introduces follow-up edits, keep those edits inside the same changed-file scope before proceeding.
 
-7.6 **Regression Re-verification**:
-   - After the deslop pass, re-run all relevant tests, build, and lint checks for the Ralph session.
-   - Read the output and confirm the post-deslop regression run actually passes.
-   - If regression fails, roll back the cleaner changes or fix the regression, then rerun the verification loop until it passes.
-   - Only proceed to completion after the post-deslop regression run passes (or `--no-deslop` was explicitly specified).
+- **Invoke the `ai-slop-cleaner` skill via the Skill tool: `Skill("ai-slop-cleaner")`.** Run in standard mode (not `--review`) on the files changed during the current Ralph session only.
+- **ai-slop-cleaner is a SKILL, not an agent.** Do NOT call it via `Task(subagent_type="oh-my-claudecode:ai-slop-cleaner")` — that subagent type does not exist and the call will fail with "Agent type not found". If you see that error, retry with the Skill tool — do NOT substitute a similarly-named agent like `code-simplifier` as a "closest match".
+- Keep the scope bounded to the Ralph changed-file set; do not broaden the cleanup pass to unrelated files.
+- If the reviewer approved the implementation but the deslop pass introduces follow-up edits, keep those edits inside the same changed-file scope before proceeding.
+
+  7.6 **Regression Re-verification**:
+
+- After the deslop pass, re-run all relevant tests, build, and lint checks for the Ralph session.
+- Read the output and confirm the post-deslop regression run actually passes.
+- If regression fails, roll back the cleaner changes or fix the regression, then rerun the verification loop until it passes.
+- Only proceed to completion after the post-deslop regression run passes (or `--no-deslop` was explicitly specified).
 
 8. **On approval**: After Step 7.6 passes (with Step 7.5 completed, or skipped via `--no-deslop`), run `/oh-my-claudecode:cancel` to cleanly exit and clean up all state files
 
 9. **On rejection**: Fix the issues raised, re-verify with the same reviewer, then loop back to check if the story needs to be marked incomplete
-</Steps>
+   </Steps>
 
 <Tool_Usage>
+
 - Use `Task(subagent_type="oh-my-claudecode:architect", ...)` for architect verification cross-checks when changes are security-sensitive, architectural, or involve complex multi-system integration
 - Use `Task(subagent_type="oh-my-claudecode:critic", ...)` when `--critic=critic`
 - Use `omc ask codex --agent-prompt critic "..."` when `--critic=codex`. Construct the prompt to include: (a) prd.json acceptance criteria, (b) files changed + related files, (c) explicit optimality question: "Is there a meaningfully simpler, faster, or more maintainable approach that achieves the same acceptance criteria?"
@@ -130,7 +139,7 @@ By default, ralph operates in PRD mode. A scaffold `prd.json` is auto-generated
 - Proceed with architect agent verification alone -- never block on unavailable tools
 - Use `state_write` / `state_read` for ralph mode state persistence between iterations
 - **Skill vs agent invocation**: `ai-slop-cleaner` is a skill, invoke via `Skill("ai-slop-cleaner")`. `architect`, `critic`, `executor` etc. are agents, invoke via `Task(subagent_type="oh-my-claudecode:<name>")`. If you ever get "Agent type ... not found" for an `oh-my-claudecode:<name>` identifier, the item is a skill — retry with the Skill tool. Do NOT substitute a similarly-named agent as a "closest match".
-</Tool_Usage>
+  </Tool_Usage>
 
 <Examples>
 <Good>
@@ -140,11 +149,12 @@ Auto-generated scaffold has:
   acceptanceCriteria: ["Implementation is complete", "Code compiles without errors"]
 
 After refinement:
-  acceptanceCriteria: [
-    "Legacy --no-prd text is stripped from the Ralph working prompt",
-    "Ralph startup still creates or validates prd.json when legacy --no-prd text is present",
-    "TypeScript compiles with no errors (npm run build)"
-  ]
+acceptanceCriteria: [
+"Legacy --no-prd text is stripped from the Ralph working prompt",
+"Ralph startup still creates or validates prd.json when legacy --no-prd text is present",
+"TypeScript compiles with no errors (npm run build)"
+]
+
 ```
 Why good: Generic criteria replaced with specific, testable criteria.
 </Good>
@@ -152,9 +162,11 @@ Why good: Generic criteria replaced with specific, testable criteria.
 <Good>
 Correct parallel delegation:
 ```
+
 Task(subagent_type="oh-my-claudecode:executor", model="haiku", prompt="Add type export for UserConfig")
 Task(subagent_type="oh-my-claudecode:executor", model="sonnet", prompt="Implement the caching layer for API responses")
 Task(subagent_type="oh-my-claudecode:executor", model="opus", prompt="Refactor auth module to support OAuth2 flow")
+
 ```
 Why good: Three independent tasks fired simultaneously at appropriate tiers.
 </Good>
@@ -162,12 +174,14 @@ Why good: Three independent tasks fired simultaneously at appropriate tiers.
 <Good>
 Story-by-story verification:
 ```
+
 1. Story US-001: "Add flag detection helpers"
    - Criterion: "Legacy --no-prd is stripped from the working prompt" → Run test → PASS
    - Criterion: "TypeScript compiles" → Run build → PASS
    - Mark US-001 passes: true
 2. Story US-002: "Wire PRD into bridge.ts"
    - Continue to next story...
+
 ```
 Why good: Each story verified against its own acceptance criteria before marking complete.
 </Good>
@@ -181,9 +195,11 @@ Why bad: Uses "should" and "look good" -- no fresh evidence, no story-by-story v
 <Bad>
 Sequential execution of independent tasks:
 ```
+
 Task(executor, "Add type export") → wait →
 Task(executor, "Implement caching") → wait →
 Task(executor, "Refactor auth")
+
 ```
 Why bad: These are independent tasks that should run in parallel, not sequentially.
 </Bad>
@@ -219,6 +235,13 @@ Why bad: Did not refine scaffold criteria into task-specific ones. This is PRD t
 - [ ] `/oh-my-claudecode:cancel` run for clean state cleanup
 </Final_Checklist>
 
+## Parallel session caveats
+
+- **Multi-repo workspace anchor:** drop a `.omc-workspace` marker at the parent directory so multiple sessions across sub-repos share one `.omc/`. Resolution order: `OMC_STATE_DIR > .omc-workspace > git > cwd`. See `docs/REFERENCE.md`.
+- **Session id source:** OMC_SESSION_ID env var wins in CLI contexts; hook payload data.session_id wins in hook contexts.
+- **Plan id (when applicable):** Two ralph runs in the same workspace will conflict on `prd.json`. Use distinct session IDs (the hook payload session_id is already isolated per Claude Code session). For parallel ultragoal-backed ralph runs, use `--plan-id`.
+- **Parallel verdict:** supported (each session writes its own session-scoped state)
+
 <Advanced>
 ## Background Execution Rules
 
@@ -236,3 +259,4 @@ Why bad: Did not refine scaffold criteria into task-specific ones. This is PRD t
 
 Original task:
 {{PROMPT}}
+```

package/bundled/upstream/oh-my-claudecode/skills/ralplan/SKILL.md

@@ -58,7 +58,7 @@ The consensus workflow:
    d. Return to Critic evaluation
    e. Repeat this loop until Critic returns `APPROVE` or 5 iterations are reached
    f. If 5 iterations are reached without `APPROVE`, present the best version to the user
-6. On Critic approval, mark the plan `pending approval` unless explicit execution approval has already been captured. *(--interactive only)* If `--interactive` is set, use `AskUserQuestion` to present the plan with approval options (Approve execution via team (Recommended) / Approve execution via ralph / Approve execution after clearing context / Request changes / Reject). Final plan must include ADR (Decision, Drivers, Alternatives considered, Why chosen, Consequences, Follow-ups). Otherwise, output the final plan and stop before any mutation or delegation.
+6. On Critic approval, mark the plan `pending approval` unless explicit execution approval has already been captured. *(--interactive only)* If `--interactive` is set, use `AskUserQuestion` to present the plan with approval options (Approve execution via team (Recommended) / Approve execution via ralph / Compact then return for execution approval / Request changes / Reject). Final plan must include ADR (Decision, Drivers, Alternatives considered, Why chosen, Consequences, Follow-ups). Otherwise, output the final plan and stop before any mutation or delegation.
 7. *(--interactive only)* User chooses: Approve (team or ralph), Request changes, or Reject
 8. *(--interactive only)* On approval: invoke `Skill("oh-my-claudecode:team")` for parallel team execution (recommended) or `Skill("oh-my-claudecode:ralph")` for sequential execution -- never implement directly
 

package/bundled/upstream/oh-my-claudecode/skills/self-improve/SKILL.md

@@ -375,6 +375,13 @@ When the loop exits:
 
 ---
 
+## Parallel session caveats
+
+- **Multi-repo workspace anchor:** drop a `.omc-workspace` marker at the parent directory so multiple sessions across sub-repos share one `.omc/`. Resolution order: `OMC_STATE_DIR > .omc-workspace > git > cwd`. See `docs/REFERENCE.md`.
+- **Session id source:** OMC_SESSION_ID env var wins in CLI contexts; hook payload data.session_id wins in hook contexts.
+- **Plan id (when applicable):** Self-improve artifact dirs are topic-slug-scoped; for parallel runs with the same topic in the same workspace, expect Wave B2's session-id suffix to land.
+- **Parallel verdict:** supported-with-caveats (topic-slug collision possible; see Wave B2)
+
 ## Approach Family Taxonomy
 
 Every plan must be tagged with exactly one:

package/bundled/upstream/oh-my-claudecode/skills/self-improve/scripts/resolve-paths.mjs

@@ -2,9 +2,12 @@
 
 import { existsSync, mkdirSync } from 'node:fs';
 import { join, resolve } from 'node:path';
+import { pathToFileURL } from 'node:url';
+import { resolveOmcStateRoot } from '../../../scripts/lib/state-root.mjs';
 
 const DEFAULT_TOPIC_SLUG = 'default';
 const TOPICS_DIR = 'topics';
+const SESSIONS_DIR = 'sessions';
 
 function slugify(value) {
   const normalized = String(value ?? '')
@@ -24,6 +27,7 @@ function parseArgs(argv) {
     projectRoot: process.cwd(),
     topic: '',
     slug: '',
+    sessionId: '',
     format: 'json',
     ensureDirs: false,
   };
@@ -47,6 +51,11 @@ function parseArgs(argv) {
       index += 1;
     } else if (arg.startsWith('--slug=')) {
       result.slug = arg.slice('--slug='.length);
+    } else if (arg === '--session-id' && next) {
+      result.sessionId = next;
+      index += 1;
+    } else if (arg.startsWith('--session-id=')) {
+      result.sessionId = arg.slice('--session-id='.length);
     } else if (arg === '--format' && next) {
       result.format = next;
       index += 1;
@@ -73,13 +82,13 @@ function hasLegacyLayout(baseRoot) {
     || existsSync(join(baseRoot, 'state', 'agent-settings.json'));
 }
 
-function buildPaths(root, projectRoot, topicSlug, scopeMode) {
+function buildPaths(root, projectRoot, topicSlug, scopeMode, baseRoot) {
   const configDir = join(root, 'config');
   const stateDir = join(root, 'state');
   const trackingDir = join(root, 'tracking');
   const paths = {
     project_root: projectRoot,
-    base_root: join(projectRoot, '.omc', 'self-improve'),
+    base_root: baseRoot,
     topic_slug: topicSlug,
     scope_mode: scopeMode,
     root,
@@ -120,21 +129,36 @@ function ensureDirs(paths) {
   }
 }
 
-export function resolveSelfImprovePaths({ projectRoot = process.cwd(), topic = '', slug = '' } = {}) {
+export async function resolveSelfImprovePaths({ projectRoot = process.cwd(), topic = '', slug = '', sessionId = '' } = {}) {
   const resolvedProjectRoot = resolve(projectRoot);
-  const baseRoot = join(resolvedProjectRoot, '.omc', 'self-improve');
+  const omcRoot = await resolveOmcStateRoot(resolvedProjectRoot);
+  const baseRoot = join(omcRoot, 'self-improve');
   const explicitSlug = slugify(slug || topic);
   const legacyLayout = hasLegacyLayout(baseRoot);
   const shouldUseLegacyRoot = !slug && !topic && legacyLayout;
   const topicSlug = shouldUseLegacyRoot ? DEFAULT_TOPIC_SLUG : explicitSlug;
+
+  // When a sessionId is provided, scope beneath topics/<slug>/sessions/<sid>/
+  // so concurrent runs sharing the same topic slug don't collide.
+  // Falls back to OMC_SESSION_ID env var when explicit arg is absent.
+  // Legacy layout (no topic/slug supplied, flat .omc/self-improve/ exists) is
+  // preserved as-is — session scoping only applies to the topic-scoped layout.
+  const rawSessionId = sessionId && sessionId.trim()
+    ? sessionId.trim()
+    : (process.env.OMC_SESSION_ID && process.env.OMC_SESSION_ID.trim() ? process.env.OMC_SESSION_ID.trim() : '');
+  const effectiveSessionId = shouldUseLegacyRoot ? '' : rawSessionId;
   const root = shouldUseLegacyRoot
     ? baseRoot
-    : join(baseRoot, TOPICS_DIR, topicSlug);
+    : effectiveSessionId
+      ? join(baseRoot, TOPICS_DIR, topicSlug, SESSIONS_DIR, effectiveSessionId)
+      : join(baseRoot, TOPICS_DIR, topicSlug);
   const scopeMode = shouldUseLegacyRoot
     ? 'legacy-flat-root'
-    : (slug || topic ? 'topic-scoped' : 'default-scoped');
+    : effectiveSessionId
+      ? 'session-scoped'
+      : (slug || topic ? 'topic-scoped' : 'default-scoped');
 
-  return buildPaths(root, resolvedProjectRoot, topicSlug, scopeMode);
+  return { ...buildPaths(root, resolvedProjectRoot, topicSlug, scopeMode, baseRoot), session_id: effectiveSessionId || null };
 }
 
 function renderShell(paths) {
@@ -146,27 +170,29 @@ function renderShell(paths) {
 function printHelp() {
   process.stdout.write(
     [
-      'Usage: node resolve-paths.mjs [--project-root PATH] [--topic TEXT | --slug SLUG] [--ensure-dirs] [--format json|shell]',
+      'Usage: node resolve-paths.mjs [--project-root PATH] [--topic TEXT | --slug SLUG] [--session-id SID] [--ensure-dirs] [--format json|shell]',
       '',
       'Resolves self-improve artifact paths.',
       '- New runs default to .omc/self-improve/topics/<topic-slug>/',
+      '- Pass --session-id to isolate parallel runs: .omc/self-improve/topics/<slug>/sessions/<sid>/',
       '- Legacy flat .omc/self-improve/ is preserved only when no topic/slug is supplied and a flat layout already exists',
       '',
     ].join('\n'),
   );
 }
 
-function main() {
+async function main() {
   const args = parseArgs(process.argv.slice(2));
   if (args.help) {
     printHelp();
     return;
   }
 
-  const paths = resolveSelfImprovePaths({
+  const paths = await resolveSelfImprovePaths({
     projectRoot: args.projectRoot,
     topic: args.topic,
     slug: args.slug,
+    sessionId: args.sessionId,
   });
 
   if (args.ensureDirs) {
@@ -181,12 +207,10 @@ function main() {
   process.stdout.write(`${JSON.stringify(paths, null, 2)}\n`);
 }
 
-if (import.meta.url === `file://${process.argv[1]}`) {
-  try {
-    main();
-  } catch (error) {
+if (process.argv[1] && pathToFileURL(process.argv[1]).href === import.meta.url) {
+  main().catch((error) => {
     const message = error instanceof Error ? error.message : String(error);
     process.stderr.write(`${message}\n`);
     process.exit(1);
-  }
+  });
 }