claudecode-omc 4.8.2 → 4.8.4

package/scripts/setup-progress.sh

@@ -0,0 +1,123 @@
+#!/usr/bin/env bash
+# setup-progress.sh - Save/clear/resume setup progress helpers
+# Usage:
+#   setup-progress.sh save <step_number> <config_type>
+#   setup-progress.sh clear
+#   setup-progress.sh resume
+#   setup-progress.sh complete <version>
+
+set -euo pipefail
+
+STATE_FILE=".omc/state/setup-state.json"
+CONFIG_FILE="$HOME/.claude/.omc-config.json"
+
+# Cross-platform ISO date to epoch conversion
+iso_to_epoch() {
+  local iso_date="$1"
+  local epoch=""
+  # Try GNU date first (Linux)
+  epoch=$(date -d "$iso_date" +%s 2>/dev/null) || true
+  if [ -n "$epoch" ] && [ "$epoch" != "0" ]; then
+    echo "$epoch"
+    return 0
+  fi
+  # Try BSD/macOS date
+  local clean_date
+  clean_date=$(echo "$iso_date" | sed 's/[+-][0-9][0-9]:[0-9][0-9]$//' | sed 's/Z$//' | sed 's/T/ /')
+  epoch=$(date -j -f "%Y-%m-%d %H:%M:%S" "$clean_date" +%s 2>/dev/null) || true
+  if [ -n "$epoch" ] && [ "$epoch" != "0" ]; then
+    echo "$epoch"
+    return 0
+  fi
+  echo "0"
+}
+
+cmd_save() {
+  local step="$1"
+  local config_type="${2:-unknown}"
+  mkdir -p .omc/state
+  cat > "$STATE_FILE" << EOF
+{
+  "lastCompletedStep": $step,
+  "timestamp": "$(date -Iseconds)",
+  "configType": "$config_type"
+}
+EOF
+  echo "Progress saved: step $step ($config_type)"
+}
+
+cmd_clear() {
+  rm -f "$STATE_FILE"
+  echo "Setup state cleared."
+}
+
+cmd_resume() {
+  if [ ! -f "$STATE_FILE" ]; then
+    echo "fresh"
+    return 0
+  fi
+
+  # Check if state is stale (older than 24 hours)
+  TIMESTAMP_RAW=$(jq -r '.timestamp // empty' "$STATE_FILE" 2>/dev/null)
+  if [ -n "$TIMESTAMP_RAW" ]; then
+    TIMESTAMP_EPOCH=$(iso_to_epoch "$TIMESTAMP_RAW")
+    NOW_EPOCH=$(date +%s)
+    STATE_AGE=$((NOW_EPOCH - TIMESTAMP_EPOCH))
+  else
+    STATE_AGE=999999  # Force fresh start if no timestamp
+  fi
+
+  if [ "$STATE_AGE" -gt 86400 ]; then
+    echo "Previous setup state is more than 24 hours old. Starting fresh."
+    rm -f "$STATE_FILE"
+    echo "fresh"
+    return 0
+  fi
+
+  LAST_STEP=$(jq -r ".lastCompletedStep // 0" "$STATE_FILE" 2>/dev/null || echo "0")
+  TIMESTAMP=$(jq -r .timestamp "$STATE_FILE" 2>/dev/null || echo "unknown")
+  CONFIG_TYPE=$(jq -r '.configType // "unknown"' "$STATE_FILE" 2>/dev/null || echo "unknown")
+  echo "Found previous setup session (Step $LAST_STEP completed at $TIMESTAMP, configType=$CONFIG_TYPE)"
+  echo "$LAST_STEP"
+}
+
+cmd_complete() {
+  local version="${1:-unknown}"
+
+  # Clear temporary state
+  rm -f "$STATE_FILE"
+
+  # Mark setup as completed in persistent config
+  mkdir -p "$(dirname "$CONFIG_FILE")"
+
+  local existing='{}'
+  if [ -f "$CONFIG_FILE" ]; then
+    existing=$(cat "$CONFIG_FILE")
+  fi
+
+  echo "$existing" | jq --arg ts "$(date -Iseconds)" --arg ver "$version" \
+    '. + {setupCompleted: $ts, setupVersion: $ver}' > "$CONFIG_FILE"
+
+  echo "Setup completed successfully!"
+  echo "Note: Future updates will only refresh CLAUDE.md, not the full setup wizard."
+}
+
+# Main dispatch
+case "${1:-}" in
+  save)
+    cmd_save "${2:?step number required}" "${3:-unknown}"
+    ;;
+  clear)
+    cmd_clear
+    ;;
+  resume)
+    cmd_resume
+    ;;
+  complete)
+    cmd_complete "${2:-unknown}"
+    ;;
+  *)
+    echo "Usage: setup-progress.sh {save <step> <config_type>|clear|resume|complete <version>}" >&2
+    exit 1
+    ;;
+esac

