claudecode-omc 5.6.8 → 5.11.0

package/bundled/upstream/oh-my-claudecode/skills/omc-setup/phases/01-install-claude-md.md

@@ -30,7 +30,7 @@ Set `GLOBAL_INSTALL_STYLE=overwrite` or `preserve` based on the user's choice. I
 **MANDATORY**: Always run this command. Do NOT skip. Do NOT use the Write tool. Let the setup script choose the safest canonical source (bundled `docs/CLAUDE.md` first, GitHub fallback only if needed).
 
 ```bash
-bash "${CLAUDE_PLUGIN_ROOT}/scripts/setup-claude-md.sh" <CONFIG_TARGET> [GLOBAL_INSTALL_STYLE]
+bash "${OMC_SETUP_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/setup-claude-md.sh" <CONFIG_TARGET> [GLOBAL_INSTALL_STYLE]
 ```
 
 Replace `<CONFIG_TARGET>` with `local` or `global`. For local installs, omit the optional style argument. For global installs, pass `overwrite` or `preserve` when you know the user's choice; otherwise let the script default to `overwrite`.
@@ -85,13 +85,13 @@ Note: Hooks are now managed by the plugin system automatically. No manual hook i
 ## Save Progress
 
 ```bash
-bash "${CLAUDE_PLUGIN_ROOT}/scripts/setup-progress.sh" save 2 <CONFIG_TARGET>
+bash "${OMC_SETUP_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/setup-progress.sh" save 2 <CONFIG_TARGET>
 ```
 
 ## Early Exit for Flag Mode
 
 If `--local` or `--global` flag was used, clear state and **STOP HERE**:
 ```bash
-bash "${CLAUDE_PLUGIN_ROOT}/scripts/setup-progress.sh" clear
+bash "${OMC_SETUP_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/setup-progress.sh" clear
 ```
 Do not continue to Phase 2 or other phases.

package/bundled/upstream/oh-my-claudecode/skills/omc-setup/phases/02-configure.md

@@ -35,13 +35,15 @@ This will:
 After HUD setup completes, save progress:
 ```bash
 CONFIG_TYPE=$(jq -r '.configType // "unknown"' ".omc/state/setup-state.json" 2>/dev/null || echo "unknown")
-bash "${CLAUDE_PLUGIN_ROOT}/scripts/setup-progress.sh" save 3 "$CONFIG_TYPE"
+bash "${OMC_SETUP_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/setup-progress.sh" save 3 "$CONFIG_TYPE"
 ```
 
-## Step 2.2: Clear Stale Plugin Cache
+## Step 2.2: Repair Stale Plugin Cache References
+
+After a marketplace update, Claude Code may still have old OMC cache paths in the running session or plugin registry. Repair those references before any cache cleanup so setup does not repeatedly emit stale plugin directory errors.
 
 ```bash
-node -e "const p=require('path'),f=require('fs'),h=require('os').homedir(),d=process.env.CLAUDE_CONFIG_DIR||p.join(h,'.claude'),b=p.join(d,'plugins','cache','omc','oh-my-claudecode');try{const v=f.readdirSync(b).filter(x=>/^\d/.test(x)).sort((a,c)=>a.localeCompare(c,void 0,{numeric:true}));if(v.length<=1){console.log('Cache is clean');process.exit()}v.slice(0,-1).forEach(x=>{f.rmSync(p.join(b,x),{recursive:true,force:true})});console.log('Cleared',v.length-1,'stale cache version(s)')}catch{console.log('No cache directory found (normal for new installs)')}"
+node "${OMC_SETUP_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/repair-plugin-cache.mjs"
 ```
 
 ## Step 2.3: Check for Updates
@@ -252,5 +254,5 @@ echo "Task tool set to: USER_CHOICE"
 
 ```bash
 CONFIG_TYPE=$(jq -r '.configType // "unknown"' ".omc/state/setup-state.json" 2>/dev/null || echo "unknown")
-bash "${CLAUDE_PLUGIN_ROOT}/scripts/setup-progress.sh" save 4 "$CONFIG_TYPE"
+bash "${OMC_SETUP_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/setup-progress.sh" save 4 "$CONFIG_TYPE"
 ```

package/bundled/upstream/oh-my-claudecode/skills/omc-setup/phases/03-integrations.md

@@ -229,5 +229,5 @@ Or by running `/oh-my-claudecode:omc-setup --force` and choosing to enable teams
 
 ```bash
 CONFIG_TYPE=$(jq -r '.configType // "unknown"' ".omc/state/setup-state.json" 2>/dev/null || echo "unknown")
-bash "${CLAUDE_PLUGIN_ROOT}/scripts/setup-progress.sh" save 6 "$CONFIG_TYPE"
+bash "${OMC_SETUP_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/setup-progress.sh" save 6 "$CONFIG_TYPE"
 ```