package/scripts/sync-metadata.ts

@@ -71,7 +71,7 @@ function loadMetadata(): Metadata {
     keywords: packageJson.keywords || [],
     repository: packageJson.repository?.url?.replace(/^git\+/, '').replace(/\.git$/, '') || '',
     homepage: packageJson.homepage || '',
-    npmPackage: packageJson.name || 'oh-my-claudecode',
+    npmPackage: packageJson.name || 'oh-my-claude-sisyphus',
   };
 }
 
@@ -165,6 +165,16 @@ function getFileSyncConfigs(): FileSync[] {
         },
       ],
     },
+    {
+      path: 'docs/CLAUDE.md',
+      replacements: [
+        {
+          pattern: /<!-- OMC:VERSION:[^\s]*? -->/g,
+          replacement: (m) => `<!-- OMC:VERSION:${m.version} -->`,
+          description: 'CLAUDE.md version marker',
+        },
+      ],
+    },
     {
       path: 'docs/ARCHITECTURE.md',
       replacements: [

package/skills/AGENTS.md

@@ -3,7 +3,7 @@
 
 # skills
 
-37 skill directories for workflow automation and specialized behaviors.
+33 skill directories for workflow automation and specialized behaviors.
 
 ## Purpose
 
@@ -31,20 +31,9 @@ Skills are reusable workflow templates that can be invoked via `/oh-my-claudecod
 | `plan/SKILL.md` | omc-plan | Strategic planning with interview workflow |
 | `ralplan/SKILL.md` | ralplan | Iterative planning (Planner+Architect+Critic) with RALPLAN-DR structured deliberation (`--deliberate` for high-risk) |
 | `deep-interview/SKILL.md` | deep-interview | Socratic deep interview with mathematical ambiguity gating (Ouroboros-inspired) |
-| `analyze/SKILL.md` | analyze | Deep analysis and investigation |
 | `ralph-init/SKILL.md` | ralph-init | Initialize PRD for structured ralph |
 | `quick-init-project/SKILL.md` | quick-init-project | Intelligent project bootstrap with mode selection (fullstack/frontend/backend/demo) and data-driven tech stack recommendations |
 
-### Code Quality Skills
-
-| File | Skill | Purpose |
-|-----------|-------|---------|
-| `code-review/SKILL.md` | code-review | Comprehensive code review |
-| `security-review/SKILL.md` | security-review | Security vulnerability detection |
-| `tdd/SKILL.md` | tdd | Test-driven development workflow |
-| `build-fix/SKILL.md` | build-fix | Fix build and TypeScript errors |
-| `ai-commenting/SKILL.md` | ai-commenting | AI-native code annotation protocol for intent/risk/deps/test context |
-
 ### Exploration Skills
 
 | File | Skill | Purpose |
@@ -56,13 +45,14 @@ Skills are reusable workflow templates that can be invoked via `/oh-my-claudecod
 
 | File | Skill | Purpose |
 |-----------|-------|---------|
+| `ai-slop-cleaner/SKILL.md` | ai-slop-cleaner | Regression-safe cleanup workflow for AI-generated code slop |
 | `learner/SKILL.md` | learner | Extract reusable skill from session |
-| `ask-codex/SKILL.md` | ask-codex | Ask Codex via `omc ask codex` and capture an artifact |
-| `ask-gemini/SKILL.md` | ask-gemini | Ask Gemini via `omc ask gemini` and capture an artifact |
+| `ask/SKILL.md` | ask | Ask Claude, Codex, or Gemini via `omc ask` and capture an artifact |
 | `note/SKILL.md` | note | Save notes for compaction resilience |
 | `cancel/SKILL.md` | cancel | Cancel any active OMC mode |
 | `hud/SKILL.md` | hud | Configure HUD display |
 | `omc-doctor/SKILL.md` | omc-doctor | Diagnose installation issues |
+| `setup/SKILL.md` | setup | Unified setup entrypoint for install, diagnostics, and MCP configuration |
 | `omc-setup/SKILL.md` | omc-setup | One-time setup wizard |
 | `omc-help/SKILL.md` | omc-help | Usage guide |
 | `mcp-setup/SKILL.md` | mcp-setup | Configure MCP servers |
@@ -91,6 +81,10 @@ triggers:
   - "keyword2"
 agent: executor  # Optional: which agent to use
 model: sonnet    # Optional: model override
+pipeline: [skill-name, follow-up-skill]  # Optional: standardized multi-skill flow
+next-skill: follow-up-skill              # Optional: explicit handoff target
+next-skill-args: --direct                # Optional: arguments for the next skill
+handoff: .omc/plans/example.md           # Optional: artifact/context handed to next skill
 ---
 
 # Skill Name
@@ -144,6 +138,8 @@ Any configurable options.
 4. Invoke `qa-tester` for verification
 ```
 
+If `pipeline` / `next-skill` metadata is present, OMC appends a standardized **Skill Pipeline** handoff block to the rendered skill prompt so downstream steps are explicit.
+
 **Conditional behavior:**
 ```markdown
 ## Workflow
@@ -175,10 +171,10 @@ None - pure markdown files.
 | Category | Skills | Trigger Keywords |
 |----------|--------|------------------|
 | Execution | autopilot, ultrawork, ralph, team, ultraqa | "autopilot", "ulw", "ralph", "team" |
-| Planning | omc-plan, ralplan, deep-interview, analyze, ralph-init | "plan this", "analyze", "interview me", "ouroboros" |
-| Quality | code-review, security-review, tdd, build-fix | "review", "security", "tdd" |
+| Cleanup | ai-slop-cleaner | "deslop", "anti-slop", cleanup/refactor + slop smells |
+| Planning | omc-plan, ralplan, deep-interview, ralph-init | "plan this", "interview me", "ouroboros" |
 | Exploration | deepinit, sciomc, external-context | "deepinit", "research" |
-| Utility | learner, note, cancel, hud, omc-doctor, omc-setup, omc-help, mcp-setup | "stop", "cancel" |
+| Utility | learner, note, cancel, hud, setup, omc-doctor, omc-setup, omc-help, mcp-setup | "stop", "cancel" |
 | Domain | psm, writer-memory, release | psm context |
 
 ## Auto-Activation

package/skills/ai-slop-cleaner/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: ai-slop-cleaner
+description: Clean AI-generated code slop with a test-first, deletion-first deslop workflow and optional reviewer-only mode
+---
+
+<Purpose>
+Use this skill to systematically clean AI-generated code slop without changing intended behavior. It focuses on simplifying existing code by deleting dead code, collapsing duplicates, removing needless abstractions, tightening boundaries, and reinforcing tests before and after cleanup.
+</Purpose>
+
+<Use_When>
+- The user explicitly says "deslop", "anti-slop", or "AI slop"
+- The request is to clean up or refactor code that feels bloated, repetitive, or overly abstract
+- The user wants a reviewer-only anti-slop pass via `--review` after cleanup work is drafted
+- The user calls out duplicate code, dead code, wrapper layers, boundary violations, or weak regression coverage
+- The goal is simplification, deletion, and cleanup rather than adding new features
+</Use_When>
+
+<Do_Not_Use_When>
+- The task is primarily a new feature build -- use `autopilot` or direct implementation instead
+- The user wants a broad architecture redesign rather than an incremental cleanup pass
+- The request is a generic refactor with no cleanup/simplification intent
+- Behavior is unclear and there are no tests or concrete anchors -- clarify scope first
+</Do_Not_Use_When>
+
+<Why_This_Exists>
+AI-generated code often works while still adding avoidable complexity: duplicate helpers, dead branches, wrapper layers, inconsistent naming, boundary leaks, and missing tests. This skill enforces a disciplined cleanup workflow so simplification happens deliberately instead of as vague "refactoring" that might expand scope.
+</Why_This_Exists>
+
+<Review_Mode>
+### Review Mode (`--review`)
+`--review` activates an explicit reviewer pass after the cleanup writer pass.
+
+- **Writer pass**: make the cleanup changes with behavior locked by tests.
+- **Reviewer pass (`--review`)**: inspect the result for duplication, dead code, boundary violations, missing tests, and unnecessary abstractions.
+- The same pass must not both write and self-approve without a separate review step.
+
+In review mode:
+1. Do **not** make edits first.
+2. Inspect the cleanup plan, changed files, and regression coverage.
+3. Check specifically for:
+   - leftover dead code or unused exports
+   - duplicate logic that was not consolidated
+   - needless wrappers or abstractions that still blur boundaries
+   - missing tests or weak verification for preserved behavior
+   - risky cleanup that changed behavior without explicit intent
+4. Produce a reviewer verdict with required follow-ups.
+5. If changes are needed, hand them back to a separate writer/executor pass instead of fixing and approving in one pass.
+
+This mode exists to preserve writer/reviewer separation: the authoring pass changes code, the reviewer pass evaluates whether the cleanup actually reduced slop safely.
+</Review_Mode>
+
+<Execution_Policy>
+- Preserve behavior unless the user explicitly asks for behavior changes
+- Lock behavior with regression tests first whenever practical
+- Write a cleanup plan before editing code
+- Prefer deletion over addition
+- Reuse existing utilities and patterns before introducing anything new
+- Avoid new dependencies unless the user explicitly requests them
+- Keep diffs small, reversible, and smell-focused
+- Keep writer/reviewer separation: author in one pass, review in another
+- Verify with lint/typecheck/tests/static analysis relevant to the touched area
+</Execution_Policy>
+
+<Steps>
+1. **Lock behavior first**
+   - Identify the current behavior and add or strengthen regression tests before cleanup when practical
+   - If tests cannot be added first, record the verification plan explicitly before editing
+
+2. **Create a cleanup plan**
+   - Do not start coding immediately
+   - List the targeted smells and the files likely involved
+   - Sequence cleanup passes from lowest-risk deletion to higher-risk consolidation
+
+3. **Categorize the slop**
+   - Duplicate code
+   - Dead or unused code
+   - Needless abstraction / wrapper layers
+   - Boundary violations / misplaced responsibilities
+   - Missing or weak tests
+
+4. **Execute one smell-focused pass at a time**
+   - **Pass 1: Dead code deletion** -- remove unused branches, helpers, exports, and stale comments
+   - **Pass 2: Duplicate removal** -- consolidate repeated logic into existing patterns where possible
+   - **Pass 3: Naming and error-handling cleanup** -- tighten naming, trim noisy plumbing, normalize obvious inconsistencies
+   - **Pass 4: Test reinforcement** -- fill any regression gaps revealed by the cleanup
+
+5. **Run quality gates**
+   - Run the relevant lint, typecheck, unit/integration tests, and any static or security checks already present for the touched area
+   - If a gate fails, fix the underlying issue or revert the risky cleanup instead of forcing it through
+
+6. **Optional `--review` pass**
+   - Run a distinct reviewer pass that checks duplication, dead code, boundary violations, test coverage, and needless abstractions
+   - If the reviewer finds issues, address them in a follow-up cleanup pass before closing the task
+
+7. **Report outcome**
+   - Changed files
+   - Simplifications made
+   - Behavior locked by tests
+   - Remaining risks or slop intentionally left for a later pass
+</Steps>
+
+<Examples>
+<Good>
+User: "deslop this module -- too many wrappers, duplicate helpers, and dead code"
+Why good: Explicit anti-slop intent with concrete cleanup smells.
+</Good>
+
+<Good>
+User: "cleanup the AI slop in src/auth: remove dead code and tighten boundaries"
+Why good: Cleanup/refactor request is clearly about simplification, not feature work.
+</Good>
+
+<Bad>
+User: "refactor auth to support SSO"
+Why bad: This is feature work disguised as refactoring, not anti-slop cleanup.
+</Bad>
+
+<Bad>
+User: "clean up formatting"
+Why bad: Formatting-only work does not need the full anti-slop workflow.
+</Bad>
+</Examples>
+
+<Final_Report>
+Always end with:
+- **Changed files**
+- **Simplifications**
+- **Verification run**
+- **Remaining risks**
+</Final_Report>

package/skills/analyze/SKILL.md

@@ -1,87 +1,42 @@
 ---
 name: analyze
-description: Deep analysis and investigation
+description: Deep analysis and investigation for bugs, architecture issues, and risk hotspots. Use when the user asks to analyze, investigate, debug, or explain why something is failing.
+agent: debugger
 ---
 
-<Purpose>
-Analyze performs deep investigation of architecture, bugs, performance issues, and dependencies. It routes to the architect Claude agent for thorough analysis and returns structured findings with evidence.
-</Purpose>
+# Analyze
 
-<Use_When>
-- User says "analyze", "investigate", "debug", "why does", or "what's causing"
-- User needs to understand a system's architecture or behavior before making changes
-- User wants root cause analysis of a bug or performance issue
-- User needs dependency analysis or impact assessment for a proposed change
-- A complex question requires reading multiple files and reasoning across them
-</Use_When>
+Use this skill for evidence-driven investigation before implementation.
 
-<Do_Not_Use_When>
-- User wants code changes made -- use executor agents or `ralph` instead
-- User wants a full plan with acceptance criteria -- use `plan` skill instead
-- User wants a quick file lookup or symbol search -- use `explore` agent instead
-- User asks a simple factual question that can be answered from one file -- just read and answer directly
-</Do_Not_Use_When>
+## Use When
 
-<Why_This_Exists>
-Deep investigation requires a different approach than quick lookups or code changes. Analysis tasks need broad context gathering, cross-file reasoning, and structured findings. Routing these to the architect agent or Codex ensures the right level of depth without the overhead of a full planning or execution workflow.
-</Why_This_Exists>
+- The user asks to analyze, investigate, debug, root-cause, or explain failures
+- A fix has failed repeatedly and the team needs diagnosis first
+- You need architecture or dependency impact analysis before making changes
 
-<Execution_Policy>
-- Route analysis to the architect Claude agent for thorough investigation
-- Always gather context files before spawning the architect agent for grounded reasoning
-- Return structured findings, not just raw observations
-</Execution_Policy>
+## Workflow
 
-<Steps>
-1. **Identify the analysis type**: Architecture, bug investigation, performance, or dependency analysis
-2. **Gather relevant context**: Read or identify the key files involved
-3. **Route to analyzer**: `Task(subagent_type="oh-my-claudecode:architect", model="opus", prompt="Analyze: ...")`
-4. **Return structured findings**: Present the analysis with evidence, file references, and actionable recommendations
-</Steps>
+1. Scope the target precisely.
+2. Gather evidence:
+   - Read relevant files and tests
+   - Reproduce the issue when possible
+   - Capture exact errors and stack traces
+3. Build and test hypotheses:
+   - Compare broken path vs working path
+   - Trace control/data flow
+   - Validate assumptions with commands
+4. Conclude with ranked findings and concrete next actions.
 
-<Tool_Usage>
-- Use `Task(subagent_type="oh-my-claudecode:architect", model="opus", ...)` as the primary analysis route
-- For broad analysis, use `explore` agent first to identify relevant files before routing to architect
-</Tool_Usage>
+## Debug Protocol
 
-<Examples>
-<Good>
-User: "analyze why the WebSocket connections drop after 30 seconds"
-Action: Gather WebSocket-related files, route to architect with context, return root cause analysis with specific file:line references and a recommended fix.
-Why good: Clear investigation target, structured output with evidence.
-</Good>
+- Root-cause first. Do not jump to fixes.
+- After 3 failed hypotheses, expand scope and challenge the initial assumption.
+- Prefer user-observable behavior and reproducible evidence over speculation.
 
-<Good>
-User: "investigate the dependency chain from src/api/routes.ts"
-Action: Use explore agent to map the import graph, then route to architect for impact analysis.
-Why good: Uses explore for fact-gathering, architect for reasoning.
-</Good>
+## Output Format
 
-<Bad>
-User: "analyze the auth module"
-Action: Returning "The auth module handles authentication."
-Why bad: Shallow summary without investigation. Should examine the module's structure, patterns, potential issues, and provide specific findings with file references.
-</Bad>
+- Summary (2-3 sentences)
+- Key findings (ranked by impact)
+- Evidence (file references, command output, repro notes)
+- Recommended next actions (minimal-risk order)
 
-<Bad>
-User: "fix the bug in the parser"
-Action: Running analysis skill.
-Why bad: This is a fix request, not an analysis request. Route to executor or ralph instead.
-</Bad>
-</Examples>
-
-<Escalation_And_Stop_Conditions>
-- If analysis reveals the issue requires code changes, report findings and recommend using `ralph` or executor for the fix
-- If the analysis scope is too broad ("analyze everything"), ask the user to narrow the focus
-- If Codex is unavailable and the architect agent also fails, report what context was gathered and suggest manual investigation paths
-</Escalation_And_Stop_Conditions>
-
-<Final_Checklist>
-- [ ] Analysis addresses the specific question or investigation target
-- [ ] Findings reference specific files and line numbers where applicable
-- [ ] Root causes are identified (not just symptoms) for bug investigations
-- [ ] Actionable recommendations are provided
-- [ ] Analysis distinguishes between confirmed facts and hypotheses
-</Final_Checklist>
-
-Task: {{ARGUMENTS}}

package/skills/ask/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: ask
+description: Ask Claude, Codex, or Gemini via local CLI and capture a reusable artifact
+---
+
+# Ask
+
+Use OMC's canonical advisor skill to route a prompt through the local Claude, Codex, or Gemini CLI and persist the result as an ask artifact.
+
+## Usage
+
+```bash
+/oh-my-claudecode:ask <claude|codex|gemini> <question or task>
+```
+
+Examples:
+
+```bash
+/oh-my-claudecode:ask codex "review this patch from a security perspective"
+/oh-my-claudecode:ask gemini "suggest UX improvements for this flow"
+/oh-my-claudecode:ask claude "draft an implementation plan for issue #123"
+```
+
+## Routing
+
+Preferred path:
+
+```bash
+omc ask {{ARGUMENTS}}
+```
+
+## Requirements
+
+- The selected local CLI must be installed and authenticated.
+- Verify availability with the matching command:
+
+```bash
+claude --version
+codex --version
+gemini --version
+```
+
+## Artifacts
+
+`omc ask` writes artifacts to:
+
+```text
+.omc/artifacts/ask/<provider>-<slug>-<timestamp>.md
+```
+
+Task: {{ARGUMENTS}}

package/skills/bdd-generator/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: bdd-generator
+description: Generate and maintain BDD scenarios and step definitions using Gherkin plus playwright-bdd with a one-scenario-at-a-time TDD loop.
+---
+
+# BDD Generator
+
+Use this skill to translate business requirements into executable BDD scenarios.
+
+## Use When
+
+- The user asks for BDD, Gherkin, feature files, or scenario-based tests
+- You need business-readable acceptance tests tied to Playwright execution
+
+## Setup
+
+```bash
+pnpm add -D @playwright/test playwright-bdd
+npx playwright install
+```
+
+```ts
+// playwright.config.ts
+import { defineConfig } from '@playwright/test';
+import { defineBddConfig } from 'playwright-bdd';
+
+const testDir = defineBddConfig({
+  features: 'features/**/*.feature',
+  steps: 'features/steps/**/*.ts',
+});
+
+export default defineConfig({ testDir });
+```
+
+## Workflow
+
+1. Write one feature and one scenario first (RED).
+2. Run `bddgen` to generate missing step stubs.
+3. Implement only the first failing step.
+4. Re-run tests; repeat until scenario passes.
+5. Add next scenario only after green.
+
+## Gherkin Best Practices
+
+- Use business language, not technical implementation details.
+- `Given` sets context, `When` describes action, `Then` verifies user-visible outcome.
+- Use `Background` for repeated context.
+- Use `Scenario Outline` for data variants.
+
+## Output
+
+- `*.feature` file with clear business behavior
+- Step definitions in `features/steps/*.ts`
+- Command list to run and debug tests
+
+## References
+
+- Cucumber Gherkin reference: https://cucumber.io/docs/gherkin/reference
+- playwright-bdd: https://github.com/vitalets/playwright-bdd
+

package/skills/ccg/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: ccg
-description: Claude-Codex-Gemini tri-model orchestration via ask-codex + ask-gemini, then Claude synthesizes results
+description: Claude-Codex-Gemini tri-model orchestration via /ask codex + /ask gemini, then Claude synthesizes results
 ---
 
 # CCG - Claude-Codex-Gemini Tri-Model Orchestration
 
-CCG routes through `ask-codex` and `ask-gemini` (CLI advisor flow), then Claude synthesizes both outputs into one answer.
+CCG routes through the canonical `/ask` skill (`/ask codex` + `/ask gemini`), then Claude synthesizes both outputs into one answer.
 
 Use this when you want parallel external perspectives without launching tmux team workers.
 
@@ -31,8 +31,8 @@ Use this when you want parallel external perspectives without launching tmux tea
    - Gemini prompt (UX/design/docs/alternatives)
 
 2. Claude runs:
-   - /oh-my-claudecode:ask-codex "<codex prompt>"
-   - /oh-my-claudecode:ask-gemini "<gemini prompt>"
+   - /oh-my-claudecode:ask codex "<codex prompt>"
+   - /oh-my-claudecode:ask gemini "<gemini prompt>"
 
    (equivalent CLI path: `omc ask codex ...` + `omc ask gemini ...`)
 
@@ -57,8 +57,8 @@ Split the user request into:
 Use skill routing first:
 
 ```bash
-/oh-my-claudecode:ask-codex <codex prompt>
-/oh-my-claudecode:ask-gemini <gemini prompt>
+/oh-my-claudecode:ask codex <codex prompt>
+/oh-my-claudecode:ask gemini <gemini prompt>
 ```
 
 Equivalent direct CLI:

package/skills/deep-interview/SKILL.md

@@ -2,6 +2,10 @@
 name: deep-interview
 description: Socratic deep interview with mathematical ambiguity gating before autonomous execution
 argument-hint: "<idea or vague description>"
+pipeline: [deep-interview, omc-plan, autopilot]
+next-skill: omc-plan
+next-skill-args: --consensus --direct
+handoff: .omc/specs/deep-interview-{slug}.md
 ---
 
 <Purpose>