package/bundled/upstream/oh-my-claudecode/skills/omc-setup/phases/04-welcome.md

@@ -116,7 +116,7 @@ OMC includes rule templates you can copy to your project's `.claude/rules/` dire
 Copy with:
 ```bash
 mkdir -p .claude/rules
-cp "${CLAUDE_PLUGIN_ROOT}/templates/rules/"*.md .claude/rules/
+cp "${OMC_SETUP_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/templates/rules/"*.md .claude/rules/
 ```
 
 See `templates/rules/README.md` for details.
@@ -188,5 +188,5 @@ if [ -z "$OMC_VERSION" ]; then
   OMC_VERSION="unknown"
 fi
 
-bash "${CLAUDE_PLUGIN_ROOT}/scripts/setup-progress.sh" complete "$OMC_VERSION"
+bash "${OMC_SETUP_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/setup-progress.sh" complete "$OMC_VERSION"
 ```

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

@@ -35,8 +35,8 @@ Spawn N CLI worker processes in tmux panes to execute tasks in parallel. Support
 
 ## Requirements
 
-- **tmux binary** must be installed and discoverable (`command -v tmux`)
-- **Classic tmux session optional** for in-place pane splitting (`$TMUX` set). Inside cmux or a plain terminal, `omc team` falls back to a detached tmux session instead of splitting the current surface.
+- **tmux binary** must be installed and discoverable (`command -v tmux`) when running from a plain terminal; classic tmux sessions reuse the current tmux surface.
+- **cmux surface optional** for in-place native splits (`CMUX_SURFACE_ID` set without `$TMUX`). Plain terminals still use the detached tmux fallback.
 - **claude** CLI: `npm install -g @anthropic-ai/claude-code`
 - **codex** CLI: `npm install -g @openai/codex`
 - **gemini** CLI: `npm install -g @google/gemini-cli`
@@ -45,15 +45,15 @@ Spawn N CLI worker processes in tmux panes to execute tasks in parallel. Support
 
 ### Phase 0: Verify prerequisites
 
-Check tmux explicitly before claiming it is missing:
+Check the active multiplexer before claiming tmux is missing. If `$TMUX` is empty and `CMUX_SURFACE_ID` is also empty, check tmux explicitly:
 
 ```bash
 command -v tmux >/dev/null 2>&1
 ```
 
-- If this fails, report that **tmux is not installed** and stop.
+- If the plain-terminal tmux check fails, report that **tmux is not installed** and stop.
 - If `$TMUX` is set, `omc team` can reuse the current tmux window/panes directly.
-- If `$TMUX` is empty but `CMUX_SURFACE_ID` is set, report that the user is running inside **cmux**. Do **not** say tmux is missing or that they are "not inside tmux"; `omc team` will launch a **detached tmux session** for workers instead of splitting the cmux surface.
+- If `$TMUX` is empty but `CMUX_SURFACE_ID` is set, report that the user is running inside **cmux**. Do **not** say tmux is missing or that they are "not inside tmux"; `omc team` will create **native cmux splits** for workers.
 - If neither `$TMUX` nor `CMUX_SURFACE_ID` is set, report that the user is in a **plain terminal**. `omc team` can still launch a **detached tmux session**, but if they specifically want in-place pane/window topology they should start from a classic tmux session first.
 - If you need to confirm the active tmux session, use:
 
@@ -174,7 +174,7 @@ If encountered, switch to `omc team ...` CLI commands.
 | Error                        | Cause                               | Fix                                                                                 |
 | ---------------------------- | ----------------------------------- | ----------------------------------------------------------------------------------- |
 | `not inside tmux`            | Requested in-place pane topology from a non-tmux surface | Start tmux and rerun, or let `omc team` use its detached-session fallback           |
-| `cmux surface detected`      | Running inside cmux without `$TMUX` | Use the normal `omc team ...` flow; OMC will launch a detached tmux session         |
+| `cmux surface detected`      | Running inside cmux without `$TMUX` | Use the normal `omc team ...` flow; OMC will create native cmux worker splits      |
 | `Unsupported agent type`     | Requested agent is not claude/codex/gemini | Use `claude`, `codex`, or `gemini`; for native Claude Code agents use `/oh-my-claudecode:team` |
 | `codex: command not found`   | Codex CLI not installed             | `npm install -g @openai/codex`                                                      |
 | `gemini: command not found`  | Gemini CLI not installed            | `npm install -g @google/gemini-cli`                                                 |

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: