{"owner":"Yeachan-Heo","repo":"oh-my-codex","hasSkills":true,"totalSkillsCount":59,"totalTokensCount":81824,"categories":["marketplace","plugin-manifest","anthropic-skill","root-instruction"],"hasMcp":false,"mcpConfig":null,"found":[".agents/plugins/marketplace.json","packages/vscode-extension/README.md","plugins/oh-my-codex/.codex-plugin/plugin.json","plugins/oh-my-codex/skills/ai-slop-cleaner/SKILL.md","plugins/oh-my-codex/skills/analyze/SKILL.md","plugins/oh-my-codex/skills/ask/SKILL.md","plugins/oh-my-codex/skills/autopilot/SKILL.md","plugins/oh-my-codex/skills/autoresearch/SKILL.md","plugins/oh-my-codex/skills/best-practice-research/SKILL.md","plugins/oh-my-codex/skills/cancel/SKILL.md","plugins/oh-my-codex/skills/code-review/SKILL.md","plugins/oh-my-codex/skills/configure-notifications/SKILL.md","plugins/oh-my-codex/skills/deep-interview/SKILL.md","plugins/oh-my-codex/skills/design/SKILL.md","plugins/oh-my-codex/skills/doctor/SKILL.md","plugins/oh-my-codex/skills/hud/SKILL.md","plugins/oh-my-codex/skills/omx-setup/SKILL.md","plugins/oh-my-codex/skills/performance-goal/SKILL.md","plugins/oh-my-codex/skills/plan/SKILL.md","plugins/oh-my-codex/skills/ralplan/SKILL.md","plugins/oh-my-codex/skills/skill/SKILL.md","plugins/oh-my-codex/skills/team/SKILL.md","plugins/oh-my-codex/skills/ultragoal/SKILL.md","plugins/oh-my-codex/skills/ultraqa/SKILL.md","plugins/oh-my-codex/skills/visual-ralph/SKILL.md","plugins/oh-my-codex/skills/wiki/SKILL.md","plugins/oh-my-codex/skills/worker/SKILL.md","plugins/oh-my-codex/templates/AGENTS.md","skills/ai-slop-cleaner/SKILL.md","skills/analyze/SKILL.md","skills/ask/SKILL.md","skills/autopilot/SKILL.md","skills/autoresearch-goal/SKILL.md","skills/autoresearch/SKILL.md","skills/best-practice-research/SKILL.md","skills/cancel/SKILL.md","skills/code-review/SKILL.md","skills/configure-notifications/SKILL.md","skills/deep-interview/SKILL.md","skills/design/SKILL.md","skills/doctor/SKILL.md","skills/git-master/SKILL.md","skills/hud/SKILL.md","skills/omx-setup/SKILL.md","skills/performance-goal/SKILL.md","skills/pipeline/SKILL.md","skills/plan/SKILL.md","skills/ralph/SKILL.md","skills/ralplan/SKILL.md","skills/skill/SKILL.md","skills/team/SKILL.md","skills/ultragoal/SKILL.md","skills/ultraqa/SKILL.md","skills/ultrawork/SKILL.md","skills/ultrawork/references/agent-tiers.md","skills/visual-ralph/SKILL.md","skills/wiki/SKILL.md","skills/worker/SKILL.md","templates/AGENTS.md"],"skills":{".agents/plugins/marketplace.json":"","packages/vscode-extension/README.md":"","plugins/oh-my-codex/.codex-plugin/plugin.json":"","plugins/oh-my-codex/skills/ai-slop-cleaner/SKILL.md":"---\nname: ai-slop-cleaner\ndescription: Run an anti-slop cleanup/refactor/deslop workflow\n---\n\n# AI Slop Cleaner Task Card\n\nUse this bounded helper for cleanup/refactor/deslop work, not as a competing top-level\nworkflow. Shared operating invariants live in `templates/AGENTS.md`; this card defines\nscope, smell taxonomy, passes, and evidence.\n\n## When to use and inputs\n\nUse when working code is bloated, noisy, repetitive, over-abstracted, or AI-generated;\nthe user requests cleanup/refactor/deslop; or a follow-up left duplicate/dead code,\nweak boundaries, missing tests, fallback-like paths, or wrappers. Inputs are the requested\nfeature/files and behavior to preserve. A file list scope is valid; keep the pass bounded\nto it. Limit the pass to the calling task's changed files unless broader cleanup was requested.\n\n## Before editing\n\n1. **Lock behavior with regression tests first**: identify behavior to preserve, run/add the narrowest targeted tests, and cover both primary and preserved compatibility/fail-safe fallback paths.\n2. **Create a cleanup plan before code**: list scope and smells, include fallback findings/classifications/escalation, and order safest/highest-signal fixes first.\n3. **Inventory fallback-like code** in scope: quick hacks, temporary workaround, temporary fallback, just bypass, just skip, fallback if it fails, swallowed errors, silent defaults, broad compatibility shims, and duplicate alternate execution paths.\n4. Classify each fallback: **Masking fallback slop** hides evidence, bypasses the contract, suppresses validation, swallows failures, silently defaults, or adds untested paths; **Grounded compatibility/fail-safe fallback** is narrow at an external/version/fail-safe boundary, documents rationale, preserves failure evidence, and tests primary plus fallback.\n5. Prefer root-cause repair, deletion, boundary repair, or explicit failure behavior. For broad/ambiguous/cross-layer/architectural findings, invoke `$ralplan` for consensus resolution; when already inside ralplan, ultragoal, team, or another OMX workflow, do not spawn a nested `$ralplan`—attach the finding to the active handoff.\n\n## Smell taxonomy and passes\n\nClassify before changing:\n\n- **Fallback-like code**: masking fallbacks, workaround branches, bypasses, swallowed errors, silent defaults, broad shims, alternate paths.\n- **Duplication**: repeated logic, copy-paste branches, redundant helpers.\n- **Dead code**: unused/unreachable code, stale flags, debug leftovers.\n- **Needless abstraction**: pass-through wrappers, speculative indirection, single-use layers.\n- **Boundary violations**: hidden coupling, leaky responsibilities, wrong-layer imports/side effects.\n- **Missing tests**: behavior not locked or edge cases uncovered.\n- **UI/design slop**: context-sensitive signals, not absolute bans; preserve intentional brand, design-system, accessibility, or product-context exceptions. Challenge Korean body text at 11-12px (generally 14px or larger); gratuitous box shadows; repetitive eyebrow + title + description + paragraph stacks and generic emoji badges; default AI blue/purple such as `#3B82F6`; reflexive 3-column or 4-column grids; and extreme gradients unless justified by context.\n\nResolve the fallback-like code resolution gate first, then one smell at a time:\n**Pass 1: Dead code deletion**; **Pass 2: Duplicate removal**; **Pass 3: Naming/error\nhandling cleanup**; **Pass 4: Test reinforcement**. Re-run targeted verification after\neach pass and avoid unrelated refactors. Prefer deletion/existing utilities; no new\nabstractions or dependencies unless explicitly required.\n\n## Evidence/output contract\n\nReport:\n\n```text\nAI SLOP CLEANUP REPORT\nScope: [files/feature]\nBehavior Lock: [targeted tests added/run]\nCleanup Plan: [bounded smells/order]\nFallback Findings: [finding -> masking fallback slop | grounded compatibility/fail-safe fallback -> escalation]\nUI/Design Findings: [none/N/A or signal -> action/defer -> intentional rationale]\nPasses Completed: [resolution gate; Passes 1-4]\nQuality Gates: Regression tests, Lint, Typecheck, Tests, Static/security scan (PASS/FAIL/N/A)\nChanged Files: [path -> simplification]\nRemaining Risks: [none or deferred item]\n```\n\nInclude changed files, simplifications, fallback classifications/escalation status,\ntests/diagnostics/build checks run, UI findings when relevant, and deferred risks. Keep\nwriter/reviewer separation for cleanup plans and approvals.\n\n## Exit condition\n\nStop when the requested scope has behavior-lock evidence, each selected smell pass is\ncomplete or explicitly deferred with rationale, verification is reported, and no\nunrelated files or temporary artifacts remain. Never present an unverified cleanup as\ncomplete; escalate a real architectural blocker rather than masking it.\n","plugins/oh-my-codex/skills/analyze/SKILL.md":"---\nname: analyze\ndescription: \"Run read-only deep repository analysis and return a ranked synthesis with explicit confidence, concrete file references, and clear evidence-vs-inference boundaries. Use when a user says 'analyze', 'investigate', 'why does', 'what's causing', or needs grounded cross-file explanation before any changes are proposed.\"\n---\n\n# Analyze — Read-Only Deep Analysis\n\nUse `$analyze` to answer a repository question with grounded, read-only evidence. Explain what the code most likely says; do not turn analysis into implementation or generic fix planning.\n\nShared operating, delegation, state, hook, team, cancellation, and verification invariants live in [`templates/AGENTS.md`](../../templates/AGENTS.md). Follow that source instead of duplicating its rules here.\n\n## Use when\n\n- The user needs a causal, architectural, behavioral, impact, or tradeoff explanation.\n- The answer requires tracing multiple files or boundaries, or ranking plausible explanations.\n- The user needs confidence and concrete evidence before changing anything.\n\nDo not use it for edits, implementation, a new product plan, a simple one-file lookup, or OMX team-runtime operation.\n\n## Inputs and method\n\n1. Restate the question and define the evidence-backed scope.\n2. Identify the smallest files, tests, configs, and docs likely to answer it.\n3. Read direct code paths and contracts first; trace boundaries only as far as needed.\n4. Compare competing explanations, rank them by support, and mark unresolved points.\n5. Stop when the question is answered with sufficient evidence, or name the smallest read-only probe that would resolve the remaining uncertainty.\n\n## Evidence discipline\n\nLabel every material claim as one of:\n\n- **Evidence** — directly shown by code, tests, generated artifacts, configuration, or docs.\n- **Inference** — a reasoned conclusion drawn from cited evidence.\n- **Unknown** — not settled by the repository evidence.\n\nPrefer direct paths and independent corroboration over contextual clues. Never present guesses as evidence or inference, and never overclaim certainty.\n\n## Output contract\n\nAnswer the asked question first and use this shape:\n\n### Question\nRestated question, briefly.\n\n### Ranked synthesis\n| Rank | Explanation | Confidence | Basis |\n|------|-------------|------------|-------|\n| 1 | ... | High / Medium / Low | strongest supporting evidence |\n| 2 | ... | High / Medium / Low | why it trails |\n| 3 | ... | High / Medium / Low | why it remains possible |\n\n### Evidence\n- `path/to/file:line-line` — direct observation.\n- `path/to/file:line-line` — corroborating observation.\n\n### Inference\n- What the evidence most strongly implies.\n- Why weaker alternatives were down-ranked.\n\n### Unknowns / limits\n- What the repository does not establish.\n- The next discriminating read-only probe, when useful.\n\n## Stop conditions\n\n- Do not edit files, run an implementation lane, or make recommendations the evidence cannot support.\n- Do not continue searching after the answer and confidence boundary are grounded.\n- If evidence is insufficient, report the limit explicitly rather than manufacturing certainty.\n\nTask: {{ARGUMENTS}}\n","plugins/oh-my-codex/skills/ask/SKILL.md":"---\nname: ask\ndescription: Ask a local external advisor CLI (Claude or Gemini) and capture a reusable artifact\n---\n\n# Ask (Local Advisor CLI)\n\nUse a locally installed external advisor CLI for focused questions, reviews, brainstorming, or second opinions. This skill replaces the separate `ask-claude` and `ask-gemini` skills.\n\n## Usage\n\n```bash\n$ask claude \n$ask gemini \nomx ask claude \"\"\nomx ask gemini \"\"\n```\n\n## Backend selection\n\n- Use `claude` when the user asks for Claude, Anthropic, or the previous `$ask-claude` behavior.\n- Use `gemini` when the user asks for Gemini or the previous `$ask-gemini` behavior.\n- If no backend is specified, choose the installed backend that best matches the user request; if neither is clearly available, explain that a local CLI is required.\n\n## Local CLI commands\n\nClaude:\n\n```bash\nomx ask claude \"{{ARGUMENTS}}\"\nclaude -p \"{{ARGUMENTS}}\"\n```\n\nGemini:\n\n```bash\nomx ask gemini \"{{ARGUMENTS}}\"\ngemini -p \"{{ARGUMENTS}}\"\n```\n\nIf needed, adapt to the user's installed CLI variant while keeping local execution as the default path. Do not silently switch to an MCP or remote provider when the local binary is missing.\n\n## Artifact requirement\n\nAfter local execution, save a markdown artifact to:\n\n```text\n.omx/artifacts/ask---.md\n```\n\nMinimum artifact sections:\n1. Original user task\n2. Backend and final prompt sent to the CLI\n3. Raw CLI output\n4. Concise summary\n5. Action items / next steps\n\nTask: {{ARGUMENTS}}\n","plugins/oh-my-codex/skills/autopilot/SKILL.md":"---\nname: autopilot\ndescription: \"[OMX] Canonical autonomous orchestrator: $deep-interview -> $ralplan -> $ultragoal\"\n---\n\n# Autopilot\n\n\nAutopilot is the first-class canonical orchestrator for hands-off delivery. Its defining default chain is mandatory:\n\n```text\n$deep-interview -> $ralplan -> $ultragoal\n```\n\nThe chain is not a list of optional hints and Autopilot is not an alias for direct execution. Autopilot supervises each child stage in one recoverable session, carries durable artifacts forward, and continues through implementation verification until the requested outcome is complete or a genuine blocker is recorded.\n\n\n\n- The user explicitly invokes `$autopilot`.\n- The user asks for end-to-end autonomous delivery from an idea, issue, or requirements seed.\n- The work needs requirements clarification, consensus planning, durable execution, and evidence-backed completion as one supervised workflow.\n\n\n\nRun or resume these stages in order:\n\n1. **`deep-interview`** — clarify intent, scope, non-goals, constraints, acceptance criteria, and unresolved decisions. Produce a durable requirements/specification handoff. Deep Interview is a real stage; do not replace it with a one-question check or skip it merely because the task looks actionable.\n2. **`ralplan`** — turn the clarified requirements into an execution-ready consensus plan with architecture, sequencing, test, and verification guidance. Preserve review evidence as lifecycle evidence, not host-issued security authority.\n3. **`ultragoal`** — execute the approved plan through durable goals and ledger receipts, implementation, focused verification, cleanup, review, and terminal evidence.\n\n`$team`, `$code-review`, and `$ultraqa` may be used inside the supervised execution when the active Ultragoal plan or verification boundary requires them. They do not replace or weaken the defining three-stage chain.\n\nWhen review or QA proves the requirements or plan wrong, keep Autopilot active, return its supervised phase to `ralplan`, attach the findings, and continue through `ultragoal` again. Implementation-only review fixes may remain within Ultragoal's blocker/review loop.\n\n\n\n- Autopilot MUST begin at `deep-interview` for a new run and MUST preserve the phase order `deep-interview -> ralplan -> ultragoal`.\n- Child stages are supervised phases, not peer workflow activations. Keep `mode:\"autopilot\"` active and update `current_phase` rather than replacing Autopilot with standalone child state.\n- Use the current CLI state SSOT (`omx state ... --json`) and the current session-scoped state root. Do not create a second writer or revive legacy root-state authority.\n- Local artifacts, prompts, trackers, transcripts, environment values, and role labels are lifecycle evidence only. Do not reintroduce the retired unrecoverable host-receipt lock or terminalize the workflow because host provenance is unavailable.\n- Authority-decreasing operations are always recoverable: `$cancel`, state clear, hook disable/uninstall recovery, and stale-state repair must remain available without completion receipts or child-stage approval.\n- Continue automatically through safe, reversible stage transitions. Stop only for an explicit user cancellation, a human-only dependency, or a verified terminal result.\n\n\n\nAutopilot state is session-scoped and owned by the canonical state writer. A new run records at least:\n\n```json\n{\n \"mode\": \"autopilot\",\n \"active\": true,\n \"current_phase\": \"deep-interview\",\n \"iteration\": 1,\n \"phase_cycle\": [\"deep-interview\", \"ralplan\", \"ultragoal\"],\n \"handoff_artifacts\": {\n \"deep_interview\": null,\n \"ralplan\": null,\n \"ultragoal\": null\n },\n \"return_to_ralplan_reason\": null\n}\n```\n\nStart or update state only through the CLI-first state surface:\n\n```bash\nomx state write --input '{\"mode\":\"autopilot\",\"active\":true,\"current_phase\":\"deep-interview\",\"state\":{\"phase_cycle\":[\"deep-interview\",\"ralplan\",\"ultragoal\"],\"handoff_artifacts\":{\"deep_interview\":null,\"ralplan\":null,\"ultragoal\":null},\"return_to_ralplan_reason\":null}}' --json\n```\n\nStage transitions:\n\n- **`deep-interview -> ralplan`**: require a durable clarified requirements/specification artifact and a non-empty completion rationale. Preserve same-session question evidence when a question surface was used.\n- **`ralplan -> ultragoal`**: require durable planning artifacts, sequential Architect then Critic approvals, and a session/review-cycle-bound `ralplan_execution_handoff`. For supervised Autopilot, the explicit Autopilot request is the source of that bound handoff. Ordinary progression MUST NOT depend on a host-issued consensus receipt; missing host provenance is not a blocker.\n- **`ultragoal -> complete`**: require durable goal/ledger completion receipts and fresh verification evidence matching the requested outcome.\n- **review/QA loopback**: keep Autopilot active, set `current_phase:\"ralplan\"`, and persist `return_to_ralplan_reason` plus the findings.\n- **cancellation**: run `$cancel`; preserve handoff artifacts for inspection or resume and mark the exact session terminal without deleting unrelated state.\n- **clear/recovery**: exact-session clear may remove corrupt or stale Autopilot state. It must not require forward-progression evidence and must not clear other skills or sessions.\n\n\n\nWhen the user says `continue`, `resume`, or `keep going`, read the current session's `autopilot-state.json` and continue from `current_phase`:\n\n- `deep-interview`: resume clarification and produce the requirements handoff.\n- `ralplan`: resume consensus planning from the deep-interview artifact and any loopback findings.\n- `ultragoal`: resume durable execution from the approved plan and ledger.\n- `complete`: report the terminal evidence; do not restart.\n- `cancelled`, `cleared`, or `failed`: report preserved artifacts and start a new run only on a new explicit Autopilot request.\n\nNever discard valid handoff artifacts or restart discovery merely because the conversation resumed.\n\n\n\nAutopilot continuation hooks may nudge an active non-terminal run, but they MUST fail open for recovery:\n\n- A stale, malformed, cancelled, cleared, complete, or foreign-session state must not keep Stop blocked.\n- `$cancel`, exact-session state clear, and setup hook disable/uninstall paths must remain executable while Autopilot is active or damaged.\n- Continuation must be bounded and session-scoped; never recreate an unconditional hook lock.\n\n\n\n- [ ] A new run started with `deep-interview`.\n- [ ] Deep Interview produced a durable clarified requirements/specification handoff.\n- [ ] Ralplan produced an execution-ready plan with lifecycle review evidence.\n- [ ] Ultragoal completed the plan with durable goals and ledger receipts.\n- [ ] Verification evidence covers the requested behavior, failure paths, and recovery paths.\n- [ ] Missing host provenance did not block ordinary progression, cancel, clear, or hook recovery.\n- [ ] Autopilot state is terminal and exact-session artifacts remain coherent.\n\n\n\n\nUser: `$autopilot implement issue #42`\nFlow: activate Autopilot at `deep-interview`, crystallize requirements, continue to supervised `ralplan`, then supervised `ultragoal`, verify the completed outcome, and mark the exact session complete.\n\n\n\nUser: `continue`\nContext: Autopilot state has `current_phase:\"ralplan\"`.\nFlow: resume the existing plan from the deep-interview handoff; do not create a separate standalone Ralplan run.\n\n\n\nFlow: treat `$deep-interview`, `$ralplan`, and `$ultragoal` as optional suggestions and jump directly to implementation.\nWhy bad: this hollows out Autopilot's defining orchestration contract.\n\n\n\nTask: {{ARGUMENTS}}\n","plugins/oh-my-codex/skills/autoresearch/SKILL.md":"---\nname: autoresearch\ndescription: Stateful validator-gated research loop with native-hook persistence\n---\n\n# Autoresearch\n\nAutoresearch is the skill-first replacement for the deprecated `omx autoresearch` command.\nIt keeps the useful measured-research loop, but it now runs as a native-hook stateful workflow instead of a direct CLI or tmux launch surface.\n\n## Boundary with planning research\n\nUse `$autoresearch` when the research output itself is a bounded deliverable that must pass an explicit validator. Do not recommend it for ordinary pre-planning docs lookup or general best-practice checks; use `$best-practice-research` for that. If `$autoresearch` is intentionally run before architecture planning, its approved artifact should feed evidence into `$ralplan`; it should not become a final architecture/component unless the user explicitly asks for ongoing research automation.\n\n## Use when\n- You want a Ralph-ish persistent research loop\n- The task should keep nudging until explicit validation evidence exists\n- You want init-time choice between script validation and prompt+architect validation\n\n## Do not use when\n- You want the old `omx autoresearch` command surface (hard-deprecated)\n- You want detached tmux or split-pane launch parity\n- You have not decided the validation regime yet\n\n## Core contract\n1. **Init chooses validation mode.** Pick exactly one:\n - `mission-validator-script`\n - `prompt-architect-artifact`\n2. **Persist mode state** in `.omx/state/.../autoresearch-state.json` including:\n - `validation_mode`\n - `completion_artifact_path`\n - `mission_validator_command` **or** `validator_prompt`\n - optional `output_artifact_path`\n3. **Completion is artifact-gated.** The loop does not stop because the model says “done”, because a stop hook fired once, or because several turns were no-ops.\n4. **Direct CLI launch is gone.** Use `$deep-interview --autoresearch` for intake and `$autoresearch` for execution.\n\n## Completion artifact contract\n\n### `mission-validator-script`\nThe completion artifact must exist and record a passing validator result, for example:\n\n```json\n{\n \"status\": \"passed\",\n \"passed\": true,\n \"summary\": \"metric improved beyond baseline\"\n}\n```\n\n### `prompt-architect-artifact`\nThe completion artifact must include both an architect approval verdict and an output artifact path, for example:\n\n```json\n{\n \"validator_prompt\": \"Review the research output against the mission.\",\n \"architect_review\": { \"verdict\": \"approved\" },\n \"output_artifact_path\": \".omx/specs/autoresearch-demo/report.md\"\n}\n```\n\n## Recommended flow\n1. Run `$deep-interview --autoresearch` to clarify mission + evaluator.\n2. Materialize `.omx/specs/autoresearch-{slug}/mission.md`, `sandbox.md`, and `result.json`.\n3. Start `$autoresearch` with the chosen validation mode stored in mode state.\n4. Let stop-hook / auto-nudge continue until the completion artifact satisfies the chosen validation mode.\n5. Finish only after the validator artifact is complete.\n\n## Migration note\n- `omx autoresearch` is hard-deprecated.\n- No direct CLI launch.\n- No tmux split-pane launch.\n- No noop-count completion gate.\n","plugins/oh-my-codex/skills/best-practice-research/SKILL.md":"---\nname: best-practice-research\ndescription: \"[OMX] Bounded best-practice research wrapper using official/upstream evidence first\"\nargument-hint: \"\"\n---\n\n# Best-Practice Research\n\nUse this skill when a task depends on current external best practices, version-aware guidance, standards, official recommendations, or upstream behavior. This is a workflow wrapper: it routes evidence gathering and synthesis; it is not a new research authority and it does not replace `researcher`.\n\n## Purpose\n\nProduce a cited, reusable best-practice answer or handoff that separates current external evidence from repo-local facts and dependency-selection decisions. For pre-planning investigation, this is the ordinary first research wrapper: gather official/upstream evidence, then hand it to `$ralplan` or the caller as planning input. Do not present `$best-practice-research` as a final architecture component or as a validator-gated research loop.\n\n## Terminal By Default\n\nThis skill is terminal and read-only by default. It gathers evidence and produces a cited recommendation with a handoff, then stops. Do not write or edit files, create or amend commits, run mutating commands, or otherwise modify repository state under this skill — even when the question has clear implementation implications. When implementation is warranted, stop and hand off rather than continuing: name `$ralplan` for planning and `$ultragoal`, `$team`, or `executor` for execution, and resume only after the user explicitly switches to that workflow.\n\n## Activate When\n\n- The user asks for best practices, recommended approach, current guidance, official recommendations, standards, or version-aware external behavior.\n- `$ralplan`, `$deep-interview`, `$team`, or another workflow needs current external evidence before planning or execution can be correct.\n- The task involves an already chosen technology and needs authoritative usage guidance, migration notes, API behavior, lifecycle rules, or current safety guidance.\n\n## Do Not Activate When\n\n- The answer is fully repo-local; use `explore` for codebase facts.\n- The main question is whether to adopt, replace, upgrade, or compare dependencies; use `dependency-expert`.\n- The user only needs implementation against already-grounded requirements; execute directly, or use `$team` when coordinated parallel work is warranted.\n- The task can be answered from stable local project conventions without current external lookup.\n\n## Specialist Routing\n\n1. Use `explore` first for brownfield facts: current code usage, local constraints, versions, config, and integration points.\n2. Use `researcher` for official/upstream docs, release notes, standards, migration guides, source-backed examples, and current best-practice evidence for an already chosen technology.\n3. Use `dependency-expert` only for adoption/upgrade/replacement/comparison decisions.\n4. Return to the caller with explicit evidence, uncertainty, and any implementation handoff constraints.\n\n## Source-Quality Rules\n\n- Prefer official documentation, upstream source, release notes, changelogs, standards, and maintainer guidance.\n- Include source URLs for material claims.\n- State date/version context for current best-practice claims.\n- Label third-party summaries as supplemental; do not use them before official/upstream sources.\n- Flag stale, conflicting, undocumented, or version-mismatched evidence.\n- Do not over-fetch: gather the smallest evidence set that can support the decision.\n\n## Workflow\n\n1. Classify the question: conceptual best practice, implementation guidance, migration/version guidance, standards/compliance guidance, or mixed local + external guidance.\n2. Gather repo-local facts with `explore` when local usage or constraints affect the answer.\n3. Gather external evidence with `researcher` when current or version-aware practice affects correctness.\n4. Synthesize a concise answer with source quality, version/date context, caveats, and an implementation or planning handoff.\n5. Stop when the answer is grounded enough for the caller; otherwise report the exact blocker or specialist handoff needed.\n\n## Output Contract\n\n```md\n## Best-Practice Research: \n\n### Direct Recommendation\n\n\n### Evidence Used\n- Official/upstream: — \n- Supplemental, if any: — \n\n### Version / Date Context\n\n\n### Repo-Local Context\n\n\n### Boundaries / Non-goals\n\n\n### Handoff\n\n```\n\n## Stop Rules\n\n- Stop after a source-backed recommendation is reusable by the caller.\n- Stop and route upward if the task becomes dependency comparison, broad architecture, or implementation.\n- Do not continue researching when remaining work would only polish wording rather than change the recommendation.\n- This skill never implements. After delivering the recommendation and handoff, stop; do not modify repo files or repo state. Resume only when the user explicitly switches to a planning or implementation workflow named in the handoff.\n\nTask: {{ARGUMENTS}}\n","plugins/oh-my-codex/skills/cancel/SKILL.md":"---\nname: cancel\ndescription: Cancel any active OMX mode (autopilot, ralph, ultrawork, ecomode, ultraqa, swarm, ultrapilot, pipeline, team)\n---\n\n# Cancel Skill\n\n## When to use\n\nUse `/cancel` (or `cancelomc` / `stopomc`) to stop an active OMX mode and perform its documented cleanup. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot` first; it is the invariant authority for scope, ownership, hooks, and Team cleanup.\n\n## Inputs and preconditions\n\n- Accepted forms are `/cancel` and `/cancel --force`.\n- Reject `--all`, unknown flags, repeated flags, and mixed flags before mutation.\n- Discover the current session/root with the state read surfaces before cleanup:\n ```bash\n omx state list-active --json\n omx state get-status --mode --json\n ```\n- Confirm the current session/root and exact target before cleanup; stop when the required evidence is missing.\n\n## Operational steps\n\n1. Parse and validate arguments; select one exact session/root scope.\n2. Inspect active modes in dependency order:\n `autopilot → ralph → ultrawork → ecomode → ultraqa → swarm → ultrapilot → pipeline → team → plan-consensus`.\n3. Cancel Autopilot while preserving its resumable state; clean only linked child modes it owns.\n4. For Ralph, terminalize the target state (`active:false`, `current_phase:\"cancelled\"`, `completed_at`) and terminalize a proven linked Ultrawork/Ecomode state in the same scope. Confirm the post-conditions in `docs/contracts/ralph-cancel-contract.md`.\n5. Clear standalone modes only after proving they are not linked to another active mode.\n6. For Team, inspect the runtime with `omx team status --json`; use `omx team shutdown ` after the normal completion gate, or follow the explicit abort path.\n7. Clear only the selected mode/session state through the state API, for example:\n ```bash\n omx state clear --input '{\"mode\":\"\",\"session_id\":\"\"}' --json\n ```\n8. With `--force`, perform its documented native-stop cleanup. Report rollback or cleanup failures rather than claiming success.\n\n## Exit and evidence\n\nReport one result per selected mode: mode, scope/session, terminal phase, preserved state, linked cleanup, and any refusal reason. A clean no-op reports `No active OMX modes detected.` Include Team status and shutdown evidence when Team was selected.\n","plugins/oh-my-codex/skills/code-review/SKILL.md":"---\nname: code-review\ndescription: Run a comprehensive code review\n---\n\n# Code Review Task Card\n\nUse this explicit opt-in for a merge-readiness review. Shared operating invariants\nlive in `templates/AGENTS.md`; this card only defines review-specific behavior.\n\n## When to use\n\n- The user asks for a code review or quality/security assessment.\n- A change is ready for review before merge, or a major feature needs an independent review.\n- Do not activate this card for implementation, broad planning, or automatic cleanup.\n\n## Inputs\n\n- Scope: the requested files, commit, PR, or whole diff.\n- Requirements/specification, acceptance criteria, and relevant test/CI evidence.\n- Existing review artifacts and known risks, if any.\n- If the user says `continue`, advance the current verified review step rather than restarting discovery.\n\nStart by recording the scope:\n\n```sh\ngit status --short\ngit diff --stat\ngit diff -- \n```\n\n## Execution\n\n1. Identify changed files and review boundaries; do not silently widen the scope.\n2. Launch the `code-reviewer` and `architect` agents in parallel. Both lanes run in parallel on a clean context with explicit scope and artifacts. If either lane cannot be launched or does not return evidence, report `independent review unavailable`; do **not** substitute the current/authoring lane, and do **not** approve or mark the review merge-ready.\n3. Respect the user's current model and reasoning/effort selection. Do not pass `model` or `reasoning_effort` overrides in review-lane calls.\n\n```text\ntask(\n agent_type=\"code-reviewer\",\n prompt=\"CODE REVIEW TASK\n\nReview the supplied scope for spec compliance, security, quality, performance, and maintainability.\nReturn files reviewed, severity-rated findings with file:line evidence and concrete fixes,\nand a recommendation: APPROVE / REQUEST CHANGES / COMMENT. Do not review architecture.\nScope: [scope and artifacts]\"\n)\n\ntask(\n agent_type=\"architect\",\n prompt=\"ARCHITECTURE / DEVIL'S-ADVOCATE REVIEW TASK\n\nReview the same scope for boundaries, interfaces, hidden coupling, long-term tradeoffs,\nand the strongest counterargument against approval. Return file:line evidence,\nrecommendations, and Architectural Status: CLEAR / WATCH / BLOCK.\nScope: [scope and artifacts]\"\n)\n```\n\n## Review taxonomy\n\n- `code-reviewer` checks **Security**, **Code Quality**, **Performance**, **Best Practices**, and **Maintainability**.\n- Rate each finding: **CRITICAL** (security or data-loss blocker), **HIGH** (bug/major smell), **MEDIUM** (important improvement), or **LOW** (style/suggestion).\n- `architect` checks explicit boundaries/interfaces, hidden coupling, long-horizon tradeoffs, and devil's-advocate concerns. Status is **CLEAR**, **WATCH** (non-blocking concern), or **BLOCK** (merge blocker).\n- Every finding names `file:line`, issue, risk, and a concrete fix; distinguish facts from suggestions.\n\n## State/HUD Phase Contract\n\n- Standalone `$code-review` relies on hook-owned `skill-active-state.json` (`skill:\"code-review\"`, `phase:\"planning\"`); do not create `code-review-state.json`.\n- Inside Autopilot, keep `mode:\"autopilot\"` active with `current_phase:\"code-review\"` / skill-active `phase:\"code-review\"`; do not activate a peer workflow.\n- On clean review, persist the artifact under Autopilot `handoff_artifacts.code_review` before moving to `ultraqa`. On non-clean review, persist findings and use `rework` or `ralplan` as appropriate.\n\n```sh\nomx state write --input '{\"mode\":\"autopilot\",\"active\":true,\"current_phase\":\"code-review\"}' --json\n```\n\n## Final Synthesis and gate\n\n### Architectural Status Contract\n\nCombine the `code-reviewer` recommendation and architect status. Approval requires explicit evidence from both independent lanes; missing or failed delegation is a blocking unavailable-review state, not an approval fallback. The final report must make architect blockers impossible to miss.\n\n- If architect status is **BLOCK**, final recommendation is **REQUEST CHANGES**.\n- Else if `code-reviewer` recommendation is **REQUEST CHANGES**, final recommendation is **REQUEST CHANGES**.\n- Else if architect status is **WATCH**, final recommendation is **COMMENT**.\n- Else final recommendation follows the `code-reviewer` lane.\n\nApproval criteria: **APPROVE** only when `code-reviewer` returns APPROVE, architect status is `CLEAR`, and both independent lanes returned evidence. **REQUEST CHANGES** for a blocker, unresolved high/critical finding, or unavailable lane. **COMMENT** may record non-blocking findings.\n\nDo not self-review as a fallback. If the `code-reviewer` or `architect` path is missing, unavailable, skipped, or fails, block approval until independent lane evidence exists. On the supported `omx ralph` CLI compatibility path, findings may trigger automatic fix follow-up without another permission prompt; plain `code-review` itself remains read-only and does **not** promise auto-fix.\n\n## Evidence/output contract\n\nReturn a concise report containing:\n\n```text\nCODE REVIEW REPORT\nFiles Reviewed: \nTotal Issues: 0\nArchitectural Status: CLEAR | WATCH | BLOCK\nCRITICAL (0) | HIGH (0) | MEDIUM (0) | LOW (0)\nFindings: file:line -> issue, risk, concrete fix (or none)\nARCHITECTURE WATCHLIST: concern, status, recommendation (or none)\n- code-reviewer recommendation: COMMENT\n- architect status: WATCH\n- final recommendation: COMMENT\nRECOMMENDATION: COMMENT\n```\n\nReplace the illustrative counts and verdict with observed values. Include scope,\nlane evidence/artifact references, unresolved risks, and validation gaps.\n\n## Exit condition\n\nStop when the scoped diff has two independent lane results and a deterministic final\nrecommendation. Report `APPROVE` only under the approval criteria; otherwise leave a\nbounded `REQUEST CHANGES`, `COMMENT`, or unavailable-review result. Never claim\nmerge-ready without the required evidence.\n","plugins/oh-my-codex/skills/configure-notifications/SKILL.md":"---\nname: configure-notifications\ndescription: Configure OMX notifications - unified entry point for all platforms\ntriggers:\n - \"configure notifications\"\n - \"setup notifications\"\n - \"notification settings\"\n - \"configure discord\"\n - \"configure telegram\"\n - \"configure slack\"\n - \"configure openclaw\"\n - \"setup discord\"\n - \"setup telegram\"\n - \"setup slack\"\n - \"setup openclaw\"\n - \"discord notifications\"\n - \"telegram notifications\"\n - \"slack notifications\"\n - \"openclaw notifications\"\n - \"discord webhook\"\n - \"telegram bot\"\n - \"slack webhook\"\n---\n\n# Configure OMX Notifications\n\nUse this card for Discord, Telegram, Slack, generic command aliases, or OpenClaw. Shared safety, lifecycle, hook, team, autonomy, and cancellation rules live in `templates/AGENTS.md`.\n\n## 1. Inspect and choose a path\n\n```bash\nCONFIG_FILE=\"$HOME/.codex/.omx-config.json\"\nif [ -f \"$CONFIG_FILE\" ]; then\n jq -r '{notifications_enabled:(.notifications.enabled // false), discord:(.notifications.discord.enabled // false), discord_bot:(.notifications[\"discord-bot\"].enabled // false), telegram:(.notifications.telegram.enabled // false), slack:(.notifications.slack.enabled // false), openclaw:(.notifications.openclaw.enabled // false), custom_webhook_command:(.notifications.custom_webhook_command.enabled // false), custom_cli_command:(.notifications.custom_cli_command.enabled // false), verbosity:(.notifications.verbosity // \"session\"), idleCooldownSeconds:(.notifications.idleCooldownSeconds // 60), reply_enabled:(.notifications.reply.enabled // false)}' \"$CONFIG_FILE\"\nelse\n echo \"NO_CONFIG_FILE\"\nfi\n```\n\nUse AskUserQuestion to choose: Discord native (webhook or bot), Telegram native (bot token + chat id), Slack native (incoming webhook), `custom_webhook_command`, `custom_cli_command`, cross-cutting settings, or disable all notifications.\n\n## 2. Native providers\n\nCollect and validate provider values, then write only these native keys: `notifications.discord`, `notifications[\"discord-bot\"]`, `notifications.telegram`, or `notifications.slack`. Do not represent native providers with generic aliases.\n\n## 3. Generic aliases\n\nFor `custom_webhook_command`, collect URL, optional headers, method (`POST` default or `PUT`), events (`session-end`, `ask-user-question`, `session-start`, `session-idle`, `stop`), and an instruction template:\n\n```bash\njq --arg url \"$URL\" --arg method \"${METHOD:-POST}\" --arg instruction \"${INSTRUCTION:-OMX event {{event}} for {{projectPath}}}\" --argjson headers \"${HEADERS_JSON:-{}}\" '.notifications=(.notifications//{enabled:true})|.notifications.enabled=true|.notifications.custom_webhook_command={enabled:true,url:$url,headers:$headers,method:$method,instruction:$instruction,events:[\"session-end\",\"ask-user-question\"]}' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\nFor `custom_cli_command`, collect a command template (`{{event}}`, `{{instruction}}`, `{{sessionId}}`, `{{projectPath}}`), optional events, and an instruction template:\n\n```bash\njq --arg command \"$COMMAND_TEMPLATE\" --arg instruction \"${INSTRUCTION:-OMX event {{event}} for {{projectPath}}}\" '.notifications=(.notifications//{enabled:true})|.notifications.enabled=true|.notifications.custom_cli_command={enabled:true,command:$command,instruction:$instruction,events:[\"session-end\",\"ask-user-question\"]}' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\nOpenClaw dispatch requires `OMX_OPENCLAW=1`; command gateways additionally require `OMX_OPENCLAW_COMMAND=1`; timeout precedence is `gateways..timeout` > `OMX_OPENCLAW_COMMAND_TIMEOUT_MS` > `5000` ms.\n\n## 4. OpenClaw + Clawdbot agent mode\n\nUse this only when the requested route is a `clawdbot agent` turn delivered to Discord. The `session-stop` notification intentionally maps to the OpenClaw `stop` hook. OMX shell-escapes substitutions; keep instructions short, avoid untrusted shell metacharacters, append `|| true`, and append JSONL logs with `>>`.\n\n```bash\njq --arg command \"(clawdbot agent --session-id omx-hooks --message {{instruction}} --thinking minimal --deliver --reply-channel discord --reply-to 'channel:CHANNEL_ID' --timeout 120 --json >>/tmp/omx-openclaw-agent.jsonl 2>&1 || true)\" '.notifications=(.notifications//{enabled:true})|.notifications.enabled=true|.notifications.verbosity=\"verbose\"|.notifications.openclaw={enabled:true,gateways:{local:{type:\"command\",command:$command,timeout:120000}},hooks:{\"session-start\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-start project={{projectName}} session={{sessionId}} tmux={{tmuxSession}}. 한국어로 상태를 #omc-dev에 공유하고 SOUL.md를 참고하세요.\"},\"session-idle\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-idle session={{sessionId}} tmux={{tmuxSession}}. 한국어로 팔로업을 #omc-dev에 안내하세요.\"},\"ask-user-question\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=ask-user-question session={{sessionId}} tmux={{tmuxSession}} question={{question}}. 한국어로 응답 필요를 #omc-dev에 알리세요.\"},\"stop\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-stop session={{sessionId}} tmux={{tmuxSession}}. 한국어로 중단 상태를 전달하세요.\"},\"session-end\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-end session={{sessionId}} tmux={{tmuxSession}} reason={{reason}}. 한국어로 완료 요약을 #omc-dev에 남기세요.\"}}}' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\n### Compatibility + precedence contract\n\nExplicit `notifications.openclaw` wins when valid; generic aliases are ignored with a warning.\n\nVerify this mode and inspect evidence without hiding output:\n\n```bash\nclawdbot agent --session-id omx-hooks --message \"OMX hook test via clawdbot agent path\" --thinking minimal --deliver --reply-channel discord --reply-to 'channel:CHANNEL_ID' --timeout 120 --json\ntmux list-sessions -F '#{session_name}' | rg '^omx-' || true\njq '.notifications.openclaw.hooks' \"$CONFIG_FILE\"\ntail -n 120 /tmp/omx-openclaw-agent.jsonl | jq -s '.[] | {timestamp:(.timestamp // .time),status:(.status // .error // \"ok\")}'\nrg '\"error\"|\"failed\"|\"timeout\"' /tmp/omx-openclaw-agent.jsonl | tail -20\n```\n\nFor HTTP integrations, run both a `/hooks/wake` smoke test and `/hooks/agent` delivery verification.\n\n## 5. Cross-cutting settings and disable\n\n- Verbosity: `minimal`, `session` (recommended), `agent`, or `verbose`.\n- Idle cooldown: `notifications.idleCooldownSeconds` (environment override: `OMX_IDLE_COOLDOWN_SECONDS`).\n- Profiles: `notifications.profiles` and `notifications.defaultProfile`.\n- Reply listener: `notifications.reply.enabled`; gates are `OMX_REPLY_ENABLED=true` and, for Discord, `OMX_REPLY_DISCORD_USER_IDS=...`. An authorized Discord bot operator may exact-match `status` on a tracked notification for a bounded read-only session summary.\n\nDisable all notifications:\n\n```bash\njq '.notifications.enabled=false' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\n## Exit evidence\n\nRun `jq empty \"$CONFIG_FILE\"` after edits. Report the config path, enabled native providers, enabled aliases, whether valid `notifications.openclaw` overrides aliases, verbosity, idle cooldown, reply-listener state, and smoke-test results. Stop when the JSON parses and the selected path has its required evidence; do not claim delivery from configuration alone.\n","plugins/oh-my-codex/skills/deep-interview/SKILL.md":"---\nname: deep-interview\ndescription: Socratic deep interview with mathematical ambiguity gating before execution\nargument-hint: \"[--quick|--standard|--deep] [--autoresearch] \"\n---\n\n\nDeep Interview is an intent-first Socratic clarification loop before planning or implementation. It turns vague ideas into execution-ready specifications by asking targeted questions about why the user wants a change, how far it should go, what should stay out of scope, and what OMX may decide without confirmation.\n\n\n\n- The request is broad, ambiguous, or missing concrete acceptance criteria\n- The user says \"deep interview\", \"interview me\", \"ask me everything\", \"don't assume\", or \"ouroboros\"\n- The user wants to avoid misaligned implementation from underspecified requirements\n- You need a requirements artifact before handing off to `ralplan`, `autopilot`, `ultragoal`, or `team`\n\n\n\n- The request already has concrete file/symbol targets and clear acceptance criteria\n- The user explicitly asks to skip planning/interview and execute immediately\n- The user asks for lightweight brainstorming only (use `plan` instead)\n- A complete PRD/plan already exists and execution should start\n\n\n\nExecution quality is usually bottlenecked by intent clarity, not just missing implementation detail. A single expansion pass often misses why the user wants a change, where the scope should stop, which tradeoffs are unacceptable, and which decisions still require user approval. This workflow applies Socratic pressure + quantitative ambiguity scoring so orchestration modes begin with an explicit, testable, intent-aligned spec.\n\n\n\n- **Quick (`--quick`)**: fast pre-PRD pass; target threshold `<= 0.30`; max rounds 5\n- **Standard (`--standard`, default)**: full requirement interview; target threshold `<= 0.20`; max rounds 12\n- **Deep (`--deep`)**: high-rigor exploration; target threshold `<= 0.15`; max rounds 20\n- **Autoresearch (`--autoresearch`)**: same interview rigor as Standard, but specialized for `$autoresearch` mission readiness and `.omx/specs/` artifact handoff\n\nProfile `max rounds` is a hard cap, not a target. Do not continue only to reach a numbered round count. Extra Socratic rigor does not override the active threshold unless the profile/config changes.\n\nIf no flag is provided, use **Standard**.\n\n\n- **`--autoresearch`**: switch the interview into autoresearch-intake mode for `$autoresearch` handoff. In this mode, the interview should converge on a validator-ready research mission, write canonical artifacts under `.omx/specs/`, and preserve the explicit `refine further` vs `launch` boundary for downstream skill intake.\n\n\n\n\n- Ask ONE question per round (never batch multiple interview rounds into one `questions[]` form)\n- Ask about intent and boundaries before implementation detail\n- Target the weakest clarity dimension each round after applying the stage-priority rules below\n- Treat every answer as a claim to pressure-test before moving on: the next question should usually demand evidence or examples, expose a hidden assumption, force a tradeoff or boundary, or reframe root cause vs symptom\n- Do not rotate to a new clarity dimension just for coverage when the current answer is still vague; stay on the same thread until one layer deeper, one assumption clearer, or one boundary tighter\n- Before crystallizing, complete at least one explicit pressure pass that revisits an earlier answer with a deeper, assumption-focused, or tradeoff-focused follow-up\n- Gather codebase facts via `explore` before asking user about internals\n- `omx explore` is deprecated. Use normal repository inspection tools/subagents for simple read-only brownfield fact gathering; use `omx sparkshell` only for explicit shell-native read-only evidence, and keep ambiguous or non-shell-only investigation on the richer normal path.\n- Always run a preflight context intake before the first interview question\n- For brownfield work, preflight must include doc/context grounding before user-facing questions: inspect applicable `AGENTS.md` files, README/getting-started docs, relevant `docs/` contracts/plans/ADRs, existing `.omx/context/` snapshots, and any project-local glossary/context files such as `CONTEXT.md` or `CONTEXT-MAP.md` when present.\n- Treat existing repo language as evidence, not authority: if the user uses a fuzzy, overloaded, or conflicting term, surface the specific doc/code wording and ask which meaning should govern before implementation.\n- Cross-check user claims about current behavior against code or documented contracts when discoverable. If docs and code disagree, ask a confirmation question that names both sources instead of silently choosing one.\n- Use scenario-based edge-case grilling when relationships, boundaries, or handoff behavior are unclear: invent one concrete scenario that stresses the ambiguous boundary, then ask one focused question about the expected outcome.\n- Durable docs, glossary, ADR, or memory updates are opt-in and public-safe only. Deep-interview may recommend such updates in the handoff summary, but must not automatically create or dump public docs from interview transcripts unless the user explicitly chooses that as in-scope.\n- If initial context is oversized or would exceed the prompt budget, do not paste or forward the raw payload into interview prompts; request and record a prompt-safe initial-context summary first\n- The oversized initial-context summary gate is blocking: wait for the concise summary before ambiguity scoring, crystallizing artifacts, or any downstream execution handoff\n- The summary must preserve goals, constraints, success criteria, non-goals, decision boundaries, and references to any full source documents so downstream consumers receive a prompt-safe but faithful context\n- Keep total prompt payloads within a safe budget by summarizing or trimming retained history; preserve newest/highest-signal answers and never let raw oversized context crowd out the current question\n- Reduce user effort: ask only the highest-leverage unresolved question, and never ask the user for codebase facts that can be discovered directly\n- For brownfield work, prefer evidence-backed confirmation questions such as \"I found X in Y. Should this change follow that pattern?\"\n- Route facts before judgment in the Ouroboros style: before presenting a user-facing interview round, classify whether the needed information is a discoverable fact, a fact needing confirmation, or a human decision. The interview is with the human for judgment, not for facts the agent can inspect.\n- When unresolved ambiguity depends on current external best practices, official/upstream guidance, standards, or version-aware behavior, use `$best-practice-research` as the bounded evidence wrapper before crystallizing requirements or handing off to planning/execution.\n- Use these transcript/spec labels only; never use them as `omx question` `source` values, and never replace the runtime `source: \"deep-interview\"` contract for user-facing deep-interview questions:\n - `[from-code][auto-confirmed]` — exact, high-confidence codebase facts from manifests/configs or direct source evidence, with no prescription attached.\n - `[from-code]` — codebase findings that are useful but inferred, pattern-based, or low/medium confidence and therefore need a confirmation-style user-facing round before being treated as settled.\n - `[from-research]` — externally sourced facts such as API limits, compatibility, or public documentation; facts only, not decisions.\n - `[from-user]` — goals, preferences, business logic, scope, non-goals, acceptance criteria, tradeoffs, and any decision-bearing interpretation.\n- Treat `[from-code][auto-confirmed]` and other non-user fact discoveries as context/transcript updates, not interview rounds: do not call `omx question`, do not create a pending deep-interview question obligation, and do not increment the user-facing round number for facts the agent can safely establish.\n- Auto-confirm only descriptive facts. If a finding implies what the new feature should do, which pattern it should follow, which tradeoff to accept, or what should stay in/out of scope, route the entire decision-bearing question to the user as `[from-user]` even when code or research facts are available.\n- In attached-tmux Codex CLI, deep-interview uses `omx question` as the required OMX-owned structured questioning path for every interview round\n- When invoking `omx question` through attached-tmux Bash/tool paths, preserve the leader-pane return target by prefixing the command with `OMX_QUESTION_RETURN_PANE=$TMUX_PANE` (or a concrete `%pane` value)\n- If you launch `omx question` in a background terminal, immediately wait for that background terminal to finish and read its JSON answer before scoring ambiguity, asking another round, or handing off\n- Treat `answers[]` as the primary `omx question` success contract. For a single interview round, read `answers[0].answer`; use legacy top-level `answer` only as a compatibility fallback when needed.\n- If the current runtime is outside tmux and cannot render `omx question`, use the native structured question tool when available; otherwise ask exactly one concise plain-text question and wait for the answer\n- Re-score ambiguity after each answer and show progress transparently\n- Once ambiguity is at or below the active profile threshold, stop ordinary questioning. Run the practical closure audit: crystallize/handoff when readiness gates pass; otherwise ask only the final closure question needed to satisfy a named gate.\n- Treat `max_rounds` as a stop cap, not evidence that more rounds are needed.\n- Do not hand off to execution while ambiguity remains above threshold unless user explicitly opts to proceed with warning\n- Do not crystallize or hand off while `Non-goals` or `Decision Boundaries` remain unresolved, even if the weighted ambiguity threshold is met\n- Treat early exit as a safety valve, not the default success path\n- Persist mode state for resume safety only through the CLI/programmatic single-writer authority (`omx state write/read --input '' --json`, backed by `src/state/operations.ts`). The MCP state server is a read-only projection and must never become a second writer.\n\n\n\n\n## Phase 0: Preflight Context Intake\n\n1. Parse `{{ARGUMENTS}}` and derive a short task slug.\n2. Attempt to load the latest relevant context snapshot from `.omx/context/{slug}-*.md`.\n3. Check whether the provided initial context or loaded snapshot is too large for safe prompt use. If it is oversized, the first interview round must ask for a concise prompt-safe summary instead of scoring ambiguity or continuing to downstream handoff.\n4. If no snapshot exists, create a minimum context snapshot with:\n - Task statement\n - Desired outcome\n - Stated solution (what the user asked for)\n - Probable intent hypothesis (why they likely want it)\n - Known facts/evidence\n - Constraints\n - Unknowns/open questions\n - Decision-boundary unknowns\n - Likely codebase touchpoints\n - Relevant repo docs/rules/context inspected\n - Terminology or doc/code conflicts found\n - Prompt-safe initial-context summary status (`not_needed`, `needed`, or `recorded`)\n5. For brownfield tasks, inspect the applicable documentation/rule surface before the first user-facing round. Prefer exact, nearby sources over broad scans:\n - governing `AGENTS.md` files and template/runtime instruction surfaces that apply to the touched paths\n - README/getting-started docs and relevant docs under `docs/`, especially contracts, plans, ADR-like records, and workflow docs\n - existing `.omx/context/` snapshots, `.omx/specs/`, and planning artifacts relevant to the slug\n - project-local glossary/context files such as `CONTEXT.md`, `CONTEXT-MAP.md`, or context-specific docs when they exist\n6. Save snapshot to `.omx/context/{slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`) and reference it in mode state.\n\n## Phase 1: Initialize\n\n1. Parse `{{ARGUMENTS}}` and depth profile (`--quick|--standard|--deep`).\n2. Detect project context:\n - Run `explore` to classify **brownfield** (existing codebase target) vs **greenfield**.\n - For brownfield, collect relevant codebase context before questioning.\n3. Initialize state via `omx state write --input '{\"mode\":\"deep-interview\",\"active\":true}' --json`:\n\n```json\n{\n \"active\": true,\n \"current_phase\": \"deep-interview\",\n \"state\": {\n \"interview_id\": \"\",\n \"profile\": \"quick|standard|deep\",\n \"type\": \"greenfield|brownfield\",\n \"initial_idea\": \"\",\n \"rounds\": [],\n \"current_ambiguity\": 1.0,\n \"threshold\": 0.3,\n \"max_rounds\": 5,\n \"challenge_modes_used\": [],\n \"codebase_context\": null,\n \"current_stage\": \"intent-first\",\n \"current_focus\": \"intent\",\n \"context_snapshot_path\": \".omx/context/-.md\"\n }\n}\n```\n\n4. Announce kickoff with profile, threshold, and current ambiguity.\n\n## Phase 2: Socratic Interview Loop\n\nRepeat until ambiguity `<= threshold`, the pressure pass is complete, the readiness gates are explicit, the user exits with warning, or max rounds are reached. This is a stop condition: below threshold, do not open a new ordinary interview branch.\n\n### 2a) Generate next question\nIf the initial context is oversized and no prompt-safe summary has been recorded yet, the next question must be only a summary request. Do not score ambiguity, do not run readiness gates, and do not hand off to `$ultragoal`, `$ralplan`, `$autopilot`, or `$team` until that summary answer is captured.\n\nUse:\n- Original idea\n- Prior Q&A rounds\n- Current dimension scores\n- Brownfield context (if any)\n- Doc/context grounding notes, including existing terminology, governing rules, and any doc/code mismatch\n- Activated challenge mode injection (Phase 3)\n\nTarget the lowest-scoring dimension, but respect stage priority:\n- **Stage 1 — Intent-first:** Intent, Outcome, Scope, Non-goals, Decision Boundaries\n- **Stage 2 — Feasibility:** Constraints, Success Criteria\n- **Stage 3 — Brownfield grounding:** Context Clarity (brownfield only)\n\nFollow-up pressure ladder after each answer:\n1. Ask for a concrete example, counterexample, or evidence signal behind the latest claim\n2. Probe the hidden assumption, dependency, or belief that makes the claim true\n3. Force a boundary or tradeoff: what would you explicitly not do, defer, or reject?\n4. Challenge fuzzy or conflicting terms against the repo's documented language and current code behavior\n5. Stress-test the boundary with one concrete scenario or edge case when a relationship or handoff remains ambiguous\n6. If the answer still describes symptoms, reframe toward essence / root cause before moving on\n\nPrefer staying on the same thread for multiple rounds when it has the highest leverage. Breadth without pressure is not progress.\n\nMaintain a **Breadth Ledger** across independent ambiguity tracks: scope, constraints, outputs, verification, brownfield integration, and any user-mentioned deliverable tracks. The ledger is a guard, not a mandatory rotation rule: stay deep on the current thread until it has been pressure-tested, then zoom out only when another material track remains unresolved and would change execution.\n\nMaintain a **Docs/Terminology Ledger** for brownfield interviews:\n- repo docs/rules/context sources inspected, with path references\n- canonical terms already used by the repo and terms to avoid or disambiguate\n- user terms that conflict with docs or current code behavior\n- doc/code mismatches that require a human decision before implementation\n- optional durable-doc follow-ups that are safe to propose but not auto-apply\n\nDetailed dimensions:\n- Intent Clarity — why the user wants this\n- Outcome Clarity — what end state they want\n- Scope Clarity — how far the change should go\n- Constraint Clarity — technical or business limits that must hold\n- Success Criteria Clarity — how completion will be judged\n- Context Clarity — existing codebase understanding (brownfield only)\n\n`Non-goals` and `Decision Boundaries` are mandatory readiness gates. Ask about them early and keep revisiting them until they are explicit.\n\n### 2b) Ask the question\nUse the surface-appropriate structured questioning path for every interview round. In attached-tmux sessions, use OMX-owned structured questioning via `omx question` (this is the required structured-question equivalent and required `AskUserQuestion` equivalent for deep-interview). Outside tmux, use native structured input when available; otherwise ask exactly one concise plain-text question and wait for the answer. Present:\n\n```\nRound {n} | Target: {weakest_dimension} | Ambiguity: {score}%\n\n{question}\n```\n\n`omx question` payload guidance for interview rounds:\n- Deep-interview is Socratic: ask one focused round at a time. Do not use batch `questions[]` to combine multiple interview rounds, even though `omx question` supports batch forms for other workflows.\n- Use canonical `type` values instead of authoring raw `multi_select` flags by hand. `type: \"single-answerable\"` is the default for one-path decisions; `type: \"multi-answerable\"` is the canonical shape for bounded multi-select rounds. The runtime will keep `multi_select` aligned with `type`.\n- Use `single-answerable` when exactly one answer should drive the next branch, the options are mutually exclusive, or selecting more than one answer would blur the decision boundary. Typical cases: handoff lane selection, choosing the primary failure mode, or confirming which of several competing interpretations is correct.\n- Use `multi-answerable` when multiple options may all be true at once and you need to capture a bounded set of coexisting constraints, non-goals, risks, or acceptance checks in one round. Typical cases: selecting all out-of-scope items, all success metrics that must hold, or all deployment constraints that apply together.\n- If one selected option would immediately require a follow-up question to disambiguate the others, prefer a `single-answerable` round now and ask the follow-up next. Do not hide a branching interview tree inside one overloaded multi-select prompt.\n- Keep interview options bounded and concrete. If the valid answers are already known, set `allow_other: false`; only leave `allow_other: true` when the interview genuinely needs one user-supplied option that cannot be enumerated in advance.\n- Read answers structurally from the primary `answers[]` array. For a normal single-round interview response, use `answers[0].answer` as the source of truth; the top-level `answer` field is a legacy single-question projection/fallback only.\n- For `single-answerable`, expect one decisive selection in the `value` field of `answers[0].answer` plus its selected-values metadata. For `multi-answerable`, treat the selected-values field inside `answers[0].answer` as the source of truth for all chosen constraints/non-goals and preserve the full set in the transcript/spec. In legacy single-question projections, this is equivalent to: For `multi-answerable`, treat `answer.selected_values` as the source of truth.\n\nCanonical bounded single-choice payload:\n\n```json\n{\n \"question\": \"Which execution lane should own this once the interview is complete?\",\n \"type\": \"single-answerable\",\n \"options\": [\n {\n \"label\": \"Plan first\",\n \"value\": \"ralplan\",\n \"description\": \"Need architecture and test-shape review before execution\"\n },\n {\n \"label\": \"Execute directly\",\n \"value\": \"autopilot\",\n \"description\": \"Requirements are already explicit enough for planning plus execution\"\n },\n {\n \"label\": \"Refine further\",\n \"value\": \"refine\",\n \"description\": \"Clarification is still needed before any handoff\"\n }\n ],\n \"allow_other\": false,\n \"other_label\": \"Other\",\n \"source\": \"deep-interview\"\n}\n```\n\nCanonical bounded multi-select payload:\n\n```json\n{\n \"question\": \"Which non-goals must stay out of scope for the first pass?\",\n \"type\": \"multi-answerable\",\n \"options\": [\n {\n \"label\": \"No UI redesign\",\n \"value\": \"no-ui-redesign\",\n \"description\": \"Keep layout and styling unchanged\"\n },\n {\n \"label\": \"No new dependencies\",\n \"value\": \"no-new-dependencies\",\n \"description\": \"Work within the existing toolchain\"\n },\n {\n \"label\": \"No API contract changes\",\n \"value\": \"no-api-contract-changes\",\n \"description\": \"Preserve external request and response shapes\"\n }\n ],\n \"allow_other\": false,\n \"other_label\": \"Other\",\n \"source\": \"deep-interview\"\n}\n```\n\nCanonical answer-shape reminders:\n\n```json\n{\n \"answer\": {\n \"kind\": \"option\",\n \"value\": \"ralplan\",\n \"selected_labels\": [\"Plan first\"],\n \"selected_values\": [\"ralplan\"]\n }\n}\n```\n\n```json\n{\n \"answer\": {\n \"kind\": \"multi\",\n \"value\": [\"no-new-dependencies\", \"no-api-contract-changes\"],\n \"selected_labels\": [\"No new dependencies\", \"No API contract changes\"],\n \"selected_values\": [\"no-new-dependencies\", \"no-api-contract-changes\"]\n }\n}\n```\n\n### 2c) Score ambiguity\nScore each weighted dimension in `[0.0, 1.0]` with justification + gap.\n\nGreenfield: `ambiguity = 1 - (intent × 0.30 + outcome × 0.25 + scope × 0.20 + constraints × 0.15 + success × 0.10)`\n\nBrownfield: `ambiguity = 1 - (intent × 0.25 + outcome × 0.20 + scope × 0.20 + constraints × 0.15 + success × 0.10 + context × 0.10)`\n\nReadiness gate:\n- `Non-goals` must be explicit\n- `Decision Boundaries` must be explicit\n- A pressure pass must be complete: at least one earlier answer has been revisited with an evidence, assumption, or tradeoff follow-up\n- A practical closure audit must pass: another question would change execution materially, not merely polish wording or chase a narrow edge case\n- If either gate is unresolved, or the pressure pass is incomplete, continue below threshold only with a final closure question that names the unresolved gate and would materially change execution.\n- Treat a low ambiguity score as permission to audit closure, not permission to keep drilling indefinitely. If remaining uncertainty would not change implementation, crystallize the spec instead of opening a new branch.\n- If ambiguity is `<= 0.10`, another user-facing question is allowed only as that final closure question; otherwise crystallize immediately.\n\n### 2d) Report progress\nShow weighted breakdown table, readiness-gate status (`Non-goals`, `Decision Boundaries`), and the next focus dimension.\n\n### 2e) Persist state\nAppend round result and updated scores via `omx state write --input '' --json`. Do not write `{mode}-state.json` directly and do not use the read-only MCP state projection as a writer.\n\n### 2f) Round controls\n- Do not offer early exit before the first explicit assumption probe and one persistent follow-up have happened\n- Apply a **Dialectic Rhythm Guard**: track consecutive non-user fact discoveries and confirmation-style answers (`[from-code][auto-confirmed]`, `[from-code]`, or `[from-research]`). After 3 consecutive non-user or confirmation answers, the next material user-facing round must solicit direct human judgment (`[from-user]`) unless the closure audit says the interview is ready to crystallize.\n- Round 4+: allow explicit early exit with risk warning\n- Soft warning at profile midpoint (e.g., round 3/6/10 depending on profile)\n- Hard cap at profile `max_rounds`; never treat this cap as a desired interview length or quota\n\n## Phase 3: Challenge Modes (assumption stress tests)\n\nUse each mode once when applicable. These are normal escalation tools, not rare rescue moves:\n\n- **Contrarian** (round 2+ or immediately when an answer rests on an untested assumption): challenge core assumptions\n- **Terminologist** (brownfield, whenever a key term is fuzzy, overloaded, or conflicts with repo docs/code): force a canonical meaning against existing project language before implementation\n- **Simplifier** (round 4+ or when scope expands faster than outcome clarity): probe minimal viable scope\n- **Ontologist** (round 5+ and ambiguity > 0.25, or when the user keeps describing symptoms): ask for essence-level reframing\n\nTrack used modes in state to prevent repetition.\n\n## Phase 4: Crystallize Artifacts\n\nWhen threshold is met (or user exits with warning / hard cap):\n\n1. Write interview transcript summary to:\n - `.omx/interviews/{slug}-{timestamp}.md`\n (kept for ralph PRD compatibility)\n2. Write execution-ready spec to:\n - `.omx/specs/deep-interview-{slug}.md`\n\nSpec should include:\n- Metadata (profile, rounds, final ambiguity, threshold, context type)\n- Context snapshot reference/path (for ralplan/team reuse)\n- Prompt-safe initial-context summary when oversized context was provided, plus references to any full source documents\n- Clarity breakdown table\n- Intent (why the user wants this)\n- Desired Outcome\n- In-Scope\n- Out-of-Scope / Non-goals\n- Decision Boundaries (what OMX may decide without confirmation)\n- Constraints\n- Testable acceptance criteria\n- Assumptions exposed + resolutions\n- Pressure-pass findings (which answer was revisited, and what changed)\n- Brownfield evidence vs inference notes for any repository-grounded confirmation questions\n- Docs/Terminology Ledger with inspected repo docs/rules/context, term conflicts, and any doc/code mismatch decisions\n- Scenario/edge-case pressure findings that materially shaped scope or acceptance criteria\n- Optional durable documentation recommendations, explicitly marked opt-in and public-safe; do not include raw private transcript dumps\n- Technical context findings\n- Full or condensed transcript\n\n### Autoresearch specialization\n\nWhen the clarified task is specifically about `$autoresearch`, or the skill is invoked with `--autoresearch`, keep the interview domain-specific and emit skill-consumable artifacts without skipping clarification.\n\n- **Accepted seed inputs:** `topic`, `evaluator`, `keep-policy`, `slug`, existing mission draft text, and prior evaluator examples/templates\n- **Required interview focus:** mission clarity, evaluator readiness, keep policy, slug/session naming, and whether the draft is ready to launch now or should refine further\n- **Canonical artifact path:** `.omx/specs/deep-interview-autoresearch-{slug}.md`\n- **Launch artifact bundle:** `.omx/specs/autoresearch-{slug}/mission.md`, `.omx/specs/autoresearch-{slug}/sandbox.md`, and `.omx/specs/autoresearch-{slug}/result.json`\n- **Launch artifact directory:** `.omx/specs/autoresearch-{slug}/`\n- **Required artifact sections:**\n - `Mission Draft`\n - `Evaluator Draft`\n - `Launch Readiness`\n - `Seed Inputs`\n - `Confirmation Bridge`\n- **Required launch artifacts under `.omx/specs/autoresearch-{slug}/`:**\n - `mission.md`\n - `sandbox.md`\n - `result.json`\n- **Launch-readiness rule:** mark the draft as **not launch-ready** while the evaluator command still contains placeholder markers such as `<...>`, `TODO`, `TBD`, `REPLACE_ME`, `CHANGEME`, or `your-command-here`\n- **Structured result contract:** `result.json` should point to the draft + mission/sandbox artifacts and carry the finalized `topic`, `evaluatorCommand`, `keepPolicy`, `slug`, `launchReady`, and `blockedReasons` fields so `$autoresearch` can consume it directly\n- **Confirmation bridge:** after artifact generation, offer at least `refine further` and `launch`; do not run direct CLI launch or detached/split tmux launch, and only hand off to `$autoresearch` after explicit confirmation\n- **Handoff rule:** downstream execution must preserve the clarified mission intent, evaluator expectations, decision boundaries, and launch-readiness status from this artifact rather than bypassing the draft review step\n\n## Phase 5: Execution Bridge\n\nPresent execution options after artifact generation using explicit handoff contracts. Treat the deep-interview spec as the current requirements source of truth and preserve intent, non-goals, decision boundaries, acceptance criteria, docs/terminology grounding, and any residual-risk warnings across the handoff.\n\n### Optional execution contract foundation\n\nWhen an Autopilot/deep-interview handoff explicitly requires a stride contract, emit it as structured data rather than prose. This is a validation foundation, not a broadness-inference feature: do not infer stride from task length, phase labels, snapshots, or freeform wording.\n\nCanonical location under Autopilot state:\n\n```json\n{\n \"handoff_artifacts\": {\n \"deep_interview\": {\n \"execution_contract_required\": true,\n \"execution_contract\": {\n \"version\": 1,\n \"execution_stride\": \"task\",\n \"source\": \"deep-interview\",\n \"selected_by\": \"user\",\n \"allow_task_shrink\": true,\n \"completion_unit\": \"One focused task\",\n \"stop_condition\": \"Stop after that task is implemented and verified\",\n \"acceptance_coverage_scope\": \"task\",\n \"shrink_policy\": \"allowed\"\n }\n }\n }\n}\n```\n\nStride meanings:\n- `task`: conservative, small-step execution; `allow_task_shrink:true`, `acceptance_coverage_scope:\"task\"`, `shrink_policy:\"allowed\"`.\n- `deliverable`: finish the named deliverable before stopping; `allow_task_shrink:false`, `acceptance_coverage_scope:\"deliverable\"`, `shrink_policy:\"ask_before_shrink\"`.\n- `milestone`: finish the larger approved milestone unless blocked; `allow_task_shrink:false`, `acceptance_coverage_scope:\"milestone\"`, `shrink_policy:\"deny_unless_blocked\"`.\n\nOnly set `execution_contract_required:true` when the selected downstream workflow needs this explicit stride/stop-condition guard. New artifacts must write the canonical snake_case schema shown above under `handoff_artifacts.deep_interview`; runtime readers may accept legacy camelCase field/marker aliases and direct/nested `execution_contract` locations only as compatibility input. If `execution_contract_required` is absent or false, downstream Autopilot compatibility behavior is unchanged.\n\n### Goal-mode follow-ups\n\nInclude these product-facing suggestions when they fit the clarified spec, without removing the existing `$ultragoal`, `$ralplan`, `$autopilot`, and `$team` handoff options:\n\n- **`$ultragoal`** — default goal-mode follow-up for implementation or general goal-oriented follow-up specs that should be converted into durable Codex/OMX goals with sequential completion tracking.\n- **`$autoresearch`** — use when the clarified context is a research project: a research question, reference/literature gathering, evaluator-backed analysis, or professor/critic-style deliverable.\n- **`$performance-goal`** — use when the clarified context is an optimization or performance project with measurable speed, latency, throughput, memory, benchmark, or evaluator criteria.\n\nRecommend `$ultragoal` as the default durable goal-mode follow-up because it supersedes Ralph for goal tracking. Preserve `$team` for coordinated parallel implementation.\n\n### 1. **`$ultragoal` (Default durable execution follow-up)**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md` (optionally accompanied by the transcript/context snapshot for traceability)\n- **Invocation:** `$ultragoal create-goals --brief-file ` followed by `$ultragoal complete-goals` in the active execution lane\n- **Consumer Behavior:** Convert the clarified spec into durable goal-mode work. Preserve intent, non-goals, decision boundaries, acceptance criteria, docs/terminology grounding, scenario-pressure findings, and residual-risk warnings as binding story constraints.\n- **Skipped / Already-Satisfied Stages:** Requirement interview, ambiguity clarification, doc/context preflight, and early intent-boundary elicitation\n- **Expected Output:** `.omx/ultragoal/brief.md`, `.omx/ultragoal/goals.json`, `.omx/ultragoal/ledger.jsonl`, implementation evidence, verification evidence, and final cleanup/review-gate evidence\n- **Best When:** The clarified spec is execution-ready or the user explicitly wants durable goal tracking as the next step\n- **Next Recommended Step:** Run the Ultragoal completion loop; launch `$team` only inside an active Ultragoal story when parallel lanes are warranted\n\n### 2. **`$ralplan` (Recommended when architecture/test-shape review is still needed)**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md` (optionally accompanied by the transcript/context snapshot for traceability)\n- **Invocation:** `$ralplan `\n- **Consumer Behavior:** Treat the deep-interview spec as the requirements source of truth. Do not repeat the interview by default; refine architecture/feasibility around the clarified intent and boundaries instead.\n- **Skipped / Already-Satisfied Stages:** Requirements discovery, ambiguity clarification, and early intent-boundary elicitation\n- **Expected Output:** Canonical planning artifacts under `.omx/plans/`, especially `prd-*.md` and `test-spec-*.md`\n- **Best When:** Requirements are clear enough to stop interviewing, but architectural validation / consensus planning is still desirable\n- **Next Recommended Step:** Use the approved planning artifacts with `$ultragoal` as the default durable goal-mode follow-up (optionally with `$team` for parallel lanes); choose `$autoresearch` for research validation or `$performance-goal` for measurable optimization\n\n### 3. **`$autopilot`**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md`\n- **Invocation:** `$autopilot `\n- **Consumer Behavior:** Use the deep-interview spec as the clarified execution brief. Preserve intent, non-goals, decision boundaries, and acceptance criteria as binding context for planning/execution.\n- **Skipped / Already-Satisfied Stages:** Initial requirement discovery and ambiguity reduction\n- **Expected Output:** Planning/execution progress, QA evidence, and validation artifacts produced by autopilot\n- **Best When:** The clarified spec is already strong enough for direct planning + execution without an additional consensus gate\n- **Next Recommended Step:** Continue through autopilot's execution/QA/validation flow; if coordination-heavy execution emerges, prefer `$team` under a leader-owned `$ultragoal` ledger\n\n### 4. **`$team`**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md`\n- **Invocation:** `$team `\n- **Consumer Behavior:** Treat the spec as shared execution context for coordinated parallel work. Preserve the clarified intent, non-goals, decision boundaries, and acceptance criteria as common lane constraints.\n- **Skipped / Already-Satisfied Stages:** Requirement clarification and early ambiguity reduction\n- **Expected Output:** Coordinated multi-agent execution against the shared spec, with final verification evidence and checkpoints in an already-active Ultragoal ledger when applicable\n- **Best When:** The task is large, multi-lane, or blocker-sensitive enough to justify coordinated parallel execution instead of a single persistent loop\n- **Next Recommended Step:** Follow the team verification path when the coordinated execution phase finishes; checkpoint an already-active `$ultragoal` ledger when applicable. Do not start another execution loop solely to verify.\n\n### 5. **Refine further**\n- **Input Artifact:** Existing transcript, context snapshot, and current spec draft\n- **Invocation:** Continue the interview loop\n- **Consumer Behavior:** Re-enter questioning to resolve the highest-leverage remaining uncertainty\n- **Skipped / Already-Satisfied Stages:** None beyond already-captured context\n- **Expected Output:** A lower-ambiguity spec with tighter boundaries and fewer unresolved assumptions\n- **Best When:** Residual ambiguity is still too high, the user wants stronger clarity, or the above-threshold / early-exit warning indicates too much risk to proceed cleanly\n- **Next Recommended Step:** Return to one of the execution handoff contracts above once the spec is sufficiently clarified\n\n**Residual-Risk Rule:** If the interview ended via early exit, hard-cap completion, or above-threshold proceed-with-warning, explicitly preserve that residual-risk state in the handoff so the downstream skill knows it inherited a partially clarified brief.\n\n**IMPORTANT:** Deep-interview is a requirements mode. On handoff, invoke the selected skill using the contract above. **Do NOT implement directly** inside deep-interview.\n\n\n\n\n- Use `explore` for codebase fact gathering\n- Use `omx question` as the OMX-native structured user-input tool for each interview round when an attached tmux renderer is available\n- From attached-tmux Bash/tool paths, call it as `OMX_QUESTION_RETURN_PANE=$TMUX_PANE omx question ...` unless an explicit `%pane` return target is already known\n- If the current runtime is outside tmux and cannot render `omx question`, use native structured input when available; otherwise ask exactly one concise plain-text question and wait for the answer\n- After `omx question` returns JSON, prefer `answers[0].answer` / `answers[]`; use legacy `answer` only as a fallback for older records\n- Use `omx state write/read --input '' --json` for resumable mode state through the sole-writer state operations path; the MCP state server is read-only and is not a fallback writer\n- If the interview cannot ask a required `omx question` round, persist the blocker as terminal state with `active: false` and `current_phase: \"blocked\"`; do not write a terminal blocked phase with `active: true`\n- Read/write context snapshots under `.omx/context/`\n- Read applicable repo docs/rules/context during preflight; write durable docs, glossary, ADR, or memory updates only when the user explicitly opts in and the content is public-safe\n- Record whether the oversized-context summary gate is not needed, pending, or satisfied before any scoring or handoff step\n- Save transcript/spec artifacts under `.omx/interviews/` and `.omx/specs/`\n\n\n\n- User says stop/cancel/abort -> persist state and stop\n- Ambiguity stalls for 3 rounds (+/- 0.05) -> force Ontologist mode once\n- Max rounds reached -> proceed with explicit residual-risk warning\n- All dimensions >= 0.9 -> allow early crystallization even before max rounds\n\n\n\n- [ ] Preflight context snapshot exists under `.omx/context/{slug}-{timestamp}.md`\n- [ ] Oversized initial context, if present, has a prompt-safe summary recorded before ambiguity scoring or downstream handoff\n- [ ] Ambiguity score shown each round\n- [ ] Intent-first stage priority used before implementation detail\n- [ ] Weakest-dimension targeting used within the active stage\n- [ ] At least one explicit assumption probe happened before crystallization\n- [ ] At least one persistent follow-up / pressure pass deepened a prior answer\n- [ ] Challenge modes triggered at thresholds (when applicable)\n- [ ] Transcript written to `.omx/interviews/{slug}-{timestamp}.md`\n- [ ] Spec written to `.omx/specs/deep-interview-{slug}.md`\n- [ ] Brownfield questions use evidence-backed confirmation when applicable\n- [ ] Brownfield preflight inspected applicable repo docs/rules/context before user-facing questions\n- [ ] Fuzzy or conflicting terminology was challenged against repo language/current code behavior when applicable\n- [ ] Scenario-based edge-case grilling was used when boundary ambiguity would materially affect implementation\n- [ ] Durable docs/ADR/memory updates, if any, were explicitly opted into and public-safe\n- [ ] Handoff options provided (`$ultragoal`, `$ralplan`, `$autopilot`, `$team`) plus context-sensitive goal-mode suggestions (`$autoresearch`, `$performance-goal`) when applicable\n- [ ] No direct implementation performed in this mode\n\n\n\n## Suggested Config (optional)\n\nDeep-interview reads runtime defaults from the first existing config source in this order:\n\n1. Repository-local `.omx/config.toml`\n2. Repository-root `omx.toml`\n3. User-global `~/.omx/config.toml`\n\nThis section is currently a deep-interview-specific runtime override surface, not a general replacement for Codex `config.toml` or `.omx-config.json` model/env routing.\nMalformed config files are ignored fail-soft so `$deep-interview` activation can continue with built-in defaults.\nExplicit `--quick`, `--standard`, or `--deep` invocation flags override `defaultProfile`.\n\n```toml\n[omx.deepInterview]\ndefaultProfile = \"standard\"\nquickThreshold = 0.30\nstandardThreshold = 0.20\ndeepThreshold = 0.15\nquickMaxRounds = 5\nstandardMaxRounds = 12\ndeepMaxRounds = 20\nenableChallengeModes = true\n```\n\n## Resume\n\nIf interrupted, rerun `$deep-interview`. Resume from persisted mode state via `omx state read --input '{\"mode\":\"deep-interview\"}' --json`.\n\n## Canonical Autopilot Entry Pipeline\n\n```\nautopilot -> deep-interview -> ralplan -> ultragoal\n```\n\n- Autopilot begins with this independent deep-interview clarity gate; it must not substitute `$plan --interview`.\n- Stage 1 (deep-interview): ambiguity clearance and execution-ready requirements artifact\n- Stage 2 (ralplan): feasibility, architecture, and consensus gate\n- Stage 3 (ultragoal): durable execution, verification, and completion receipts\n\n","plugins/oh-my-codex/skills/design/SKILL.md":"---\nname: design\ndescription: Canonical repo-local DESIGN.md workflow for product, UI/UX, and frontend decision source of truth\n---\n\n# Design Skill\n\nUse `$design` to discover product and UI evidence, close only design-critical context gaps, and create or refresh the repository’s durable `DESIGN.md` contract. It is a maintained design brief, not a pixel-matching loop or one-off critique.\n\nShared operating, delegation, state, hook, team, cancellation, and verification invariants live in [`templates/AGENTS.md`](../../templates/AGENTS.md). Follow that source instead of duplicating its rules here.\n\n## Use when\n\n- Product, UX, frontend, or design-system decisions need a repo-local source of truth.\n- A feature needs a design brief before a designer lane or implementation.\n- Existing UI, assets, screenshots, or constraints need an actionable design summary.\n\nDo not use it for visual-reference implementation matching (use `$visual-ralph`), screenshot comparison alone, or backend/infrastructure work without user-facing design impact.\n\n## Relationship to `$visual-ralph`\n\n`$design` owns product goals, users, information architecture, visual language, components, accessibility, constraints, and open questions in `DESIGN.md`. `$visual-ralph` owns implementation against an approved visual reference or live-URL baseline, measured verdicts, and pixel-diff evidence. Run `$design` first when both are needed; `DESIGN.md` supports but does not replace the visual verdict target.\n\n## Workflow\n\n### 1. Discover local evidence\n\nInspect and cite existing `DESIGN.md`, design/UX/frontend docs, README/specs/issues, routes/pages/layouts/components/stories, theme and token files, assets, screenshots/mockups, Storybook or Playwright baselines, and accessibility/responsive/i18n/platform constraints. Separate observations from inferences; note absent evidence.\n\n### 2. Interview only missing context\n\nAsk concise questions only for gaps the repository cannot resolve: users/jobs, goals/non-goals, brand personality and forbidden aesthetics, primary flows, accessibility/device/browser targets, or unavailable assets/references. If answers are unavailable, record explicit assumptions and open questions rather than blocking.\n\n### 3. Create or refresh `DESIGN.md`\n\nPreserve useful content, remove contradictions, mark unknowns, and keep decisions actionable. The root file must contain these sections:\n\n# Design\n## Source of truth\nStatus (Draft | Active | Needs refresh), date, product surfaces, evidence reviewed.\n## Brand\nPersonality, trust signals, avoid.\n## Product goals\nGoals, non-goals, success signals.\n## Personas and jobs\nPrimary personas, user jobs, contexts of use.\n## Information architecture\nNavigation, routes/screens, content hierarchy.\n## Design principles\nPrinciples and tradeoffs.\n## Visual language\nColor, typography, spacing, shape/elevation, motion, imagery/iconography.\n## Components\nExisting/new components, variants/states, token ownership.\n## Accessibility\nTarget standard, keyboard/focus, contrast, semantics, reduced motion/sensory concerns.\n## Responsive behavior\nBreakpoints/devices, layout adaptations, touch/hover differences.\n## Interaction states\nLoading, empty, error, success, disabled, offline/slow network where applicable.\n## Content voice\nTone, terminology, microcopy rules.\n## Implementation constraints\nFramework/styling, tokens, performance, compatibility, test/screenshot expectations.\n## Open questions\n`[ ]` question, owner, and impact.\n\n### 4. Apply the contract\n\nBefore UI decisions, cite relevant `DESIGN.md` sections, reuse documented components/tokens, and update the file or add an open question when implementation exposes a contradiction. Do not invent a parallel design-system layer.\n\n### 5. Handoff\n\nFor normal frontend work, provide the relevant sections, repo evidence, and acceptance criteria. For visual-reference, image, or live-URL matching, hand off to `$visual-ralph` with the approved baseline and identify `DESIGN.md` as supporting context only.\n\n## Evidence and completion\n\nComplete only when design docs/assets/components/screenshots were inspected or noted absent; missing context is answered, assumed, or listed; root `DESIGN.md` contains every required section; recommendations cite it; and any Visual Ralph handoff is clearly separated from design governance.\n\nTask: {{ARGUMENTS}}\n","plugins/oh-my-codex/skills/doctor/SKILL.md":"---\nname: doctor\ndescription: Diagnose and fix oh-my-codex installation issues\n---\n\n# OMX Doctor\n\nUse this task card to diagnose installation/discovery problems. Shared safety, lifecycle, hook, team, autonomy, and cancellation rules live in `templates/AGENTS.md`. `~/.codex` means `${CODEX_HOME:-~/.codex}` when `CODEX_HOME` is set.\n\n## Run diagnostics\n\n```bash\nomx doctor\nomx doctor --team # include Team runtime checks\nomx doctor --verbose # include detailed check evidence\nomx doctor --force # repair eligible repo artifact ownership issues\nomx doctor --dry-run --force # preview eligible ownership repairs\n```\n\nFor a local source checkout, build first and invoke `node dist/cli/omx.js doctor`. Keep command output and exact paths for the report.\n\n### Plugin cache and version\n\n```bash\nPLUGIN_CACHE_ROOT=\"${CODEX_HOME:-$HOME/.codex}/plugins/cache\"\nCACHE_ENTRIES=$(find \"$PLUGIN_CACHE_ROOT\" -path \"*/oh-my-codex/*\" -mindepth 3 -maxdepth 3 -type d 2>/dev/null)\nif [[ -z \"$CACHE_ENTRIES\" ]]; then\n echo \"Installed plugin cache: none\"\nelse\n while IFS= read -r d; do\n m=$(basename \"$(dirname \"$(dirname \"$d\")\")\"); v=$(basename \"$d\")\n printf 'Installed plugin cache: marketplace=%s version=%s path=%s\\n' \"$m\" \"$v\" \"$d\"\n done <<<\"$CACHE_ENTRIES\"\nfi\nLATEST=$(npm view oh-my-codex version 2>/dev/null)\necho \"Latest npm: $LATEST\"\n```\n\nNo cache is INFO (normal for npm/setup-only installs). A non-`local` cache version differing from `LATEST`, or multiple versions for one marketplace, is WARN. Plugin discovery does not replace npm installation plus `omx setup`; native/runtime wiring remains setup-owned.\n\n### Hooks, AGENTS, and skill roots\n\n```bash\nCODEX_DIR=\"${CODEX_HOME:-$HOME/.codex}\"\nls -la \"$CODEX_DIR/config.toml\" \"$CODEX_DIR/settings.json\" 2>/dev/null\nrg 'keyword-detector|persistent-mode|session-start|stop-continuation' \"$CODEX_DIR/config.toml\" \"$CODEX_DIR/settings.json\" 2>/dev/null || true\nls -la \"$CODEX_DIR/hooks\"/*.sh 2>/dev/null\nls -la \"$CODEX_DIR/AGENTS.md\" 2>/dev/null\ngrep -q \"oh-my-codex Multi-Agent System\" \"$CODEX_DIR/AGENTS.md\" 2>/dev/null && echo \"Has OMX config\" || echo \"Missing OMX config\"\nls -la \"$CODEX_DIR/agents\" \"$CODEX_DIR/commands\" \"$CODEX_DIR/skills\" \"$HOME/.agents/skills\" 2>/dev/null\n```\n\nClassify legacy hook references as **CRITICAL** (duplicate hooks). The scripts `keyword-detector.sh`, `persistent-mode.sh`, `session-start.sh`, and `stop-continuation.sh` are **WARN**. Missing AGENTS.md is **CRITICAL**; missing the OMX marker is **WARN**. `${CODEX_HOME:-~/.codex}/skills` is the canonical user root. `~/.agents/skills` is historical and overlapping trees can duplicate skill entries. OMX files under legacy `agents/` or `commands/` are **WARN**.\n\nWith `--team`, retain any `resume_blocker`, `slow_shutdown`, `delayed_status_lag`, `stale_leader`, or `orphan_tmux_session` diagnostics; failed checks set a non-zero exit status.\n\n## Report contract\n\n```text\n## OMX Doctor Report\n### Summary\n[HEALTHY / ISSUES FOUND]\n### Checks\n| Check | Status | Details |\n| Plugin Version | OK/WARN/INFO | ... |\n| Hook Config (config.toml / legacy settings.json) | OK/CRITICAL | ... |\n| Legacy Scripts (~/.codex/hooks/) | OK/WARN | ... |\n| AGENTS.md | OK/WARN/CRITICAL | ... |\n| Plugin Cache | OK/WARN | ... |\n| Legacy Agents / Commands | OK/WARN | ... |\n| Skills (canonical / historical root) | OK/WARN | ... |\n### Issues Found\n1. ...\n### Recommended Fixes\n...\n```\n\n## Remediation (after user confirmation and confirming each target is OMX-owned)\n\nRemove only confirmed OMX legacy content; preserve unrelated user files:\n\n```bash\n# If settings.json exists, remove only its legacy \"hooks\" section.\nrm -f \"$CODEX_DIR/hooks/keyword-detector.sh\" \"$CODEX_DIR/hooks/persistent-mode.sh\" \"$CODEX_DIR/hooks/session-start.sh\" \"$CODEX_DIR/hooks/stop-continuation.sh\"\nPLUGIN_CACHE_ROOT=\"${CODEX_HOME:-$HOME/.codex}/plugins/cache\"\nfind \"$PLUGIN_CACHE_ROOT\" -path \"*/oh-my-codex\" -type d -prune -exec rm -rf {} +\n```\n\nFor older curl installs, inspect first and remove only directories containing OMX-managed files:\n\n```bash\nls -la \"$CODEX_DIR/agents\" \"$CODEX_DIR/commands\" \"$CODEX_DIR/skills\" \"$HOME/.agents/skills\" 2>/dev/null\n# Optional backups:\n# mv \"$CODEX_DIR/agents\" \"$CODEX_DIR/agents.bak\"\n# mv \"$CODEX_DIR/commands\" \"$CODEX_DIR/commands.bak\"\n# mv \"$HOME/.agents/skills\" \"$HOME/.agents/skills.bak\"\nrm -rf \"$CODEX_DIR/agents\" \"$CODEX_DIR/commands\" \"$HOME/.agents/skills\"\n```\n\nIf AGENTS.md is missing/outdated, fetch the current raw file and write it to `$CODEX_DIR/AGENTS.md`:\n\n```text\nWebFetch(url: \"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/main/docs/AGENTS.md\", prompt: \"Return the complete raw markdown content exactly as-is\")\n```\n\nTo keep only the newest cache version for a selected marketplace:\n\n```bash\nPLUGIN_CACHE_DIR=\"$PLUGIN_CACHE_ROOT/$MARKETPLACE_NAME/oh-my-codex\"\nKEEP_VERSION=$(for d in \"$PLUGIN_CACHE_DIR\"/*; do [[ -d \"$d\" ]] && basename \"$d\"; done | sort -V | tail -1)\n[[ -n \"$KEEP_VERSION\" ]] && find \"$PLUGIN_CACHE_DIR\" -mindepth 1 -maxdepth 1 -type d ! -name \"$KEEP_VERSION\" -exec rm -rf {} +\n```\n\nIf AGENTS.md is missing or stale, refresh it from the current release source, then rerun `omx doctor`. If legacy `~/.agents/skills` overlaps the canonical root, archive/remove that tree only after checking for custom skills. Restart Codex after fixes and report before/after evidence.\n\n## Exit conditions\n\nStop with **HEALTHY** only when required paths, hook/config checks, AGENTS marker, plugin cache status, and (when requested) Team checks pass. Otherwise report **ISSUES FOUND**, exact failed evidence, and the smallest confirmed remediation; do not claim a fix from a recommendation alone.\n","plugins/oh-my-codex/skills/hud/SKILL.md":"---\nname: \"hud\"\ndescription: \"Show or configure the OMX HUD (two-layer statusline)\"\nrole: \"display\"\nscope: \".omx/**\"\n---\n\n# HUD Skill\n\nThe OMX HUD uses a two-layer architecture:\n\n1. **Layer 1 - Codex built-in statusLine**: Real-time TUI footer showing model, git branch, and context usage. Configured via `[tui] status_line` in `~/.codex/config.toml`. Zero code required.\n\n2. **Layer 2 - `omx hud` CLI command**: Shows OMX-specific orchestration state (ralph, ultrawork, autopilot, team, pipeline, ecomode, turns). Reads `.omx/state/` files.\n\n## Quick Commands\n\n| Command | Description |\n|---------|-------------|\n| `omx hud` | Show current HUD (modes, turns, activity) |\n| `omx hud --watch` | Live-updating display (polls every 1s) |\n| `omx hud --json` | Raw state output for scripting |\n| `omx hud --preset=minimal` | Minimal display |\n| `omx hud --preset=focused` | Default display |\n| `omx hud --preset=full` | All elements |\n\n## Presets\n\n### minimal\n```\n[OMX] ralph:3/10 | turns:42\n```\n\n### focused (default)\n```\n[OMX] ralph:3/10 | ultrawork | team:3 workers | turns:42 | last:5s ago\n```\n\n### full\n```\n[OMX] ralph:3/10 | ultrawork | autopilot:execution | team:3 workers | pipeline:exec | turns:42 | last:5s ago | total-turns:156\n```\n\n## Setup\n\n`omx setup` automatically configures both layers:\n- Adds `[tui] status_line` to `~/.codex/config.toml` (Layer 1)\n- Writes `.omx/hud-config.json` with default preset (Layer 2)\n- Default preset is `focused`; if HUD/statusline changes do not appear, restart Codex CLI once.\n\n## Layer 1: Codex Built-in StatusLine\n\nConfigured in `~/.codex/config.toml`:\n```toml\n[tui]\nstatus_line = [\"model-with-reasoning\", \"git-branch\", \"context-remaining\"]\n```\n\nAvailable built-in items (Codex CLI v0.101.0+):\n`model-name`, `model-with-reasoning`, `current-dir`, `project-root`, `git-branch`, `context-remaining`, `context-used`, `five-hour-limit`, `weekly-limit`, `codex-version`, `context-window-size`, `used-tokens`, `total-input-tokens`, `total-output-tokens`, `session-id`\n\n## Layer 2: OMX Orchestration HUD\n\nThe `omx hud` command reads these state files:\n- `.omx/state/ralph-state.json` - Ralph loop iteration\n- `.omx/state/ultrawork-state.json` - Ultrawork mode\n- `.omx/state/autopilot-state.json` - Autopilot phase\n- `.omx/state/team-state.json` - Team workers\n- `.omx/state/pipeline-state.json` - Pipeline stage\n- `.omx/state/ecomode-state.json` - Ecomode active\n- `.omx/state/hud-state.json` - Last activity (from notify hook)\n- `.omx/metrics.json` - Turn counts\n\n## Configuration\n\nHUD config stored at `.omx/hud-config.json`:\n```json\n{\n \"preset\": \"focused\"\n}\n```\n\n## Color Coding\n\n- **Green**: Normal/healthy\n- **Yellow**: Warning (ralph >70% of max)\n- **Red**: Critical (ralph >90% of max)\n\n## Troubleshooting\n\nIf the TUI statusline is not showing:\n1. Ensure Codex CLI v0.101.0+ is installed\n2. Run `omx setup` to configure `[tui]` section\n3. Restart Codex CLI\n\nIf `omx hud` shows \"No active modes\":\n- This is expected when no workflows are running\n- Start an explicitly requested supported workflow (`$autopilot` or `$ultragoal`) and check again\n","plugins/oh-my-codex/skills/omx-setup/SKILL.md":"---\nname: omx-setup\ndescription: Setup and configure oh-my-codex using current CLI behavior\n---\n\n# OMX Setup\n\nUse this task card to install or refresh OMX for the current project and/or user scope. Shared safety, lifecycle, hook, team, autonomy, and cancellation rules live in `templates/AGENTS.md`. Do not infer new CLI behavior from this card; the implementation is authoritative.\n\n## Command and alternatives\n\n```bash\nomx setup [--force] [--merge-agents|--no-merge-agents|--clear-merge-agents-policy] [--dry-run] [--verbose] [--scope ] [--plugin|--legacy|--install-mode ] [--mcp ] [--no-mcp|--with-mcp] [--disable-team|--enable-team|--team-mode ]\nomx agents-init [path] [--dry-run] [--force] [--verbose]\n```\n\nUse `agents-init` for lightweight AGENTS.md scaffolding only, not a full install.\n\nSupported setup options:\n- `--force`: overwrite/reinstall managed artifacts; transient, not persisted or replayed.\n- `--merge-agents`, `--no-merge-agents`, `--clear-merge-agents-policy`: exact bare selectors (no values/equals). Repeated identical selectors are idempotent; conflicting selectors fail before mutations. Set persists an explicit policy per invoking project root; clear removes it and cannot combine with a set. Merge refreshes managed sections; no-merge only suppresses that branch and is not a preserve mode.\n- `--dry-run`, `--verbose`: preview actions or show per-file/per-step detail.\n- `--scope user|project`: choose user (`~/.codex`, `~/.omx/agents`) or project (`./.codex`, `./.omx/agents`) targets.\n- `--plugin` / `--legacy`: select delivery mode; `--install-mode legacy|plugin` is the canonical scripted spelling. Conflicting mode flags fail.\n- `--mcp none|compat` (plus `--no-mcp` / `--with-mcp`): omit or enable first-party MCP compatibility and shared registry sync.\n- `--disable-team`, `--enable-team`, `--team-mode enabled|disabled`: select Team skill/context generation; conflicting selectors fail.\n\n## Resolve setup\n\n1. Scope: explicit flag, valid persisted `./.omx/setup-scope.json`, TTY choice (default `user`), or non-interactive `user`. Legacy `project-local` migrates to `project`.\n2. Mode: explicit flag, persisted mode when retained, discovered `${CODEX_HOME:-~/.codex}/plugins/cache/**/.codex-plugin/plugin.json` with `name: oh-my-codex` (plugin default), otherwise legacy. TTY reruns summarize saved choices and offer keep/review/reset; non-interactive runs do not block.\n3. Create required directories and atomically persist preferences only after successful setup.\n\n## What setup changes\n\n- Legacy mode installs prompts/native agents/skills and merges full config.toml.\n- Plugin mode archives/removes legacy OMX-managed prompts/skills, refreshes installable native agent TOMLs and stale generated non-installable agents, and keeps setup-owned runtime hooks.\n- Both modes verify Team CLI interop markers in built `dist/cli/team.js`, generate AGENTS defaults only when selected/allowed, and write `./.omx/hud-config.json`; notification hook references are setup-owned outside plugin skill delivery.\n- `AGENTS.md` is `./AGENTS.md`. Without `--force` or `--merge-agents`, interactive runs ask before overwrite and non-interactive runs preserve it. Active-session safeguards may skip writes. Plugin mode may separately prompt for AGENTS and `developer_instructions` defaults; non-interactive runs preserve existing files.\n- Plugin mode enables setup-owned runtime flags (`plugin_hooks`, `goals`, or legacy `hooks`/`codex_hooks` fallback). Project scope uses `CODEX_HOME=./.codex` unless explicitly overridden.\n\n## Verify\n\n```bash\nomx setup --force --verbose\nomx doctor\n```\n\nExpect doctor evidence for prompts and skills in the selected scope, project-root AGENTS.md, `.omx/state`, and CLI-first config in the scope target `config.toml`. First-party MCP and shared registry sync are omitted unless setup used `--mcp compat` (if supported by the installed CLI).\n\nIf using local source, run `npm run build` before `node dist/cli/omx.js setup --force --verbose` and `node dist/cli/omx.js doctor`. If AGENTS was not overwritten or merged, stop the active OMX session and rerun with `--force` or `--merge-agents`; do not edit lifecycle state manually.\n\n## Discovery troubleshooting\n\nIf `$omx-setup` is absent/stale: run `omx setup --verbose`, then `omx doctor`; verify `./.codex/skills/omx-setup/SKILL.md` for project scope or `${CODEX_HOME:-~/.codex}/skills/omx-setup/SKILL.md` for legacy user scope. In plugin mode verify the oh-my-codex plugin is installed/discovered. For duplicates, inspect historical `~/.agents/skills` overlap and follow doctor/setup cleanup guidance.\n\n## Exit contract\n\nReport selected scope/mode, dry-run versus mutation, AGENTS policy, affected roots, and doctor indicators. Stop only after setup completes successfully and verification identifies the expected files/config; on failure preserve the exact command output and rerun the smallest corrective command. Do not claim installation from a dry-run alone.\n","plugins/oh-my-codex/skills/performance-goal/SKILL.md":"---\nname: performance-goal\ndescription: \"Run an evaluator-gated performance optimization workflow over Codex goal mode with durable OMX artifacts and safe goal handoffs.\"\n---\n\n# Performance Goal Workflow\n\nUse this skill when a user asks OMX to optimize performance and wants a goal-oriented loop rather than a one-off review.\n\n## Contract\n\n- OMX owns durable workflow state under `.omx/goals/performance//`.\n- Codex goal mode owns only the active-thread focus/accounting primitive.\n- Shell commands do **not** mutate hidden Codex goal state. They write artifacts and emit model-facing handoff text.\n- No optimization work may start until an evaluator command and pass/fail contract exist.\n- Do not call `update_goal({status: \"complete\"})` until the evaluator has a passing checkpoint and a completion audit proves the objective is done; then call `get_goal` again and pass that fresh snapshot to `omx performance-goal complete --codex-goal-json`.\n\n## CLI\n\nCreate the workflow and evaluator contract:\n\n```sh\nomx performance-goal create \\\n --objective \"Reduce CLI startup latency by 20%\" \\\n --evaluator-command \"npm run perf:startup\" \\\n --evaluator-contract \"PASS when p95 latency improves by 20% and regression tests pass\" \\\n --slug startup-latency\n```\n\nEmit the Codex goal handoff:\n\n```sh\nomx performance-goal start --slug startup-latency\n```\n\nRecord evaluator evidence:\n\n```sh\nomx performance-goal checkpoint --slug startup-latency --status pass --evidence \"benchmark + tests passed\"\nomx performance-goal checkpoint --slug startup-latency --status fail --evidence \"benchmark regressed\"\nomx performance-goal checkpoint --slug startup-latency --status blocked --evidence \"missing fixture\"\n```\n\nComplete only after a passing checkpoint:\n\n```sh\nomx performance-goal complete --slug startup-latency --evidence \"final evaluator evidence\" --codex-goal-json \n```\n\n## Agent Loop\n\n1. Run `omx performance-goal create` if no workflow exists.\n2. Run `omx performance-goal start` and follow the handoff:\n - call `get_goal`;\n - call `create_goal` only when no active goal exists and the objective is explicit;\n - work only against the evaluator contract;\n - after evaluator pass and completion audit, call `update_goal({status: \"complete\"})`, call `get_goal` again, and pass that snapshot to `omx performance-goal complete --codex-goal-json`;\n - after `omx performance-goal complete` succeeds, run `/goal clear` in the Codex UI before starting another goal in this same thread/session; OMX prints this terminal cleanup step but does not invoke hidden clear routes;\n3. Optimize in small reversible patches.\n4. Run the evaluator and related regression tests.\n5. Record each pass/fail/blocker with `checkpoint`.\n6. Complete only when the pass artifact exists and no required work remains.\n\n## Completion Gate\n\nA performance goal is incomplete unless `.omx/goals/performance//state.json` contains a `lastValidation.status` of `pass` and `omx performance-goal complete` receives a matching complete Codex `get_goal` snapshot via `--codex-goal-json`. Passing ordinary tests alone is not sufficient unless they are the declared evaluator contract.\n\nLifecycle: `create_goal` starts the Codex thread goal, `update_goal({status: \"complete\"})` marks terminal success after the evaluator and audit pass, and `/goal clear` removes the completed thread goal when another same-thread goal is needed. OMX shell commands and hooks reconcile snapshots and print the cleanup instruction; they must not mutate hidden Codex goal state.\n","plugins/oh-my-codex/skills/plan/SKILL.md":"---\nname: plan\ndescription: Lightweight planning with optional interview\n---\n\n\nPlan creates concise, actionable work plans. Auto-detects interview vs direct, supports `--interview` for Socratic clarification and `--review` for evaluation.\n\n\n\n- Planning before implementation — \"plan this\", \"let's plan\"\n- Requirements are vague and need scoping — use `--interview`\n- Reviewing an existing plan — `--review`\n\n\n\n- Want direct execution — execute the scoped task directly; use `ultragoal` only for durable goals or `team` for coordinated parallel work\n- Simple focused fix with obvious scope — skip planning\n\n\n\n- Auto-detect interview vs direct; `--interview` forces Socratic mode, `--direct` skips it\n- Ask one question at a time; gather codebase facts first\n- `omx explore` is deprecated. Use normal repository inspection for codebase facts; `omx sparkshell` only for explicit shell-native evidence\n- Plans must be evidence-backed: 80%+ claims cite file/line, 90%+ criteria testable\n- Right-size steps to scope; save to `.omx/plans/`\n\n\n\n\n### Mode Selection\n| Mode | Trigger | Behavior |\n|------|---------|----------|\n| Interview | `--interview` or broad request | Socratic requirements gathering |\n| Direct | `--direct` or detailed request | Generate plan immediately |\n| Review | `--review` | Critic evaluation of existing plan |\n\n### Interview (`--interview`)\n1. Classify request; ask one focused question via `omx question`\n2. Gather codebase facts first, then ask informed follow-ups\n3. Build on answers; consult Analyst for hidden requirements\n4. Create plan when user signals readiness\n\n### Direct\n1. Quick analysis (optional Analyst)\n2. Generate plan immediately\n3. Optional Critic review if requested\n\n### Review (`--review`)\n1. Read plan from `.omx/plans/`\n2. Evaluate via Critic; verdict APPROVED/REVISE/REJECT\n3. If author == reviewer, hand off to `$code-review`\n\n### Output\nEvery plan includes: Requirements Summary, Acceptance Criteria (testable), Implementation Steps (with file refs, adaptive count), Risks/Mitigations, Verification. Saved to `.omx/plans/`.\n\nOutcome-first framing: apply outcome-first framing, concise visible updates for multi-step planning. Local overrides for the active workflow branch apply via newer user task updates. If the user says `continue`, continue the current branch instead of restarting.\n\n\n\n\n- `omx explore` is deprecated. Use normal repository inspection; `omx sparkshell` only for explicit shell-native evidence\n- Use `omx question` for interview questions; plain text only as fallback\n- Use `ask_codex` with `planner`/`analyst`/`critic` as needed\n\n\n\n- Stop interviewing when requirements are clear — do not over-interview\n- Escalate on irreconcilable trade-offs requiring business decision\n- \"just do it\" / \"skip planning\" → hand off to `$ultragoal`\n\n\n\n- [ ] Acceptance criteria testable (90%+ concrete)\n- [ ] Claims cite file/line (80%+)\n- [ ] Risks have mitigations, no vague terms\n- [ ] Plan saved to `.omx/plans/`\n\n\n\n## Question Classification\n| Type | Examples | Action |\n|------|----------|--------|\n| Codebase Fact | \"Where is X?\" | Explore first, do not ask |\n| User Preference | \"Priority?\" | Ask via `omx question` |\n| Scope Decision | \"Include Y?\" | Ask user |\n\n## Review Quality Criteria\n| Criterion | Standard |\n|-----------|----------|\n| Clarity | 80%+ claims cite file/line |\n| Testability | 90%+ criteria concrete |\n| Verification | File refs exist |\n\n","plugins/oh-my-codex/skills/ralplan/SKILL.md":"---\nname: ralplan\ndescription: Consensus planning stage for Planner -> Architect -> Critic handoff to $ultragoal\n---\n\n# Ralplan (Consensus Planning Alias)\n\nRalplan is the canonical consensus-planning stage used by Autopilot between `$deep-interview` and `$ultragoal`. It drives Planner, Architect, and Critic planning and records their review lifecycle with **RALPLAN-DR structured deliberation** (short mode by default, deliberate mode for high-risk work). Local lifecycle evidence is not host-issued security authority, but ordinary progression to Ultragoal must remain reachable after the execution-ready plan and sequential review evidence are durable; missing host provenance must not terminalize Ralplan or block cancel, clear, or recovery.\n\n## Usage\n\n```\n$ralplan \"task description\"\n```\n\nStandalone advisory planning is explicitly opt-in:\n\n```text\n$ralplan --advisory \"task description\"\n```\n\nAdvisory runs the same sequential Planner → Architect → Critic review lifecycle, binds the plan and both review artifacts to exact bytes and one tracker-backed iteration, then returns to the caller with `active:false`. It is a cooperative workflow pause, not a security fence or permission system. It never emits a `PreToolUse` allow/block decision, never completes the host consensus gate, never authorizes execution, and never suppresses unrelated host behavior. Terminal state must carry explicit `false` values for the consensus gate, host verification, and execution handoff rather than omitting them. A later concrete affirmative execution request may produce non-authoritative routing context, but it does not persist a permission, rewrite terminal evidence, or create an automatic handoff; quotations, code, examples, documentation, questions, modal requests, negations, and vague approval remain classifier negatives. `approved+proven` requires complete lifecycle digests plus post-write revalidation. Administrative abandonment is append-only, idempotent for prepared or committed journals, and records a separate byte-bound admin event without rewriting the original closeout journal. Real enforcement requires an explicit host-issued, host-verified receipt or capability on a non-user-mintable surface; local Advisory files, prompts, session/thread fields, tracker records, and HERDR observability cannot substitute for it. On Darwin, each Advisory evidence artifact is limited to 128 KiB by the pinned-directory reader; other supported platforms allow up to 8 MiB.\n\n## Flags\n\n- `--interactive`: Enables user prompts at key decision points (draft review in step 2 and final approval in step 6). Without this flag the workflow runs fully automated — Planner → Architect → Critic loop — and outputs the final plan without asking for confirmation.\n- `--deliberate`: Forces deliberate mode for high-risk work. Adds pre-mortem (3 scenarios) and expanded test planning (unit/integration/e2e/observability). Without this flag, deliberate mode can still auto-enable when the request explicitly signals high risk (auth/security, migrations, destructive changes, production incidents, compliance/PII, public API breakage).\n- `--advisory`: Standalone only. It cannot be combined with Autopilot, Pipeline, Team, Ralph, Ultragoal, execution flags, or unknown flags. Activation requires canonical session, root thread, and turn identity.\n\n## Ontology-heavy review\n\nFor requirements semantics, taxonomy, prompt/spec design, policy distinctions, or category-risk architecture, cite the `architect` role agent's read-only review as advisory evidence. Its findings can inform the plan or follow-up evidence when explicitly used, but `$ralplan` itself records Architect→Critic lifecycle evidence only, and advisory review is never a durable execution authorization.\n\n## Usage with interactive mode\n\n```\n$ralplan --interactive \"task description\"\n```\n\n## Behavior\n\n## GPT-5.6 Guidance Alignment\n\nUse the shared workflow guidance pattern: outcome-first framing, concise visible updates for multi-step planning, local overrides for the active workflow branch, evidence-backed planning and validation expectations, explicit stop rules, right-sized implementation/PRD shape, and automatic continuation for safe reversible steps. Ask only for material, destructive, credentialed, external-production, or preference-dependent branches.\n\nThis skill runs its own consensus runtime; it does not delegate to a nonexistent Plan consensus mode:\n\n```\nomx ralplan run --task [--session ]\n```\n\nThe consensus workflow:\n1. **Planner** creates an adaptive plan (right-sized to task scope; do not default to exactly five steps) and a compact **RALPLAN-DR summary** before review. Current `[main]` vs `[planner]` behavior: standalone `$ralplan` may be authored by the active main planning lane unless the caller/runtime supplies a dedicated planner routing record; inside `$autopilot`, state field `planning_routing.owner:\"planner\"` means the initial Planner draft/decomposition must use dedicated `[planner]`. Set `.omx-config.json` `agentModels.planner` to opt into a specific planner model and force dedicated planner ownership for complex Autopilot planning even when `[main]` is not cheap/mini. The RALPLAN-DR summary includes:\n - Principles (3-5)\n - Decision Drivers (top 3)\n - Viable Options (>=2) with bounded pros/cons\n - If only one viable option remains, explicit invalidation rationale for alternatives\n - Deliberate mode only: pre-mortem (3 scenarios) + expanded test plan (unit/integration/e2e/observability)\n2. **User feedback** *(--interactive only)*: If `--interactive` is set, use the structured question UI (`omx question` in attached tmux; native structured input outside tmux when available) to present the draft plan **plus the Principles / Drivers / Options summary** before review (Proceed to review / Request changes / Skip review). Otherwise, automatically proceed to review.\n**Native role-routing preflight:** Keyword routing may already have selected Ralplan, but it is not authority. Run `omx ralplan preflight --json` only when the native task surface reports `role_routing_unavailable` and this workflow attempts adapted Ralplan Planner, Architect, or Critic authority, adapted role-intent, or adapted consensus authority. On `unsupported_documented_leader_proof`, stop before that adapted authority and use a Codex surface with documented root proof or a reviewed alternative workflow. Do not infer root identity from `session_id`, undocumented `thread_id`, session/pointer/transcript/cwd state, absence of child data, or a prompt label. Ordinary native planning, lifecycle, state, status, health, HUD, runtime, setup, install, sync, and unrelated delegation are outside this preflight boundary and remain governed by existing controls.\n\n**Native role-routing rule:** When the native surface exposes `agent_type` role routing, set `agent_type` to an installed OMX role and never omit it for OMX work. When it does not (`role_routing_unavailable`), do not fabricate `agent_type`. On the exact reviewed Codex releases 0.144.5, 0.145.0, 0.146.1, and 0.148.0-alpha.5, adapted Ralplan Planner, Architect, Critic, role-intent, and consensus authority are unavailable because they lack documented root proof; every other version remains unknown and fails closed. Do not silently weaken routing with a prompt role label or inferred carrier. Use a Codex surface with documented root proof or a reviewed alternative workflow for that authority. A direct `omx ralplan role-intent write` attempt is denied with machine reason `unsupported_documented_leader_proof`.\n\n3. **Architect** reviews for architectural soundness and must provide the strongest steelman antithesis, at least one real tradeoff tension, and (when possible) synthesis — **await completion before step 4**. Launch this as a subsequent role-specific `Architect` subagent and pass the full task statement, context snapshot, PRD/test-spec paths, and relevant prior findings; do not substitute an unvalidated reviewer identity or a short improvised reviewer prompt. In deliberate mode, Architect should explicitly flag principle violations.\n4. **Critic** evaluates against quality criteria — run only after step 3 completes. Launch this as a subsequent role-specific `Critic` subagent with the full task statement, context snapshot, PRD/test-spec paths, and the completed Architect review; do not ask the Architect subagent to perform the Critic gate and do not substitute an unvalidated reviewer identity or a short improvised reviewer prompt. Critic must enforce principle-option consistency, fair alternatives, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. In deliberate mode, Critic must reject missing/weak pre-mortem or expanded test plan.\n5. **Re-review loop** (max 5 iterations): Any non-`APPROVE` Critic verdict (`ITERATE` or `REJECT`) MUST run the same full closed loop:\n a. Collect Architect and Critic feedback\n b. Revise the plan with Planner\n c. Return to Architect review\n d. Return to Critic evaluation\n e. Repeat this loop until Critic returns `APPROVE` or 5 iterations are reached\n f. If 5 iterations are reached without `APPROVE`, present the best version to the user\n6. On Critic approval, persist the execution-ready planning artifacts and sequential Architect→Critic evidence. In standalone interactive Ralplan, present the requested future execution lane. Inside Autopilot, the existing explicit `$autopilot` invocation authorizes the supervised transition to its defining next stage, `$ultragoal`; persist an Autopilot-owned `ralplan_execution_handoff` bound to the same session and review cycle.\n7. Record `ralplan_execution_handoff` with `{authorized: true, reason, authorized_at, session_id, review_cycle, source: \"autopilot\"|\"user\"}`. `source:\"autopilot\"` is valid only for a supervised active Autopilot run whose current phase is `ralplan`; it does not claim host-consensus authority.\n8. Transition to `$ultragoal` after the durable plan, sequential approvals, and bound execution handoff exist. Do not implement directly inside Ralplan.\n\n> **Important:** Steps 3 and 4 MUST run sequentially as role-specific subagents. Do NOT issue both agent calls in the same parallel batch. Always await the subsequent `Architect` result before invoking the subsequent `Critic`; their completed approvals establish local lifecycle evidence only and cannot satisfy the durable execution gate.\n\n## Planning/Execution Boundary\n\n`$ralplan` is a planning mode. While ralplan is active and no explicit execution handoff is active, implementation-focused write tools are out of scope. Ralplan may inspect the repository and may write only planning artifacts such as `.omx/context/`, `.omx/plans/`, `.omx/specs/`, and required `.omx/state/` records.\n\nThe canonical flow is:\n\n```\n$ralplan -> local Architect→Critic lifecycle evidence -> bound execution handoff -> $ultragoal\n```\n\nBefore any execution lane begins, ralplan must emit terminal planning state (complete, paused, failed, or waiting for input) and the durable handoff record below. Do not continue from consensus planning into direct code edits in the same ralplan session.\n\n## Durable Consensus Handoff Contract\n\nRalplan is not complete, skippable, or ready for execution merely because `.omx/plans/prd-*.md` and `.omx/plans/test-spec-*.md` exist. Those files are planning artifacts, not consensus evidence.\n\nBefore any Autopilot, Ultragoal, Team, or implementation handoff, persist a durable handoff record that distinguishes:\n\n- `planning_artifacts`: PRD/test-spec paths.\n- `ralplan_architect_review`: the completed Architect review with an approving verdict.\n- `ralplan_critic_review`: the completed Critic review with an approving verdict, recorded only after the Architect review.\n- `ralplan_execution_handoff`: persist `{authorized: true, reason: \"\", authorized_at: \"\", session_id: \"\", review_cycle: , source: \"autopilot\"|\"user\"}`. Autopilot may issue this only for its own supervised `ralplan` phase; standalone Ralplan uses `source:\"user\"`.\n- `ralplan_consensus_gate.complete` records lifecycle completion after the sequential Architect and Critic approvals. It is not a host-security claim. Locally authored JSON/env/prompt/tracker/transcript/receipt-shaped evidence must never be described as host-issued authority.\n\nIf Architect is missing/blocked, keep the workflow in Architect review or report that blocker. If Critic is missing/blocked/non-approving, keep the workflow in Critic/re-review or report the max-iteration outcome. After both reviews approve, execution begins only when the matching `ralplan_execution_handoff` is durable. Existing plan/test-spec files alone are never permission to skip Ralplan or execute.\n\nFollow the Plan skill's full documentation for consensus mode details.\n\n## Goal-Mode Follow-up Suggestions\n\nWhen a bound `ralplan_execution_handoff` permits execution, include product-facing goal-mode suggestions alongside coordinated Team execution. Record the requested lane and persist the handoff without claiming host-issued authority.\n\n- `$ultragoal` — **default goal-mode follow-up** for implementation or general goal-oriented follow-up plans that should become durable Codex/OMX goals with sequential completion tracking.\n- `$autoresearch` — research-project follow-up when the plan centers on a question, literature/reference gathering, evaluator-backed research, or a professor/critic-style research deliverable. (`$autoresearch-goal` was retired to a sunset stub in OMX 0.21.)\n- `$performance-goal` — optimization/performance follow-up when the plan centers on speed, latency, throughput, memory, benchmark, or other measurable performance work.\n\nUse `$ultragoal` for durable goal tracking and `$team` for coordinated parallel implementation. When combined, Ultragoal owns the ledger and Team returns checkpoint-ready execution evidence.\nUse the available-agent-types roster to produce explicit role/staffing allocation, reasoning-by-lane guidance, concrete launch hints (including `omx team` when parallel delivery is justified), and team verification responsibilities for any future receipt-authorized execution path.\n\n## Pre-context Intake\n\nBefore consensus planning or execution handoff, ensure a grounded context snapshot exists:\n\n1. Derive a task slug from the request.\n2. Reuse the latest relevant snapshot in `.omx/context/{slug}-*.md` when available.\n3. If none exists, create `.omx/context/{slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`) with:\n - task statement\n - desired outcome\n - known facts/evidence\n - constraints\n - unknowns/open questions\n - likely codebase touchpoints\n4. If ambiguity remains high, gather brownfield facts first. `omx explore` is deprecated; use normal repository inspection tools/subagents for simple read-only repository lookups and `omx sparkshell` only for explicit shell-native read-only evidence. Then run `$deep-interview --quick ` before continuing.\n5. If the plan depends on official docs, version-aware framework guidance, best practices, or external dependency behavior, use `$best-practice-research` as the bounded evidence wrapper and auto-delegate `researcher` for the official/upstream lookup before finalizing the planning handoff so execution does not start from repo-local recall alone.\n6. If a prior `$autoresearch` run exists, treat its approved artifact as evidence for the plan. Read historical artifacts from `$autoresearch-goal` only as compatibility input. Do not include Autoresearch as a final architecture or runtime component unless the user explicitly requested ongoing research automation; otherwise synthesize the evidence into the `$ralplan` ADR, risks, and verification steps.\n\nDo not hand off to execution modes until this intake is complete; if urgency forces progress, explicitly document the risk tradeoffs.\n\n## Routing boundary\n\nOrdinary scoped tasks stay in the direct execution lane described by `templates/AGENTS.md`.\nExplicit workflow requests follow the keyword registry (`src/hooks/keyword-registry.ts`) and their owning skill contracts; this card does not define a second activation table.\nOnce Ralplan is active, preserve the planning/execution and consensus handoff requirements above. A conversational “just do it” is not a substitute for the required review evidence.\n\n## Scenario Examples\n\n**Good:** The user says `continue` after the workflow already has a clear next step. Continue the current branch of work instead of restarting or re-asking the same question.\n\n**Good:** The user changes only the output shape or downstream delivery step (for example `make a PR`). Preserve earlier non-conflicting workflow constraints and apply the update locally.\n\n**Bad:** The user says `continue`, and the workflow restarts discovery or stops before the missing verification/evidence is gathered.\n","plugins/oh-my-codex/skills/skill/SKILL.md":"---\nname: skill\ndescription: Manage local skills - list, add, remove, search, edit, setup wizard\nargument-hint: \" [args]\"\n---\n\n# Skill Management\n\nManage local `SKILL.md` files with `/skill` commands. Shared execution, delegation,\nstate, hook, team, cancellation, verification, and escalation invariants live in\n`templates/AGENTS.md`; follow that contract instead of repeating it here.\n\n\nCreate, inspect, validate, update, and organize user- or project-scoped skills.\nKeep each skill specific, actionable, evidence-based, and useful to this codebase.\n\n\n\n- The user asks to list, add, edit, remove, search, inspect, sync, set up, scan, or validate skills.\n- A durable, codebase-specific solution or workflow should be captured as a skill.\n\n\n\n- Use `/learner` to extract a skill from a conversation and `/note` for a short note.\n- Do not use this prompt to change runtime code, catalogs, hooks, or installation logic.\n\n\n## Scopes and commands\n\nCanonical roots are `${CODEX_HOME:-$HOME/.codex}/skills/` (user) and `.codex/skills/`\n(project). A skill lives at `//SKILL.md`.\n\n| Command | Contract |\n|---|---|\n| `/skill list` | Scan both roots, parse frontmatter, and show name, description, triggers, scope, and quality/usage (`N/A` when unavailable). |\n| `/skill add [name]` | Run the authoring wizard, validate the name, choose scope, create `SKILL.md`, and report its path. |\n| `/skill edit ` | Find one scope, show metadata, then update description, triggers, argument hint, body, or rename and report the change. |\n| `/skill remove ` | Find the skill, show scope and metadata, confirm explicitly, then remove its directory. |\n| `/skill search ` | Case-insensitively search name, description, triggers, and body; rank name/trigger matches first and show context. |\n| `/skill info ` | Show parsed metadata, scope, path, and full body; suggest `/skill search` when absent. |\n| `/skill sync` | Compare user/project skills, show user-only/project-only/common entries, and confirm every copy or overwrite. |\n| `/skill setup` | Ensure both roots exist, scan them, then offer add, list, pattern scan, import, or done. |\n| `/skill scan` | Run setup's scan/inventory without its interactive menu. |\n| `/skill validate` | Validate every skill in both roots and report each path's pass/fail result; never rewrite files. |\n\nWith an argument, use direct command mode; without one, use the guided setup menu.\n\n## Authoring contract\n\nAsk for any missing values:\n1. `name`: lowercase letters/digits separated by single hyphens (`[a-z0-9]+(?:-[a-z0-9]+)*`).\n2. `description`: a concise, non-empty one-line purpose.\n3. `triggers`: comma-separated recognition terms.\n4. `argument-hint`: optional invocation arguments.\n5. `scope`: `user` or `project`.\n\nWrite this frontmatter at the start of every skill; optional metadata may add `id`,\n`source`, and `quality` without replacing required fields:\n\n```yaml\n---\nname: \ndescription: \ntriggers: [, ]\nargument-hint: \"\"\n# optional: id, source, quality\n---\n```\n\nUse an actionable body. The minimum recommended shape is:\n\n```markdown\n# \n\n## Purpose\nWhat durable, codebase-specific outcome does this skill provide?\n\n## When to Activate\nRecognition signals, scope, and explicit non-goals.\n\n## Workflow\n1. Inspect the named files or inputs.\n2. Apply the precise approach and record important assumptions.\n3. Verify observable behavior and report evidence.\n\n## Examples / Gotchas\nConcrete invocation, edge cases, and failure recovery.\n```\n\nPrefer hard-won, non-obvious knowledge over generic programming advice. Include\nexact paths, commands, error text, and expected evidence when they materially help.\n\n## Validation and errors\n\nBefore reporting success, check that the file exists, starts with `---` frontmatter,\nhas non-empty `name` and `description`, uses a valid name, and has a non-empty body.\nReject malformed or unterminated YAML, multiline required scalar values, duplicate\nnames in one scope, missing directories/files, permission failures, and invalid\narguments. Report errors consistently:\n\n```text\n✗ Error: \n→ Suggestion: \n```\n\n## Exit contract\n\nEvery command ends with one concise result: `✓` plus the affected skill/path and\nnext action, or `✗` plus the error and suggestion. Preserve files on cancel or\nvalidation-only runs. For add/edit/sync, report changed scope and metadata; for\nlist/search/info/scan/validate, report counts or matched paths and any failures.\n","plugins/oh-my-codex/skills/team/SKILL.md":"---\nname: team\ndescription: N coordinated agents on shared task list using tmux-based orchestration\n---\n\n# Team Skill\n\n## When to use\n\nUse only for an explicit `$team` request or `omx team ...` launch that benefits from durable tmux workers, shared task state, mailbox coordination, or worktree isolation. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot`; do not copy its durable rules into this card.\n\n## Inputs and preconditions\n\n- Launch shape: `omx team [N:agent-type] \"\"` (for example `omx team 3:executor \"implement X\"`).\n- Require `tmux -V`, a leader session with `$TMUX`, and the intended `omx` executable. In Codex App/plain non-tmux sessions, explain the runtime boundary instead of pretending Team is available.\n- Before launch, ground the task in a recent `.omx/context/{slug}-*.md`; create a concise snapshot when none exists. Include target, evidence, constraints, unknowns, and likely touchpoints.\n- Do not launch nested Team runs. Pick worker roles deliberately; use `OMX_TEAM_WORKER_CLI=codex|claude|auto` or `OMX_TEAM_WORKER_CLI_MAP=...` only when needed.\n- Per-agent reasoning is set by `agentReasoning`; accepted values are `low`, `medium`, `high`, `xhigh`, and `max`. `max` is passed unchanged and remains capability-dependent. `ultra` is unsupported and is not an alias for `max`.\n- Invalid configured values use the built-in role-default fallback. An explicit raw `-c model_reasoning_effort=...` is opaque and wins. When both sources are present, explicit raw reasoning wins over inherited Team reasoning and environment reasoning. Do not downgrade or retry `max` as `xhigh`; built-in role defaults remain unchanged.\n\n## Operational steps\n\n1. Start the runtime and capture startup evidence: `Team started: `, tmux target, worker panes, and the leader ACK mailbox.\n2. **Current Runtime Behavior:** runtime-owned task files and APIs are the operational interface; the durable ownership and safety rules remain in `templates/AGENTS.md`.\n3. Runtime creates `.omx/state/team//config.json`, `manifest.v2.json`, `tasks/task-.json`, worker identities/inboxes, mailbox files, and a dispatch queue. Workers receive `OMX_TEAM_WORKER`, `OMX_TEAM_STATE_ROOT`, and `OMX_TEAM_LEADER_CWD`.\n4. Deliver assignments through durable inbox/task state and the CLI API. The worker card defines ACK, claim, transition, mailbox, and idle-status commands.\n5. Prefer these machine-readable operations:\n ```bash\n omx team api send-message --input '{\"team_name\":\"\",\"from_worker\":\"leader-fixed\",\"to_worker\":\"worker-1\",\"body\":\"\"}' --json\n omx team api read-task --input '{\"team_name\":\"\",\"task_id\":\"\"}' --json\n omx team api transition-task-status --input '{\"team_name\":\"\",\"task_id\":\"\",\"from\":\"in_progress\",\"to\":\"completed\",\"claim_token\":\"\"}' --json\n ```\n6. Monitor with `omx team status --json` or `omx team await --timeout-ms 30000 --json`; inspect mailbox/state files when a worker is blocked or stale.\n7. Keep the team running until `pending=0`, `in_progress=0`, and `failed=0` (or an explicitly acknowledged failure path). Run `omx team shutdown ` only then, unless the user explicitly aborts.\n8. Verify shutdown evidence and state cleanup. Do not claim completion while workers are still writing.\n\n## Team and Ultragoal\n\nWhen a leader-owned `.omx/ultragoal/goals.json` exists, workers return task evidence only. The leader checkpoints with a fresh Codex `get_goal` snapshot:\n```bash\nomx ultragoal checkpoint --goal-id --status complete --evidence \"\" --codex-goal-json \n```\nTeam launch remains an explicit separate action; it does not create hidden Codex goals.\n\n## Dispatch and recovery\n\n- If dispatch reports `worker_notify_failed:`, inspect `tmux list-panes`, capture the pane, then send one concise trigger and re-check mailbox/state.\n- For Claude panes, do not spam Enter while work is active. Confirm runtime status first.\n- If a worker reports `omx team api ... ENOENT`, check whether shutdown or state deletion happened too early; preserve state until all transitions finish.\n- For a clean retry, kill only known stale worker panes, remove only the exact stale Team root, and relaunch; never kill the leader/HUD pane accidentally.\n\n## Exit and evidence\n\nReport team name, launch command, pane/ACK evidence, task counts, worker verification, failures or blockers, shutdown result, and cleaned state paths. Include any worktree or CLI-map choices and keep final integration/verification in the leader lane.\n","plugins/oh-my-codex/skills/ultragoal/SKILL.md":"---\nname: ultragoal\ndescription: Create and execute durable repo-native multi-goal plans over Codex goal mode artifacts.\n---\n\n# Ultragoal Workflow\n\n## When to use\n\nUse for `ultragoal`, `create-goals`, `complete-goals`, durable multi-goal planning, or sequential execution over Codex `/goal`. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot` for state ownership and goal-tool boundaries.\n\n## Inputs and preconditions\n\n- Durable artifacts are `.omx/ultragoal/brief.md`, `.omx/ultragoal/goals.json`, and `.omx/ultragoal/ledger.jsonl`.\n- New plans use aggregate Codex goal mode by default: one stable pointer objective for the plan while OMX tracks individual stories. Use `--codex-goal-mode per-story` only when explicitly requested.\n- Do not call `/goal clear` from shell or this skill. After a completed run, the operator may clear the interactive Codex goal in the Codex UI before another same-thread run.\n\n## Operational steps: create\n\nRun one command, then inspect the generated plan:\n```bash\nomx ultragoal create-goals --brief \"\"\nomx ultragoal create-goals --brief-file \ncat | omx ultragoal create-goals --from-stdin\nomx ultragoal create-goals --codex-goal-mode per-story --brief \"\"\n```\nIf refinement is needed, use explicit supported steering rather than editing durable artifacts by hand.\n\n## Operational steps: execute\n\nRepeat until `omx ultragoal status` reports all goals complete:\n\n1. Run `omx ultragoal complete-goals` and read its handoff.\n2. Call `get_goal`. Call `create_goal` with the printed payload only when no active Codex goal exists; otherwise continue the matching aggregate objective.\n3. Complete one OMX story and audit its objective against real artifacts and verification evidence.\n4. For intermediate aggregate stories, keep the Codex goal active and checkpoint:\n ```bash\n omx ultragoal checkpoint --goal-id --status complete --evidence \"\" --codex-goal-json \n ```\n5. For a blocked/failed story, use `--status blocked|failed` with evidence; resume failed work with `omx ultragoal complete-goals --retry-failed`.\n6. On the final story, complete the final gate below before `update_goal({status: \"complete\"})`; then call `get_goal` again and checkpoint the fresh complete snapshot.\n\n## Explicit steering\n\nUse evidence-backed directives only when the decomposition must change:\n```bash\nomx ultragoal steer --kind add_subgoal --title \"\" --objective \"<objective>\" --evidence \"<evidence>\" --rationale \"<reason>\" --json\nomx ultragoal steer --directive-json ./steering.json --json\n```\nSupported kinds: `add_subgoal`, `split_subgoal`, `reorder_pending`, `revise_pending_wording`, `annotate_ledger`, and `mark_blocked_superseded`. Ordinary prose does not mutate the plan; repeated structured directives dedupe.\n\n## Phase/HUD handoff\n\nAt standalone activation, declare the smallest accurate phase (`planning`, `executing`, `verifying`, `reviewing`, `checkpointing`, or `blocked`):\n```bash\nomx state write --input '{\"mode\":\"ultragoal\",\"active\":true,\"current_phase\":\"planning\"}' --json\n```\nInside Autopilot, keep the parent mode active and set `current_phase:\"ultragoal\"`; persist Ultragoal evidence under `handoff_artifacts.ultragoal` before a code-review handoff. Mark standalone Ultragoal complete only when every durable goal is complete.\n\n## Optional Team bridge\n\nFor parallel story execution, use the separate Team command. The leader records the Ultragoal checkpoint with a fresh `get_goal` snapshot; see the Team skill for the bridge details.\n\n## Final gate and exit evidence\n\nBefore final completion:\n\n1. Run targeted story verification.\n2. Run `ai-slop-cleaner` on changed files, then rerun verification.\n3. Audit every architecture/domain invariant from the brief/spec/accepted steering against implementation, test, and review evidence.\n4. Run `$code-review` through independent `code-reviewer` and `architect` lanes. If review or invariant proof is not clean, do not update the Codex goal; record durable blockers:\n ```bash\n omx ultragoal record-review-blockers --goal-id <id> --title \"Resolve final code-review blockers\" --objective \"<objective>\" --evidence \"<findings>\" --codex-goal-json <active-get-goal-json-or-path>\n ```\n5. If clean, call `update_goal({status: \"complete\"})`, call `get_goal`, and checkpoint with `--quality-gate-json` containing cleaner, verification, review, and architecture-invariant evidence.\n\nReport goal ids/statuses, ledger/checkpoint paths, fresh goal snapshot evidence, review verdicts, and any blocker. Never claim completion from OMX state alone.\n","plugins/oh-my-codex/skills/ultraqa/SKILL.md":"---\nname: ultraqa\ndescription: Adversarial dynamic e2e QA workflow - generate hostile scenarios, test, verify, fix, report, and clean up\n---\n\n# UltraQA Task Card\n\nUse this explicit opt-in when a runnable behavior needs adversarial dynamic end-to-end\nQA. Shared operating invariants live in `templates/AGENTS.md`; this card defines the\nQA matrix, evidence contract, and bounded cycling only.\n\n## When to use and inputs\n\n- Use `/ultraqa --tests|--build|--lint|--typecheck|--interactive` or `/ultraqa --custom \"pattern\"` for the corresponding goal; without a structured goal, derive a runnable behavior goal.\n- Inputs: goal, changed scope, acceptance criteria, runnable command/service, existing tests, and relevant state/cleanup paths.\n- Keep outcome-first framing, local overrides for the active workflow branch, and `continue` on the current verified next step.\n- If the user says `continue`, advance the current verified QA step rather than restarting discovery.\n- UltraQA is not satisfied by a shallow build/lint/typecheck/test checklist: exercise requested behavior through adversarial dynamic e2e scenarios whenever it can be run, simulated, or harnessed safely.\n\n## Plan and scenario matrix\n\nBefore commands, record a matrix with scenario id, intent, user/attacker model, setup,\ncommand or harness, expected signal, actual result, fixes, evidence, and cleanup.\nInclude a normal path and relevant hostile classes:\n\n1. **Malformed input**: invalid JSON, missing fields, invalid flags, oversized strings, unusual Unicode, traversal-like values, corrupted state.\n2. **Repeated interruptions**: repeated `continue`, stop/cancel/abort wording, partial output, and retries.\n3. **Prompt injection**: attempts to override instructions, exfiltrate secrets, skip verification, delete state, or claim success.\n4. **Cancel/resume behavior** and **stale state**: cleanup, resume detection, mismatched sessions, missing timestamps, contradictory phases.\n5. **Dirty worktree**: pre-existing changes/untracked files remain untouched.\n6. **Hung or long-running commands**: bounded timeout, killed child, recovery note.\n7. **Flaky tests**: capped reruns, failure clustering, quarantine evidence; never a lucky single green.\n8. **Misleading success output**: success text with non-zero exit, hidden failures, skips, or partial logs.\n\n## Cycle (maximum 5)\n\n1. **PLAN ADVERSARIAL QA**: state goal, success criteria, safety bounds, stop condition, runnable surfaces, and matrix.\n2. **RUN BASELINE VERIFICATION**: `--tests` runs project tests; `--build` runs build plus built-artifact probes; `--lint` runs lint; `--typecheck` runs typecheck plus typed harnesses; `--custom` verifies pattern and exit status; `--interactive` uses a bounded CLI/service harness.\n3. **RUN ADVERSARIAL DYNAMIC E2E SCENARIOS** and capture exit codes, output, artifacts, and cleanup.\n4. **CHECK RESULT**: pass only when baseline, adversarial scenarios, evidence, and cleanup all pass. Otherwise diagnose and fix, then repeat.\n5. **ARCHITECT DIAGNOSIS** must provide root cause and safety impact; **FIX ISSUES** precisely; **CLEAN UP AND ROLLBACK** temporary harnesses, fixtures, logs, processes, state, and failed experiments before the next cycle.\n\nGenerate temporary tests, scripts, fixtures, or harnesses only when useful. Use bounded runtimes,\nproject-native tools, and safe substitutes when a safety boundary blocks a scenario.\nUse absolute repo imports and `pathToFileURL(join(repoRoot, \"dist\", ...)).href`; Never rely on `./dist` from `/tmp`.\nUse a safe file writer with a non-interpolating file-write mechanism; do not use interpolating heredocs for JavaScript assertions.\nSanitize OMX runtime env for isolated probes: keep `OMX_ROOT` and `OMX_STATE_ROOT` unset and run `env -u OMX_ROOT -u OMX_STATE_ROOT`.\nClassify harness setup failures separately: record it as harness debris, fix the harness, and rerun the scenario before declaring a product defect.\n\n## Safety, state, and exit\n\nNo destructive commands, secret exfiltration, credential dumping, production writes, or unbounded process spawning. Use no unbounded waits; preserve unrelated dirty work. If a scenario is unsafe, record it blocked and the safe substitute. Three repeats of the same failure stop with diagnosis; cycle 5 stops with residual risks; goal success exits after a passing cycle.\n\nUse CLI-first lifecycle state and exact commands:\n\n```sh\nomx state write --input '{\"mode\":\"ultraqa\",\"active\":true,\"current_phase\":\"planning\",\"iteration\":1,\"started_at\":\"<now>\",\"scenario_matrix\":[]}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"current_phase\":\"qa\",\"iteration\":<cycle>,\"scenario_matrix\":\"<updated matrix path or summary>\"}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"current_phase\":\"adversarial-e2e\"}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"current_phase\":\"diagnose\"}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"current_phase\":\"fix\"}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"current_phase\":\"cleanup\"}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"active\":false,\"current_phase\":\"complete\",\"completed_at\":\"<now>\"}' --json\nomx state read --input '{\"mode\":\"ultraqa\"}' --json\nomx state clear --input '{\"mode\":\"ultraqa\"}' --json\n```\n\nOn completion, max cycles, same failure, safety boundary, or environment error, clean\nstate and temporary artifacts. Report cleanup status and clean temporary e2e harnesses.\nNever claim complete without current evidence.\n\n## Evidence/output contract\n\nReturn `# UltraQA Report` with: **Goal and success criteria** (including stop condition\nand safety bounds); **Scenario matrix** (all columns above); **Commands run** (exit code,\npurpose, timeout, key output); **Failures found** (root/user/safety impact); **Fixes\napplied** / **Fixes applied** (files, rationale, scenarios, regression evidence); **Cleanup and rollback**\n(artifacts/processes/worktree before/after); **Residual risks**; and **Evidence**\n(logs, harness output, screenshots/transcripts where relevant, rerun/flake evidence).\n\n## Exit condition\n\n`ULTRAQA COMPLETE: Goal met after N cycles` only follows a passing baseline plus\nadversarial matrix, clean artifacts, and complete evidence. Otherwise return the exact\nbounded status: `ULTRAQA STOPPED: Max cycles`, `ULTRAQA STOPPED: Same failure detected 3 times`,\n`ULTRAQA BLOCKED: ...`, or `ULTRAQA ERROR: ...` with owner and next safe step.\n","plugins/oh-my-codex/skills/visual-ralph/SKILL.md":"---\nname: visual-ralph\ndescription: \"Visual Ralph orchestration for frontend UI from generated references, static references, or live URL targets, using $ultragoal with built-in visual verdict and pixel-diff evidence until the implementation matches and leaves a reproducible design system.\"\n---\n\n# Visual Ralph Skill\n\nUse `$visual-ralph` for measured frontend implementation from an approved generated reference, static image, or live-URL baseline. The loop is:\n\n`description / URL -> approved reference -> $ultragoal implementation -> Visual Ralph verdict + pixel diff -> reusable design system`.\n\nFor URL cloning, this skill owns the migrated `$web-clone` use case; preserve URL, viewport, fidelity, and interaction notes here. Do not invoke standalone `$web-clone`.\n\nShared operating, delegation, state, hook, team, cancellation, and verification invariants live in [`templates/AGENTS.md`](../../templates/AGENTS.md). Follow that source instead of duplicating its rules here.\n\n## Use when\n\n- The user wants a web/app UI built or restyled against a visual target.\n- A live URL or generated raster mockup needs measured implementation and pixel-level iteration.\n- The result must leave reusable repo-native tokens/components, not only a matching screenshot.\n\nDo not use it for a durable `DESIGN.md` brief (`$design`), non-visual backend work, comparison-only fixes that can be executed directly, or deterministic SVG/code-native assets.\n\n## Workflow\n\n### 1. Ground the repository\n\nInspect package manager/scripts, frontend framework and routes, styling/token conventions, screenshot tooling, and reusable components. Choose stack-specific commands only when repository evidence supports them.\n\n### 2. Establish a reference\n\nFor a live URL, capture or document an artifact containing source URL and permission/scope, viewport(s), route/state, seed/login assumptions, baseline screenshot path or capture command, visible-control parity notes, and exclusions (backend/API/auth, personalized data, crawling, third-party widgets).\n\nFor a generated concept, use `$imagegen` with classification `ui-mockup`, viewport/aspect ratio, surface, layout hierarchy, typography, color mood, exact text, no logos/watermarks/unrequested marks, and readable/feasible UI details. In OMX runtime, queue the continuation checkpoint before the built-in image tool:\n\n```bash\nomx imagegen continuation <session-id> --artifact <slug-or-filename> --generated-dir \"$CODEX_HOME/generated_images/<session>\" --work-dir \".omx/artifacts/visual-ralph/<slug>\"\n```\n\nCopy the approved reference into `.omx/artifacts/visual-ralph/<slug>/reference.png`; do not leave it only under `$CODEX_HOME/generated_images`.\n\n### 3. Approval gate\n\nStop after generation or URL capture and obtain approval of one reference image/state (or a targeted regeneration/capture adjustment). Before approval, do not implement or invoke `$ultragoal`. After approval, the image/baseline is the visual source of truth; major pivots require an explicit user request.\n\n### 4. Hand off to `$ultragoal`\n\nPass the approved reference/baseline, URL and permission note when applicable, viewport/content state, interaction parity and exclusions, user description, detected frontend context, screenshot command/viewport, and the completion checklist. The active Ultragoal execution lane edits, runs, captures, and iterates after approval until matched or blocked.\n\n### 5. Verdict before every edit\n\nFor each iteration, capture the current screenshot with viewport/state, run Visual Ralph verdict (using `vision` when needed), and treat its JSON as authoritative. If `score < 90`, turn `differences[]` and `suggestions[]` into the next edit plan and rerun before editing. Required verdict keys: `score`, `verdict`, `category_match`, `differences[]`, `suggestions[]`, `reasoning`.\n\n### 6. Secondary diff evidence\n\nUse pixel diff/pixelmatch overlays only to locate hotspots and translate them into edits; they never replace the verdict. Record final reference, screenshot, and diff artifacts for auditability.\n\n### 7. Reusable design system\n\nEncode the match in existing repo-native CSS variables, theme tokens, config, component variants, stories, or `DESIGN.md` updates. Capture applicable colors, spacing, typography/weights, radii, shadows/elevation, and important variants/states. Extend existing patterns rather than adding a parallel layer.\n\n## Completion evidence and stop conditions\n\nDo not declare done until the approved reference/baseline and reproduction command (viewport, route, state, output path) are saved; final verdict is `>= 90`; secondary diff evidence is recorded; reusable tokens/components exist; equivalent build/lint/test verification passes; no unapproved pivot occurred; and remaining differences are documented. Stop at the approval gate or report a concrete blocker when evidence cannot satisfy these conditions.\n\n## Handoff template\n\n```text\n$ultragoal \"Implement the approved frontend reference.\nReference: <workspace reference or URL-derived artifact>\nSource URL and permission/scope: <when applicable>\nViewport/content state: <viewport, route/state, seed/login assumptions>\nInteraction parity and exclusions: <visible controls and known limits>\nRoute/surface: <route or component>\nScreenshot command: <command and viewport>\nRun Visual Ralph verdict before every next edit; pass threshold >= 90.\nUse pixel diff only as secondary evidence.\nExtract reusable tokens/components for colors, spacing, typography, radii, shadows, and variants.\nRun the repository's equivalent verification before completion.\nDo not make major design pivots unless explicitly requested.\"\n```\n\nTask: {{ARGUMENTS}}\n","plugins/oh-my-codex/skills/wiki/SKILL.md":"---\nname: wiki\ndescription: Persistent markdown project wiki stored under repository omx_wiki with keyword search and lifecycle capture\ntriggers: [\"wiki add\", \"wiki lint\", \"wiki query\", \"wiki read\", \"wiki delete\"]\n---\n\n# Wiki\n\nPersistent, self-maintained markdown knowledge base for project and session knowledge.\n\n## Operations\n\n### Ingest\n```bash\nomx wiki wiki_ingest --input '{\"title\":\"Auth Architecture\",\"content\":\"...\",\"tags\":[\"auth\",\"architecture\"],\"category\":\"architecture\"}' --json\n```\n\n### Query\n```bash\nomx wiki wiki_query --input '{\"query\":\"authentication\",\"tags\":[\"auth\"],\"category\":\"architecture\"}' --json\n```\n\n### Lint\n```bash\nomx wiki wiki_lint --json\n```\n\n### Quick Add\n```bash\nomx wiki wiki_add --input '{\"title\":\"Page Title\",\"content\":\"...\",\"tags\":[\"tag1\"],\"category\":\"decision\"}' --json\n```\n\n### List / Read / Delete\n```bash\nomx wiki wiki_list --json\nomx wiki wiki_read --input '{\"page\":\"auth-architecture\"}' --json\nomx wiki wiki_delete --input '{\"page\":\"outdated-page\"}' --json\nomx wiki wiki_refresh --json\n```\n\n## Categories\n`architecture`, `decision`, `pattern`, `debugging`, `environment`, `session-log`, `reference`, `convention`\n\n## Storage\n- Pages: `omx_wiki/*.md`\n- Index: `omx_wiki/index.md`\n- Log: `omx_wiki/log.md`\n\n## Cross-References\nUse `[[page-name]]` wiki-link syntax to create cross-references between pages.\n\n## Auto-Capture\nAt session end, discoveries can be captured as `session-log-*` pages. Configure via `wiki.autoCapture` in `.omx-config.json`.\n\n## Hard Constraints\n- No vector embeddings — query uses keyword + tag matching only\n- Wiki files are repository project knowledge under `omx_wiki/`; legacy `.omx/wiki/` is read-only compatibility input when no canonical wiki exists\n","plugins/oh-my-codex/skills/worker/SKILL.md":"---\nname: worker\ndescription: Team worker protocol (ACK, mailbox, task lifecycle) for tmux-based OMX teams\n---\n\n# Worker Skill\n\n## When to use\n\nUse only when the session was started as an OMX Team worker. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot` before acting; it defines the durable ownership and coordination boundaries.\n\n## Inputs and preconditions\n\n- Require `OMX_TEAM_WORKER=<team-name>/worker-<n>`.\n- Resolve this skill from the first existing path:\n `${CODEX_HOME:-~/.codex}/skills/worker/SKILL.md`, `~/.codex/skills/worker/SKILL.md`, `<leader_cwd>/.codex/skills/worker/SKILL.md`, then `<leader_cwd>/skills/worker/SKILL.md`.\n- Resolve the Team state root in this order: `OMX_TEAM_STATE_ROOT`, worker identity `team_state_root`, config/manifest `team_state_root`, local `.omx/state`.\n\n## Operational steps\n\n1. Split the environment into `teamName` and `workerName`; Send a startup ACK before task work:\n ```bash\n omx team api send-message --input '{\"team_name\":\"<teamName>\",\"from_worker\":\"<workerName>\",\"to_worker\":\"leader-fixed\",\"body\":\"ACK: <workerName> initialized\"}' --json\n ```\n2. Read `<team_state_root>/team/<teamName>/workers/<workerName>/inbox.md` and take the first unblocked assignment.\n3. Read `<team_state_root>/team/<teamName>/tasks/task-<id>.json`; APIs use the bare numeric `task_id` (for example `\"1\"`).\n4. Claim before editing:\n ```bash\n omx team api claim-task --input '{\"team_name\":\"<teamName>\",\"task_id\":\"<id>\",\"worker\":\"<workerName>\"}' --json\n ```\n5. Do the assigned work. Do not write task lifecycle fields directly.\n6. Complete or fail through the lifecycle API, from `in_progress` to `completed` or `failed`:\n ```bash\n omx team api transition-task-status --input '{\"team_name\":\"<teamName>\",\"task_id\":\"<id>\",\"from\":\"in_progress\",\"to\":\"completed\",\"claim_token\":\"<token>\",\"result\":\"<evidence>\"}' --json\n ```\n Use `release-task-claim` only to requeue a blocked task to `pending`.\n7. Check and acknowledge mailbox messages:\n ```bash\n omx team api mailbox-list --input '{\"team_name\":\"<teamName>\",\"worker\":\"<workerName>\"}' --json\n omx team api mailbox-mark-delivered --input '{\"team_name\":\"<teamName>\",\"worker\":\"<workerName>\",\"message_id\":\"<MESSAGE_ID>\"}' --json\n ```\n8. Write idle status after the transition:\n `<team_state_root>/team/<teamName>/workers/<workerName>/status.json` with `{\"state\":\"idle\",\"updated_at\":\"<ISO timestamp>\"}`.\n\n## Exit and evidence\n\nCompletion evidence names the task id, changed artifacts, verification performed, and any blocker. ACKs, task transitions, mailbox acknowledgements, and status writes must be observable through the Team API/state files. On shutdown, follow the lead's inbox instructions and write the required shutdown acknowledgement before exiting.\n","plugins/oh-my-codex/templates/AGENTS.md":"<!-- AUTONOMY DIRECTIVE — DO NOT REMOVE -->\nYOU ARE AN AUTONOMOUS CODING AGENT. EXECUTE TASKS TO COMPLETION WITHOUT ASKING FOR PERMISSION.\nDO NOT STOP TO ASK \"SHOULD I PROCEED?\" — PROCEED. DO NOT WAIT FOR CONFIRMATION ON OBVIOUS NEXT STEPS.\nIF BLOCKED, TRY AN ALTERNATIVE APPROACH. ONLY ASK WHEN TRULY AMBIGUOUS OR DESTRUCTIVE.\nUSE CODEX NATIVE SUBAGENTS FOR INDEPENDENT PARALLEL SUBTASKS WHEN THAT IMPROVES THROUGHPUT. THIS IS COMPLEMENTARY TO OMX TEAM MODE.\n<!-- END AUTONOMY DIRECTIVE -->\n\n# oh-my-codex - Intelligent Multi-Agent Orchestration\n\nYou are running with oh-my-codex (OMX), a coordination layer for Codex CLI.\nThis AGENTS.md is the top-level operating contract for the workspace.\nRole prompts under `prompts/*.md` are narrower execution surfaces. They must follow this file, not override it.\nWhen OMX is installed, load the installed prompt/skill/agent surfaces from `~/.codex/prompts`, `~/.codex/skills`, and `~/.codex/agents` (or the project-local `./.codex/...` equivalents when project scope is active).\n\n<guidance_schema_contract>\nCanonical guidance schema for this template is defined in `docs/guidance-schema.md`.\nKeep runtime marker contracts stable and non-destructive when overlays are applied:\n- `<!-- OMX:RUNTIME:START --> ... <!-- OMX:RUNTIME:END -->`\n- `<!-- OMX:TEAM:WORKER:START --> ... <!-- OMX:TEAM:WORKER:END -->`\n</guidance_schema_contract>\n\n<operating_principles>\n- Solve the task directly when you can do so safely and well.\n- Delegate only when it materially improves quality, speed, or correctness.\n- Keep progress short, concrete, and useful.\n- Prefer evidence over assumption; verify before claiming completion.\n- Check official documentation before implementing with unfamiliar SDKs, frameworks, or APIs.\n- Within one Codex session or team pane, use Codex native subagents for independent, bounded subtasks when that improves throughput.\n<!-- OMX:GUIDANCE:OPERATING:START -->\n- Default to outcome-first, quality-focused responses: identify the user's target result, success criteria, constraints, available evidence, expected output, and stop condition before adding process detail.\n- Keep collaboration style short and direct. Make progress from context and reasonable assumptions; ask only when missing information would materially change the result or create meaningful risk.\n- Start multi-step or tool-heavy work with a concise visible preamble that acknowledges the request and names the first step; keep later updates brief and evidence-based.\n- Proceed automatically on clear, low-risk, reversible next steps; ask only for irreversible, credential-gated, external-production, destructive, or materially scope-changing actions.\n- AUTO-CONTINUE for clear, already-requested, low-risk, reversible, local edit-test-verify work; keep inspecting, editing, testing, and verifying without permission handoff.\n- ASK only for destructive, irreversible, credential-gated, external-production, or materially scope-changing actions, or when missing authority blocks progress.\n- On AUTO-CONTINUE branches, do not use permission-handoff phrasing; state the next action or evidence-backed result.\n- Keep going unless blocked; finish the current safe branch before asking for confirmation or handoff.\n- Ask only when blocked by missing information, missing authority, or an irreversible/destructive branch.\n- Use absolute language only for true invariants: safety, security, side-effect boundaries, required output fields, workflow state transitions, and product contracts.\n- Do not ask or instruct humans to perform ordinary non-destructive, reversible actions; execute those safe reversible OMX/runtime operations and ordinary commands yourself.\n- Treat OMX runtime manipulation, state transitions, and ordinary command execution as agent responsibilities when they are safe and reversible.\n- Treat newer user task updates as local overrides for the active task while preserving earlier non-conflicting instructions.\n- When the user provides newer same-thread evidence (for example logs, stack traces, or test output), treat it as the current source of truth, re-evaluate earlier hypotheses against it, and do not anchor on older evidence unless the user reaffirms it.\n- Persist with retrieval, inspection, diagnostics, tests, or tool use only while they materially improve correctness, required citations, validation, or safe execution; stop once the core request is answerable with sufficient evidence.\n- More effort does not mean reflexive web/tool escalation; re-evaluate low/medium effort and the smallest useful tool loop before escalating reasoning or retrieval.\n<!-- OMX:GUIDANCE:OPERATING:END -->\n</operating_principles>\n\n## Working agreements\n- For cleanup/refactor/deslop work, write a cleanup plan and lock behavior with regression tests before editing when coverage is missing.\n- Prefer deletion, existing utilities, and existing patterns before new abstractions; add dependencies only when explicitly requested.\n- Keep diffs small, reviewable, and reversible.\n- Verify with lint, typecheck, tests, and static analysis after changes; final reports include changed files, simplifications, and remaining risks.\n\n\n<delegation_rules>\nChoose the lane before acting:\n- Solo execute by default when scope is clear: work directly. The ordinary workflow is `understand -> execute -> verify -> report`.\n- Use `$autopilot` for explicit hands-off orchestration. Its defining default chain is `$deep-interview -> $ralplan -> $ultragoal`; these supervised stages must not be hollowed into optional hints.\n- Use `$deep-interview` when requirements, intent, non-goals, or decision boundaries are materially ambiguous; it is the independent Ouroboros-style Socratic deep interview stage before planning.\n- Use `$plan` for lightweight planning when a deep interview is unnecessary.\n- Use `$team` when an approved plan needs coordinated parallel execution across multiple lanes.\n- Use `$ultragoal` for durable multi-goal runs with checkpoint/resume semantics.\n- Outside active `team`/`swarm` mode, use `executor` for bounded implementation or review slices; do not invoke `worker` as a general-purpose role.\n- Reserve `worker` strictly for active `team`/`swarm` sessions where the team runtime assigns a worker lane.\n- `worker` is a team-runtime surface, not a general-purpose child role.\n- Stages may also be invoked independently when their input contract is satisfied. `$deep-interview` is not `$plan --interview`.\n\n\nUse Codex native subagents for bounded implementation, research, review, or verification slices when they materially improve quality, speed, or safety. Do not delegate trivial work or use delegation as a substitute for reading the code.\n- Under ordinary native support with inherited permissions, native children may implement, mutate, and report bounded delegated work directly: reporting back through the native result surface is ordinary completion, not a separate authority grant, and local state, task text, session fields, trackers, or child provenance remain routing/diagnostic data, never a substitute for real sandbox, approval, cross-session ownership, or privileged-operation boundaries. Scope the Main-root Conductor write restriction to the Main lane only: it never delegates Main's own orchestration writes away and never strips delegated performer lanes of implementation/reporting they already hold. Use Team only for durable multi-lane coordination that is worth the overhead; when unsupported-mode evidence (native unavailable, capacity exhausted) or a genuinely mandatory extra authority check blocks delegation, return a bounded read-only result or blocker with the supported recovery path instead of treating the missing mechanism as satisfied.\n</delegation_rules>\n\n<child_agent_protocol>\nLeader responsibilities: choose the mode, delegate bounded verifiable subtasks, integrate results, and own final verification.\nWorker responsibilities: execute the assigned slice, stay inside scope, and report blockers, shared-file conflicts, scope expansion, or recommended handoffs upward; child prompts should report recommended handoffs upward rather than recursively orchestrating.\nLeader vs worker: leaders own mode selection, integration, verification, and stop/escalate calls; workers execute assigned slices and escalate from worker to leader for blockers, shared-file conflicts, scope expansion, missing authority, or mode mismatch.\nRules: max 6 concurrent child agents; child prompts remain under AGENTS.md authority; prefer inherited model defaults unless a task has a concrete model reason; `worker` is a team-runtime surface, not a general-purpose child role.\n</child_agent_protocol>\n\n\n<invocation_conventions>\n- `$name` — invoke a workflow skill.\n- `/skills` — browse available skills.\n- Prefer explicit skill invocation for deterministic workflow routing.\n</invocation_conventions>\n\n<model_routing>\nMatch role to task shape: `explore` for repo lookup, `researcher` for official docs/reference gathering, `dependency-expert` for SDK/package decisions, `executor` for implementation, `debugger` for root cause, `architect`/`critic` for high-complexity review. Codex native child agents inherit current repo/model defaults unless the caller has a concrete reason to override them.\n</model_routing>\n\n<specialist_routing>\nLeader/workflow routing contract:\n<!-- OMX:GUIDANCE:SPECIALIST-ROUTING:START -->\n- Route to `explore` for repo-local file / symbol / pattern / relationship lookup, current implementation discovery, or mapping how this repo currently uses a dependency. `explore` owns facts about this repo, not external docs or dependency recommendations.\n- Route to `researcher` when the main need is official docs, external API behavior, version-aware framework guidance, release-note history, or citation-backed reference gathering. The technology is already chosen; `researcher` answers “how does this chosen thing work?” and is not the default dependency-comparison role.\n- Route to `dependency-expert` when the main need is package / SDK selection or a comparative dependency decision: whether / which package, SDK, or framework to adopt, upgrade, replace, or migrate; candidate comparison; maintenance, license, security, or risk evaluation across options.\n- Use mixed routing deliberately: `explore` -> `researcher` for current local usage plus official-doc confirmation; `explore` -> `dependency-expert` for current dependency usage plus upgrade / replacement / migration evaluation; `researcher` -> `explore` when docs are clear but repo usage or impact still needs confirmation; `dependency-expert` -> `explore` when a dependency decision is clear but the local migration surface still needs mapping.\n- Specialists should report boundary crossings upward instead of silently absorbing adjacent work.\n- When external evidence materially affects the answer, do not keep the leader in the main lane on recall alone; route to the relevant specialist first, then return to planning or execution.\n<!-- OMX:GUIDANCE:SPECIALIST-ROUTING:END -->\n</specialist_routing>\n\n<agent_catalog>\nKey roles: `explore`, `researcher`, `dependency-expert`, `planner`, `architect`, `debugger`, `executor`, `test-engineer`, `verifier`, and `critic`. Use the installed role catalog for full descriptions.\n</agent_catalog>\n\n<keyword_detection>\nKeyword routing is implemented primarily by native `UserPromptSubmit` hooks and the generated keyword registry. Treat hook-injected routing context as authoritative for the current turn, then load the named `SKILL.md` or prompt file as instructed.\n\nFallback behavior when hook context is unavailable:\n- Explicit `$name` invocations run left-to-right and override implicit keywords.\n- Bare skill names do not activate skills by themselves; skill-name activation requires explicit `$skill` invocation. Natural-language routing phrases may still map to a workflow. Examples: `analyze` / `investigate` → `$analyze` for read-only deep analysis with ranked synthesis, explicit confidence, and concrete file references.\n- Keep the detailed keyword list in `src/hooks/keyword-registry.ts`; do not duplicate it here.\n\nRuntime workflows such as `autopilot`, `ultraqa`, `team`, and `ultragoal` require OMX CLI runtime support. In Codex App, outside-tmux, or plain Codex sessions without OMX tmux runtime, explain that those workflows are not directly available there and continue with the nearest App-safe surface unless the user explicitly wants to launch OMX CLI from shell first.\n- Route explicit `$autopilot` to its supervised `$deep-interview -> $ralplan -> $ultragoal` chain.\n- `$ralph`, `$ultrawork`, `$pipeline`, `ecomode`, and `swarm` remain removed or deprecated sunset stubs; do not route users there.\n- When deep-interview is active in attached-tmux OMX CLI/runtime, ask each interview round via `omx question`; after launching `omx question` in a background terminal, wait for that terminal to finish and read the JSON answer before continuing; preserve the leader pane with `OMX_QUESTION_RETURN_PANE=$TMUX_PANE` when invoking it through Bash/tool paths. Outside tmux or native surfaces that cannot render `omx question` should use the native structured question path when available; otherwise ask exactly one concise plain-text question and wait for the answer.\n\n</keyword_detection>\n\n<skills>\nSkills are workflow commands. Always load the relevant installed `SKILL.md` before following a skill-specific process. Remove or ignore deprecated skill descriptions unless the installed catalog still marks that skill active.\n</skills>\n\n<team_compositions>\nUse explicit team orchestration for feature development, bug investigation, code review, UX audit, and similar multi-lane work when coordination value outweighs overhead.\n</team_compositions>\n\n<team_pipeline>\nTeam mode is the structured multi-agent surface. Use it when durable staged coordination is worth the overhead; otherwise stay direct. Terminal states: `complete`, `failed`, `cancelled`.\n</team_pipeline>\n\n<team_model_resolution>\nTeam/Swarm worker model precedence: explicit `OMX_TEAM_WORKER_LAUNCH_ARGS`, inherited leader `--model`, then low-complexity default from `OMX_DEFAULT_SPARK_MODEL` (legacy alias: `OMX_SPARK_MODEL`). Normalize model flags to one canonical `--model <value>` entry and use `OMX_DEFAULT_FRONTIER_MODEL` / `OMX_DEFAULT_SPARK_MODEL` rather than guessing defaults.\n</team_model_resolution>\n\n<!-- OMX:MODELS:START -->\n<!-- Auto-generated by omx setup -->\n<!-- OMX:MODELS:END -->\n\n<verification>\nVerify before claiming completion.\n<!-- OMX:GUIDANCE:VERIFYSEQ:START -->\nVerification loop: define the claim and success criteria, run the smallest validation that can prove it, read the output, then report with evidence. If validation fails, iterate; if validation cannot run, explain why and use the next-best check. Keep evidence summaries concise but sufficient.\n\n- Run dependent tasks sequentially; verify prerequisites before starting downstream actions.\n- If a task update changes only the current branch of work, apply it locally and continue without reinterpreting unrelated standing instructions.\n- For coding work, prefer targeted tests for changed behavior, then typecheck/lint/build/smoke checks when applicable; do not claim completion without fresh evidence or an explicit validation gap.\n- When correctness depends on retrieval, diagnostics, tests, or other tools, continue only until the task is grounded and verified; avoid extra loops that only improve phrasing or gather nonessential evidence.\n<!-- OMX:GUIDANCE:VERIFYSEQ:END -->\n</verification>\n\n<execution_protocols>\nMode selection: follow `<delegation_rules>` above. Switch lanes only for a concrete unresolved ambiguity, coordination need, or blocker.\n\nCommand routing: use normal Codex repository inspection tools/subagents as the default surface for simple read-only repository lookup tasks; use `omx sparkshell` only for explicit shell-native read-only evidence or bounded verification.\nWhen to use what:\n- Use normal Codex repository inspection tools/subagents for repository lookup and implementation context.\n- Use `omx sparkshell --tmux-pane` only as an explicit opt-in operator aid for shell-native tmux evidence or bounded verification; it does not replace raw evidence capture.\n\nSupervisor tmux handoff safety:\n- Never paste from tmux's implicit/current buffer. Load handoff text into a fresh named buffer with `tmux set-buffer -b <name> -- \"$message\"` or a temp-file-backed `tmux load-buffer -b <name> <file>`; never use `tmux load-buffer -- <message>`.\n- Verify the named buffer with `tmux show-buffer -b <name>` before any paste. A failed load or mismatched buffer is a blocker; do not run `paste-buffer` or submit keys after it.\n- Clear the pane composer with `tmux send-keys -t <pane> C-u` immediately before paste, then use bracketed paste (`tmux paste-buffer -t <pane> -b <name> -p -d`) and submit intentionally.\n- Recapture the pane after paste/Enter and verify the intended turn was accepted rather than leaving stale draft text visible.\n\nLeader vs worker: leaders choose mode, delegate bounded work, integrate, and own verification; workers execute their slice and escalate blockers, scope expansion, shared-file conflicts, or mode mismatch upward. Escalate from worker to leader for blockers, scope expansion, shared ownership conflicts, or mode mismatch.\n\nStop / escalate: stop when the task is verified complete, the user says stop/cancel, or no meaningful recovery path remains. Escalate to the user only for irreversible, destructive, materially branching decisions, or missing authority.\n\nOutput contract: Default update/final shape: state current mode, action/result, and evidence or blocker/next step. Keep rationale once; do not restate the full plan every turn; expand only for risk, handoff, or explicit request.\n\nAnti-slop workflow:\n- Cleanup/refactor/deslop work follows the same lightweight workflow (`understand -> execute -> verify -> report`); use `$ai-slop-cleaner` as a bounded helper inside the chosen execution lane, not as a competing top-level workflow.\n- Write a cleanup plan before modifying code; lock existing behavior with regression tests first, then make one smell-focused pass at a time.\n- Prefer deletion over addition, and prefer reuse plus boundary repair over new layers.\n- No new dependencies without explicit request.\n- Run lint, typecheck, tests, and static analysis before claiming completion.\n- Keep writer/reviewer pass separation for cleanup plans and approvals; preserve writer/reviewer pass separation explicitly.\n\nContinuation: before concluding, confirm no pending work remains, features work, tests pass or gaps are explicit, and verification evidence is collected. If not, continue.\n</execution_protocols>\n\n<cancellation>\nUse the `cancel` skill to end active execution modes when work is done and verified, when the user says stop, or when a hard blocker prevents meaningful progress. Do not cancel while recoverable work remains.\n</cancellation>\n\n<state_management>\nSee [Durable Runtime Invariants](#durable-runtime-invariants-canonical-ssot) for state ownership and hook boundaries. OMX runtime state lives under `.omx/`.\n</state_management>\n\n## Durable Runtime Invariants (canonical SSOT)\n\nThis section is the single source of truth for durable state ownership, hook boundaries, cancellation, and Team coordination. Skills and role prompts reference it; they must not restate or weaken these rules.\n\n### State and hook ownership\n\n- Durable state is authoritative only in the current, proven session or Team scope. Compatibility discovery is read-only and never grants write authority.\n- Hooks own normal skill activation and workflow-state persistence under `.omx/state/`; skills do not duplicate or mutate hook-owned state except through documented recovery paths.\n- Native hook payloads, prompt labels, task text, cwd, environment, pointers, transcripts, markers, and local trackers are routing or diagnostic data, not ownership or write authority.\n- The Team state files and `omx team api ... --json` are the source of truth for task lifecycle and mailbox coordination.\n\n### Cancellation boundary\n\n- Cancellation parses and validates arguments before mutation, resolves one exact writable scope, freezes and revalidates target identity, mutates only proven targets, and leaves unrelated sessions, legacy roots, Team artifacts, and tmux sessions untouched.\n- Ralph cancellation must satisfy its documented terminal post-conditions in the same scope; linked modes are handled only when the link is proven.\n- `--force` does not widen cancellation scope; it only removes the selected exact-session native-stop entry after the same authority checks. `--all` is unsupported.\n- Team cancellation requires exact frozen Team root, internal name, session, leader pane, and runtime identity. It fails closed when that proof is unavailable or changes; it must not enumerate or broadly kill Team sessions or recursively delete unrelated Team state.\n\n### Team protocol\n\n- Team runtime is explicit and outside the default workflow. Ultragoal does not auto-launch Team, and ordinary workflows do not silently become Team runs.\n- Workers ACK startup, claim before work, transition task status through the lifecycle API, use release only for rollback, and report verification evidence. Leaders own integration, final verification, and shutdown decisions.\n- Prefer durable state writes and `omx team api ... --json` dispatch. Direct `tmux send-keys` is fallback-only, never primary dispatch; manual pane actions require prior state/evidence checks.\n- Team shutdown waits for terminal task state and uses exact Team authority. It does not shut down active work unless explicitly aborting.\n\n### Ultragoal ownership\n\n- `.omx/ultragoal/goals.json` is the leader-owned plan and `.omx/ultragoal/ledger.jsonl` is its durable audit trail. Workers report task evidence only; they do not create worker ledgers, mutate Ultragoal artifacts, or checkpoint goals.\n- Shell commands and hooks do not mutate hidden Codex goal state. The active agent uses `get_goal`, `create_goal`, and `update_goal` only at the documented gates, then checkpoints with a fresh `get_goal` snapshot.\n\n## Setup\n\nExecute `omx setup` to install all components. Execute `omx doctor` to verify installation.\n","skills/ai-slop-cleaner/SKILL.md":"---\nname: ai-slop-cleaner\ndescription: Run an anti-slop cleanup/refactor/deslop workflow\n---\n\n# AI Slop Cleaner Task Card\n\nUse this bounded helper for cleanup/refactor/deslop work, not as a competing top-level\nworkflow. Shared operating invariants live in `templates/AGENTS.md`; this card defines\nscope, smell taxonomy, passes, and evidence.\n\n## When to use and inputs\n\nUse when working code is bloated, noisy, repetitive, over-abstracted, or AI-generated;\nthe user requests cleanup/refactor/deslop; or a follow-up left duplicate/dead code,\nweak boundaries, missing tests, fallback-like paths, or wrappers. Inputs are the requested\nfeature/files and behavior to preserve. A file list scope is valid; keep the pass bounded\nto it. Limit the pass to the calling task's changed files unless broader cleanup was requested.\n\n## Before editing\n\n1. **Lock behavior with regression tests first**: identify behavior to preserve, run/add the narrowest targeted tests, and cover both primary and preserved compatibility/fail-safe fallback paths.\n2. **Create a cleanup plan before code**: list scope and smells, include fallback findings/classifications/escalation, and order safest/highest-signal fixes first.\n3. **Inventory fallback-like code** in scope: quick hacks, temporary workaround, temporary fallback, just bypass, just skip, fallback if it fails, swallowed errors, silent defaults, broad compatibility shims, and duplicate alternate execution paths.\n4. Classify each fallback: **Masking fallback slop** hides evidence, bypasses the contract, suppresses validation, swallows failures, silently defaults, or adds untested paths; **Grounded compatibility/fail-safe fallback** is narrow at an external/version/fail-safe boundary, documents rationale, preserves failure evidence, and tests primary plus fallback.\n5. Prefer root-cause repair, deletion, boundary repair, or explicit failure behavior. For broad/ambiguous/cross-layer/architectural findings, invoke `$ralplan` for consensus resolution; when already inside ralplan, ultragoal, team, or another OMX workflow, do not spawn a nested `$ralplan`—attach the finding to the active handoff.\n\n## Smell taxonomy and passes\n\nClassify before changing:\n\n- **Fallback-like code**: masking fallbacks, workaround branches, bypasses, swallowed errors, silent defaults, broad shims, alternate paths.\n- **Duplication**: repeated logic, copy-paste branches, redundant helpers.\n- **Dead code**: unused/unreachable code, stale flags, debug leftovers.\n- **Needless abstraction**: pass-through wrappers, speculative indirection, single-use layers.\n- **Boundary violations**: hidden coupling, leaky responsibilities, wrong-layer imports/side effects.\n- **Missing tests**: behavior not locked or edge cases uncovered.\n- **UI/design slop**: context-sensitive signals, not absolute bans; preserve intentional brand, design-system, accessibility, or product-context exceptions. Challenge Korean body text at 11-12px (generally 14px or larger); gratuitous box shadows; repetitive eyebrow + title + description + paragraph stacks and generic emoji badges; default AI blue/purple such as `#3B82F6`; reflexive 3-column or 4-column grids; and extreme gradients unless justified by context.\n\nResolve the fallback-like code resolution gate first, then one smell at a time:\n**Pass 1: Dead code deletion**; **Pass 2: Duplicate removal**; **Pass 3: Naming/error\nhandling cleanup**; **Pass 4: Test reinforcement**. Re-run targeted verification after\neach pass and avoid unrelated refactors. Prefer deletion/existing utilities; no new\nabstractions or dependencies unless explicitly required.\n\n## Evidence/output contract\n\nReport:\n\n```text\nAI SLOP CLEANUP REPORT\nScope: [files/feature]\nBehavior Lock: [targeted tests added/run]\nCleanup Plan: [bounded smells/order]\nFallback Findings: [finding -> masking fallback slop | grounded compatibility/fail-safe fallback -> escalation]\nUI/Design Findings: [none/N/A or signal -> action/defer -> intentional rationale]\nPasses Completed: [resolution gate; Passes 1-4]\nQuality Gates: Regression tests, Lint, Typecheck, Tests, Static/security scan (PASS/FAIL/N/A)\nChanged Files: [path -> simplification]\nRemaining Risks: [none or deferred item]\n```\n\nInclude changed files, simplifications, fallback classifications/escalation status,\ntests/diagnostics/build checks run, UI findings when relevant, and deferred risks. Keep\nwriter/reviewer separation for cleanup plans and approvals.\n\n## Exit condition\n\nStop when the requested scope has behavior-lock evidence, each selected smell pass is\ncomplete or explicitly deferred with rationale, verification is reported, and no\nunrelated files or temporary artifacts remain. Never present an unverified cleanup as\ncomplete; escalate a real architectural blocker rather than masking it.\n","skills/analyze/SKILL.md":"---\nname: analyze\ndescription: \"Run read-only deep repository analysis and return a ranked synthesis with explicit confidence, concrete file references, and clear evidence-vs-inference boundaries. Use when a user says 'analyze', 'investigate', 'why does', 'what's causing', or needs grounded cross-file explanation before any changes are proposed.\"\n---\n\n# Analyze — Read-Only Deep Analysis\n\nUse `$analyze` to answer a repository question with grounded, read-only evidence. Explain what the code most likely says; do not turn analysis into implementation or generic fix planning.\n\nShared operating, delegation, state, hook, team, cancellation, and verification invariants live in [`templates/AGENTS.md`](../../templates/AGENTS.md). Follow that source instead of duplicating its rules here.\n\n## Use when\n\n- The user needs a causal, architectural, behavioral, impact, or tradeoff explanation.\n- The answer requires tracing multiple files or boundaries, or ranking plausible explanations.\n- The user needs confidence and concrete evidence before changing anything.\n\nDo not use it for edits, implementation, a new product plan, a simple one-file lookup, or OMX team-runtime operation.\n\n## Inputs and method\n\n1. Restate the question and define the evidence-backed scope.\n2. Identify the smallest files, tests, configs, and docs likely to answer it.\n3. Read direct code paths and contracts first; trace boundaries only as far as needed.\n4. Compare competing explanations, rank them by support, and mark unresolved points.\n5. Stop when the question is answered with sufficient evidence, or name the smallest read-only probe that would resolve the remaining uncertainty.\n\n## Evidence discipline\n\nLabel every material claim as one of:\n\n- **Evidence** — directly shown by code, tests, generated artifacts, configuration, or docs.\n- **Inference** — a reasoned conclusion drawn from cited evidence.\n- **Unknown** — not settled by the repository evidence.\n\nPrefer direct paths and independent corroboration over contextual clues. Never present guesses as evidence or inference, and never overclaim certainty.\n\n## Output contract\n\nAnswer the asked question first and use this shape:\n\n### Question\nRestated question, briefly.\n\n### Ranked synthesis\n| Rank | Explanation | Confidence | Basis |\n|------|-------------|------------|-------|\n| 1 | ... | High / Medium / Low | strongest supporting evidence |\n| 2 | ... | High / Medium / Low | why it trails |\n| 3 | ... | High / Medium / Low | why it remains possible |\n\n### Evidence\n- `path/to/file:line-line` — direct observation.\n- `path/to/file:line-line` — corroborating observation.\n\n### Inference\n- What the evidence most strongly implies.\n- Why weaker alternatives were down-ranked.\n\n### Unknowns / limits\n- What the repository does not establish.\n- The next discriminating read-only probe, when useful.\n\n## Stop conditions\n\n- Do not edit files, run an implementation lane, or make recommendations the evidence cannot support.\n- Do not continue searching after the answer and confidence boundary are grounded.\n- If evidence is insufficient, report the limit explicitly rather than manufacturing certainty.\n\nTask: {{ARGUMENTS}}\n","skills/ask/SKILL.md":"---\nname: ask\ndescription: Ask a local external advisor CLI (Claude or Gemini) and capture a reusable artifact\n---\n\n# Ask (Local Advisor CLI)\n\nUse a locally installed external advisor CLI for focused questions, reviews, brainstorming, or second opinions. This skill replaces the separate `ask-claude` and `ask-gemini` skills.\n\n## Usage\n\n```bash\n$ask claude <question or task>\n$ask gemini <question or task>\nomx ask claude \"<question or task>\"\nomx ask gemini \"<question or task>\"\n```\n\n## Backend selection\n\n- Use `claude` when the user asks for Claude, Anthropic, or the previous `$ask-claude` behavior.\n- Use `gemini` when the user asks for Gemini or the previous `$ask-gemini` behavior.\n- If no backend is specified, choose the installed backend that best matches the user request; if neither is clearly available, explain that a local CLI is required.\n\n## Local CLI commands\n\nClaude:\n\n```bash\nomx ask claude \"{{ARGUMENTS}}\"\nclaude -p \"{{ARGUMENTS}}\"\n```\n\nGemini:\n\n```bash\nomx ask gemini \"{{ARGUMENTS}}\"\ngemini -p \"{{ARGUMENTS}}\"\n```\n\nIf needed, adapt to the user's installed CLI variant while keeping local execution as the default path. Do not silently switch to an MCP or remote provider when the local binary is missing.\n\n## Artifact requirement\n\nAfter local execution, save a markdown artifact to:\n\n```text\n.omx/artifacts/ask-<backend>-<slug>-<timestamp>.md\n```\n\nMinimum artifact sections:\n1. Original user task\n2. Backend and final prompt sent to the CLI\n3. Raw CLI output\n4. Concise summary\n5. Action items / next steps\n\nTask: {{ARGUMENTS}}\n","skills/autopilot/SKILL.md":"---\nname: autopilot\ndescription: \"[OMX] Canonical autonomous orchestrator: $deep-interview -> $ralplan -> $ultragoal\"\n---\n\n# Autopilot\n\n<Purpose>\nAutopilot is the first-class canonical orchestrator for hands-off delivery. Its defining default chain is mandatory:\n\n```text\n$deep-interview -> $ralplan -> $ultragoal\n```\n\nThe chain is not a list of optional hints and Autopilot is not an alias for direct execution. Autopilot supervises each child stage in one recoverable session, carries durable artifacts forward, and continues through implementation verification until the requested outcome is complete or a genuine blocker is recorded.\n</Purpose>\n\n<Use_When>\n- The user explicitly invokes `$autopilot`.\n- The user asks for end-to-end autonomous delivery from an idea, issue, or requirements seed.\n- The work needs requirements clarification, consensus planning, durable execution, and evidence-backed completion as one supervised workflow.\n</Use_When>\n\n<Default_Chain>\nRun or resume these stages in order:\n\n1. **`deep-interview`** — clarify intent, scope, non-goals, constraints, acceptance criteria, and unresolved decisions. Produce a durable requirements/specification handoff. Deep Interview is a real stage; do not replace it with a one-question check or skip it merely because the task looks actionable.\n2. **`ralplan`** — turn the clarified requirements into an execution-ready consensus plan with architecture, sequencing, test, and verification guidance. Preserve review evidence as lifecycle evidence, not host-issued security authority.\n3. **`ultragoal`** — execute the approved plan through durable goals and ledger receipts, implementation, focused verification, cleanup, review, and terminal evidence.\n\n`$team`, `$code-review`, and `$ultraqa` may be used inside the supervised execution when the active Ultragoal plan or verification boundary requires them. They do not replace or weaken the defining three-stage chain.\n\nWhen review or QA proves the requirements or plan wrong, keep Autopilot active, return its supervised phase to `ralplan`, attach the findings, and continue through `ultragoal` again. Implementation-only review fixes may remain within Ultragoal's blocker/review loop.\n</Default_Chain>\n\n<Execution_Policy>\n- Autopilot MUST begin at `deep-interview` for a new run and MUST preserve the phase order `deep-interview -> ralplan -> ultragoal`.\n- Child stages are supervised phases, not peer workflow activations. Keep `mode:\"autopilot\"` active and update `current_phase` rather than replacing Autopilot with standalone child state.\n- Use the current CLI state SSOT (`omx state ... --json`) and the current session-scoped state root. Do not create a second writer or revive legacy root-state authority.\n- Local artifacts, prompts, trackers, transcripts, environment values, and role labels are lifecycle evidence only. Do not reintroduce the retired unrecoverable host-receipt lock or terminalize the workflow because host provenance is unavailable.\n- Authority-decreasing operations are always recoverable: `$cancel`, state clear, hook disable/uninstall recovery, and stale-state repair must remain available without completion receipts or child-stage approval.\n- Continue automatically through safe, reversible stage transitions. Stop only for an explicit user cancellation, a human-only dependency, or a verified terminal result.\n</Execution_Policy>\n\n<State_Management>\nAutopilot state is session-scoped and owned by the canonical state writer. A new run records at least:\n\n```json\n{\n \"mode\": \"autopilot\",\n \"active\": true,\n \"current_phase\": \"deep-interview\",\n \"iteration\": 1,\n \"phase_cycle\": [\"deep-interview\", \"ralplan\", \"ultragoal\"],\n \"handoff_artifacts\": {\n \"deep_interview\": null,\n \"ralplan\": null,\n \"ultragoal\": null\n },\n \"return_to_ralplan_reason\": null\n}\n```\n\nStart or update state only through the CLI-first state surface:\n\n```bash\nomx state write --input '{\"mode\":\"autopilot\",\"active\":true,\"current_phase\":\"deep-interview\",\"state\":{\"phase_cycle\":[\"deep-interview\",\"ralplan\",\"ultragoal\"],\"handoff_artifacts\":{\"deep_interview\":null,\"ralplan\":null,\"ultragoal\":null},\"return_to_ralplan_reason\":null}}' --json\n```\n\nStage transitions:\n\n- **`deep-interview -> ralplan`**: require a durable clarified requirements/specification artifact and a non-empty completion rationale. Preserve same-session question evidence when a question surface was used.\n- **`ralplan -> ultragoal`**: require durable planning artifacts, sequential Architect then Critic approvals, and a session/review-cycle-bound `ralplan_execution_handoff`. For supervised Autopilot, the explicit Autopilot request is the source of that bound handoff. Ordinary progression MUST NOT depend on a host-issued consensus receipt; missing host provenance is not a blocker.\n- **`ultragoal -> complete`**: require durable goal/ledger completion receipts and fresh verification evidence matching the requested outcome.\n- **review/QA loopback**: keep Autopilot active, set `current_phase:\"ralplan\"`, and persist `return_to_ralplan_reason` plus the findings.\n- **cancellation**: run `$cancel`; preserve handoff artifacts for inspection or resume and mark the exact session terminal without deleting unrelated state.\n- **clear/recovery**: exact-session clear may remove corrupt or stale Autopilot state. It must not require forward-progression evidence and must not clear other skills or sessions.\n</State_Management>\n\n<Continuation_And_Resume>\nWhen the user says `continue`, `resume`, or `keep going`, read the current session's `autopilot-state.json` and continue from `current_phase`:\n\n- `deep-interview`: resume clarification and produce the requirements handoff.\n- `ralplan`: resume consensus planning from the deep-interview artifact and any loopback findings.\n- `ultragoal`: resume durable execution from the approved plan and ledger.\n- `complete`: report the terminal evidence; do not restart.\n- `cancelled`, `cleared`, or `failed`: report preserved artifacts and start a new run only on a new explicit Autopilot request.\n\nNever discard valid handoff artifacts or restart discovery merely because the conversation resumed.\n</Continuation_And_Resume>\n\n<Recovery_Contract>\nAutopilot continuation hooks may nudge an active non-terminal run, but they MUST fail open for recovery:\n\n- A stale, malformed, cancelled, cleared, complete, or foreign-session state must not keep Stop blocked.\n- `$cancel`, exact-session state clear, and setup hook disable/uninstall paths must remain executable while Autopilot is active or damaged.\n- Continuation must be bounded and session-scoped; never recreate an unconditional hook lock.\n</Recovery_Contract>\n\n<Final_Checklist>\n- [ ] A new run started with `deep-interview`.\n- [ ] Deep Interview produced a durable clarified requirements/specification handoff.\n- [ ] Ralplan produced an execution-ready plan with lifecycle review evidence.\n- [ ] Ultragoal completed the plan with durable goals and ledger receipts.\n- [ ] Verification evidence covers the requested behavior, failure paths, and recovery paths.\n- [ ] Missing host provenance did not block ordinary progression, cancel, clear, or hook recovery.\n- [ ] Autopilot state is terminal and exact-session artifacts remain coherent.\n</Final_Checklist>\n\n<Examples>\n<Good>\nUser: `$autopilot implement issue #42`\nFlow: activate Autopilot at `deep-interview`, crystallize requirements, continue to supervised `ralplan`, then supervised `ultragoal`, verify the completed outcome, and mark the exact session complete.\n</Good>\n\n<Good>\nUser: `continue`\nContext: Autopilot state has `current_phase:\"ralplan\"`.\nFlow: resume the existing plan from the deep-interview handoff; do not create a separate standalone Ralplan run.\n</Good>\n\n<Bad>\nFlow: treat `$deep-interview`, `$ralplan`, and `$ultragoal` as optional suggestions and jump directly to implementation.\nWhy bad: this hollows out Autopilot's defining orchestration contract.\n</Bad>\n</Examples>\n\nTask: {{ARGUMENTS}}\n","skills/autoresearch-goal/SKILL.md":"---\nname: autoresearch-goal\ndescription: Sunset stub — use $autoresearch instead\n---\n\n# Autoresearch-goal — removed\n\n`$autoresearch-goal` was removed in OMX 0.21; use `$autoresearch` instead.\n\nAutoresearch-goal was a duplicate research-over-goal-mode entry point. `$autoresearch` is the single canonical validator-gated research loop; it owns the research mission lifecycle that autoresearch-goal duplicated.\n\nMigration: replace `$autoresearch-goal` with `$autoresearch`.\n\nTask: {{ARGUMENTS}}\n","skills/autoresearch/SKILL.md":"---\nname: autoresearch\ndescription: Stateful validator-gated research loop with native-hook persistence\n---\n\n# Autoresearch\n\nAutoresearch is the skill-first replacement for the deprecated `omx autoresearch` command.\nIt keeps the useful measured-research loop, but it now runs as a native-hook stateful workflow instead of a direct CLI or tmux launch surface.\n\n## Boundary with planning research\n\nUse `$autoresearch` when the research output itself is a bounded deliverable that must pass an explicit validator. Do not recommend it for ordinary pre-planning docs lookup or general best-practice checks; use `$best-practice-research` for that. If `$autoresearch` is intentionally run before architecture planning, its approved artifact should feed evidence into `$ralplan`; it should not become a final architecture/component unless the user explicitly asks for ongoing research automation.\n\n## Use when\n- You want a Ralph-ish persistent research loop\n- The task should keep nudging until explicit validation evidence exists\n- You want init-time choice between script validation and prompt+architect validation\n\n## Do not use when\n- You want the old `omx autoresearch` command surface (hard-deprecated)\n- You want detached tmux or split-pane launch parity\n- You have not decided the validation regime yet\n\n## Core contract\n1. **Init chooses validation mode.** Pick exactly one:\n - `mission-validator-script`\n - `prompt-architect-artifact`\n2. **Persist mode state** in `.omx/state/.../autoresearch-state.json` including:\n - `validation_mode`\n - `completion_artifact_path`\n - `mission_validator_command` **or** `validator_prompt`\n - optional `output_artifact_path`\n3. **Completion is artifact-gated.** The loop does not stop because the model says “done”, because a stop hook fired once, or because several turns were no-ops.\n4. **Direct CLI launch is gone.** Use `$deep-interview --autoresearch` for intake and `$autoresearch` for execution.\n\n## Completion artifact contract\n\n### `mission-validator-script`\nThe completion artifact must exist and record a passing validator result, for example:\n\n```json\n{\n \"status\": \"passed\",\n \"passed\": true,\n \"summary\": \"metric improved beyond baseline\"\n}\n```\n\n### `prompt-architect-artifact`\nThe completion artifact must include both an architect approval verdict and an output artifact path, for example:\n\n```json\n{\n \"validator_prompt\": \"Review the research output against the mission.\",\n \"architect_review\": { \"verdict\": \"approved\" },\n \"output_artifact_path\": \".omx/specs/autoresearch-demo/report.md\"\n}\n```\n\n## Recommended flow\n1. Run `$deep-interview --autoresearch` to clarify mission + evaluator.\n2. Materialize `.omx/specs/autoresearch-{slug}/mission.md`, `sandbox.md`, and `result.json`.\n3. Start `$autoresearch` with the chosen validation mode stored in mode state.\n4. Let stop-hook / auto-nudge continue until the completion artifact satisfies the chosen validation mode.\n5. Finish only after the validator artifact is complete.\n\n## Migration note\n- `omx autoresearch` is hard-deprecated.\n- No direct CLI launch.\n- No tmux split-pane launch.\n- No noop-count completion gate.\n","skills/best-practice-research/SKILL.md":"---\nname: best-practice-research\ndescription: \"[OMX] Bounded best-practice research wrapper using official/upstream evidence first\"\nargument-hint: \"<technology|decision|practice question>\"\n---\n\n# Best-Practice Research\n\nUse this skill when a task depends on current external best practices, version-aware guidance, standards, official recommendations, or upstream behavior. This is a workflow wrapper: it routes evidence gathering and synthesis; it is not a new research authority and it does not replace `researcher`.\n\n## Purpose\n\nProduce a cited, reusable best-practice answer or handoff that separates current external evidence from repo-local facts and dependency-selection decisions. For pre-planning investigation, this is the ordinary first research wrapper: gather official/upstream evidence, then hand it to `$ralplan` or the caller as planning input. Do not present `$best-practice-research` as a final architecture component or as a validator-gated research loop.\n\n## Terminal By Default\n\nThis skill is terminal and read-only by default. It gathers evidence and produces a cited recommendation with a handoff, then stops. Do not write or edit files, create or amend commits, run mutating commands, or otherwise modify repository state under this skill — even when the question has clear implementation implications. When implementation is warranted, stop and hand off rather than continuing: name `$ralplan` for planning and `$ultragoal`, `$team`, or `executor` for execution, and resume only after the user explicitly switches to that workflow.\n\n## Activate When\n\n- The user asks for best practices, recommended approach, current guidance, official recommendations, standards, or version-aware external behavior.\n- `$ralplan`, `$deep-interview`, `$team`, or another workflow needs current external evidence before planning or execution can be correct.\n- The task involves an already chosen technology and needs authoritative usage guidance, migration notes, API behavior, lifecycle rules, or current safety guidance.\n\n## Do Not Activate When\n\n- The answer is fully repo-local; use `explore` for codebase facts.\n- The main question is whether to adopt, replace, upgrade, or compare dependencies; use `dependency-expert`.\n- The user only needs implementation against already-grounded requirements; execute directly, or use `$team` when coordinated parallel work is warranted.\n- The task can be answered from stable local project conventions without current external lookup.\n\n## Specialist Routing\n\n1. Use `explore` first for brownfield facts: current code usage, local constraints, versions, config, and integration points.\n2. Use `researcher` for official/upstream docs, release notes, standards, migration guides, source-backed examples, and current best-practice evidence for an already chosen technology.\n3. Use `dependency-expert` only for adoption/upgrade/replacement/comparison decisions.\n4. Return to the caller with explicit evidence, uncertainty, and any implementation handoff constraints.\n\n## Source-Quality Rules\n\n- Prefer official documentation, upstream source, release notes, changelogs, standards, and maintainer guidance.\n- Include source URLs for material claims.\n- State date/version context for current best-practice claims.\n- Label third-party summaries as supplemental; do not use them before official/upstream sources.\n- Flag stale, conflicting, undocumented, or version-mismatched evidence.\n- Do not over-fetch: gather the smallest evidence set that can support the decision.\n\n## Workflow\n\n1. Classify the question: conceptual best practice, implementation guidance, migration/version guidance, standards/compliance guidance, or mixed local + external guidance.\n2. Gather repo-local facts with `explore` when local usage or constraints affect the answer.\n3. Gather external evidence with `researcher` when current or version-aware practice affects correctness.\n4. Synthesize a concise answer with source quality, version/date context, caveats, and an implementation or planning handoff.\n5. Stop when the answer is grounded enough for the caller; otherwise report the exact blocker or specialist handoff needed.\n\n## Output Contract\n\n```md\n## Best-Practice Research: <question>\n\n### Direct Recommendation\n<actionable guidance or decision support>\n\n### Evidence Used\n- Official/upstream: <source URL> — <what it establishes>\n- Supplemental, if any: <source URL> — <why it is secondary>\n\n### Version / Date Context\n<versions, dates, release channels, or unknowns>\n\n### Repo-Local Context\n<facts from explore, or \"not needed\">\n\n### Boundaries / Non-goals\n<what this research does not decide>\n\n### Handoff\n<planning/execution/test implications; name the next workflow — `$ralplan` for planning, `$ultragoal`/`$team`/`executor` for execution — and note that this skill stops here unless the user explicitly switches workflows>\n```\n\n## Stop Rules\n\n- Stop after a source-backed recommendation is reusable by the caller.\n- Stop and route upward if the task becomes dependency comparison, broad architecture, or implementation.\n- Do not continue researching when remaining work would only polish wording rather than change the recommendation.\n- This skill never implements. After delivering the recommendation and handoff, stop; do not modify repo files or repo state. Resume only when the user explicitly switches to a planning or implementation workflow named in the handoff.\n\nTask: {{ARGUMENTS}}\n","skills/cancel/SKILL.md":"---\nname: cancel\ndescription: Cancel any active OMX mode (autopilot, ralph, ultrawork, ecomode, ultraqa, swarm, ultrapilot, pipeline, team)\n---\n\n# Cancel Skill\n\n## When to use\n\nUse `/cancel` (or `cancelomc` / `stopomc`) to stop an active OMX mode and perform its documented cleanup. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot` first; it is the invariant authority for scope, ownership, hooks, and Team cleanup.\n\n## Inputs and preconditions\n\n- Accepted forms are `/cancel` and `/cancel --force`.\n- Reject `--all`, unknown flags, repeated flags, and mixed flags before mutation.\n- Discover the current session/root with the state read surfaces before cleanup:\n ```bash\n omx state list-active --json\n omx state get-status --mode <mode> --json\n ```\n- Confirm the current session/root and exact target before cleanup; stop when the required evidence is missing.\n\n## Operational steps\n\n1. Parse and validate arguments; select one exact session/root scope.\n2. Inspect active modes in dependency order:\n `autopilot → ralph → ultrawork → ecomode → ultraqa → swarm → ultrapilot → pipeline → team → plan-consensus`.\n3. Cancel Autopilot while preserving its resumable state; clean only linked child modes it owns.\n4. For Ralph, terminalize the target state (`active:false`, `current_phase:\"cancelled\"`, `completed_at`) and terminalize a proven linked Ultrawork/Ecomode state in the same scope. Confirm the post-conditions in `docs/contracts/ralph-cancel-contract.md`.\n5. Clear standalone modes only after proving they are not linked to another active mode.\n6. For Team, inspect the runtime with `omx team status <team> --json`; use `omx team shutdown <team>` after the normal completion gate, or follow the explicit abort path.\n7. Clear only the selected mode/session state through the state API, for example:\n ```bash\n omx state clear --input '{\"mode\":\"<mode>\",\"session_id\":\"<session>\"}' --json\n ```\n8. With `--force`, perform its documented native-stop cleanup. Report rollback or cleanup failures rather than claiming success.\n\n## Exit and evidence\n\nReport one result per selected mode: mode, scope/session, terminal phase, preserved state, linked cleanup, and any refusal reason. A clean no-op reports `No active OMX modes detected.` Include Team status and shutdown evidence when Team was selected.\n","skills/code-review/SKILL.md":"---\nname: code-review\ndescription: Run a comprehensive code review\n---\n\n# Code Review Task Card\n\nUse this explicit opt-in for a merge-readiness review. Shared operating invariants\nlive in `templates/AGENTS.md`; this card only defines review-specific behavior.\n\n## When to use\n\n- The user asks for a code review or quality/security assessment.\n- A change is ready for review before merge, or a major feature needs an independent review.\n- Do not activate this card for implementation, broad planning, or automatic cleanup.\n\n## Inputs\n\n- Scope: the requested files, commit, PR, or whole diff.\n- Requirements/specification, acceptance criteria, and relevant test/CI evidence.\n- Existing review artifacts and known risks, if any.\n- If the user says `continue`, advance the current verified review step rather than restarting discovery.\n\nStart by recording the scope:\n\n```sh\ngit status --short\ngit diff --stat\ngit diff -- <scope>\n```\n\n## Execution\n\n1. Identify changed files and review boundaries; do not silently widen the scope.\n2. Launch the `code-reviewer` and `architect` agents in parallel. Both lanes run in parallel on a clean context with explicit scope and artifacts. If either lane cannot be launched or does not return evidence, report `independent review unavailable`; do **not** substitute the current/authoring lane, and do **not** approve or mark the review merge-ready.\n3. Respect the user's current model and reasoning/effort selection. Do not pass `model` or `reasoning_effort` overrides in review-lane calls.\n\n```text\ntask(\n agent_type=\"code-reviewer\",\n prompt=\"CODE REVIEW TASK\n\nReview the supplied scope for spec compliance, security, quality, performance, and maintainability.\nReturn files reviewed, severity-rated findings with file:line evidence and concrete fixes,\nand a recommendation: APPROVE / REQUEST CHANGES / COMMENT. Do not review architecture.\nScope: [scope and artifacts]\"\n)\n\ntask(\n agent_type=\"architect\",\n prompt=\"ARCHITECTURE / DEVIL'S-ADVOCATE REVIEW TASK\n\nReview the same scope for boundaries, interfaces, hidden coupling, long-term tradeoffs,\nand the strongest counterargument against approval. Return file:line evidence,\nrecommendations, and Architectural Status: CLEAR / WATCH / BLOCK.\nScope: [scope and artifacts]\"\n)\n```\n\n## Review taxonomy\n\n- `code-reviewer` checks **Security**, **Code Quality**, **Performance**, **Best Practices**, and **Maintainability**.\n- Rate each finding: **CRITICAL** (security or data-loss blocker), **HIGH** (bug/major smell), **MEDIUM** (important improvement), or **LOW** (style/suggestion).\n- `architect` checks explicit boundaries/interfaces, hidden coupling, long-horizon tradeoffs, and devil's-advocate concerns. Status is **CLEAR**, **WATCH** (non-blocking concern), or **BLOCK** (merge blocker).\n- Every finding names `file:line`, issue, risk, and a concrete fix; distinguish facts from suggestions.\n\n## State/HUD Phase Contract\n\n- Standalone `$code-review` relies on hook-owned `skill-active-state.json` (`skill:\"code-review\"`, `phase:\"planning\"`); do not create `code-review-state.json`.\n- Inside Autopilot, keep `mode:\"autopilot\"` active with `current_phase:\"code-review\"` / skill-active `phase:\"code-review\"`; do not activate a peer workflow.\n- On clean review, persist the artifact under Autopilot `handoff_artifacts.code_review` before moving to `ultraqa`. On non-clean review, persist findings and use `rework` or `ralplan` as appropriate.\n\n```sh\nomx state write --input '{\"mode\":\"autopilot\",\"active\":true,\"current_phase\":\"code-review\"}' --json\n```\n\n## Final Synthesis and gate\n\n### Architectural Status Contract\n\nCombine the `code-reviewer` recommendation and architect status. Approval requires explicit evidence from both independent lanes; missing or failed delegation is a blocking unavailable-review state, not an approval fallback. The final report must make architect blockers impossible to miss.\n\n- If architect status is **BLOCK**, final recommendation is **REQUEST CHANGES**.\n- Else if `code-reviewer` recommendation is **REQUEST CHANGES**, final recommendation is **REQUEST CHANGES**.\n- Else if architect status is **WATCH**, final recommendation is **COMMENT**.\n- Else final recommendation follows the `code-reviewer` lane.\n\nApproval criteria: **APPROVE** only when `code-reviewer` returns APPROVE, architect status is `CLEAR`, and both independent lanes returned evidence. **REQUEST CHANGES** for a blocker, unresolved high/critical finding, or unavailable lane. **COMMENT** may record non-blocking findings.\n\nDo not self-review as a fallback. If the `code-reviewer` or `architect` path is missing, unavailable, skipped, or fails, block approval until independent lane evidence exists. On the supported `omx ralph` CLI compatibility path, findings may trigger automatic fix follow-up without another permission prompt; plain `code-review` itself remains read-only and does **not** promise auto-fix.\n\n## Evidence/output contract\n\nReturn a concise report containing:\n\n```text\nCODE REVIEW REPORT\nFiles Reviewed: <count>\nTotal Issues: 0\nArchitectural Status: CLEAR | WATCH | BLOCK\nCRITICAL (0) | HIGH (0) | MEDIUM (0) | LOW (0)\nFindings: file:line -> issue, risk, concrete fix (or none)\nARCHITECTURE WATCHLIST: concern, status, recommendation (or none)\n- code-reviewer recommendation: COMMENT\n- architect status: WATCH\n- final recommendation: COMMENT\nRECOMMENDATION: COMMENT\n```\n\nReplace the illustrative counts and verdict with observed values. Include scope,\nlane evidence/artifact references, unresolved risks, and validation gaps.\n\n## Exit condition\n\nStop when the scoped diff has two independent lane results and a deterministic final\nrecommendation. Report `APPROVE` only under the approval criteria; otherwise leave a\nbounded `REQUEST CHANGES`, `COMMENT`, or unavailable-review result. Never claim\nmerge-ready without the required evidence.\n","skills/configure-notifications/SKILL.md":"---\nname: configure-notifications\ndescription: Configure OMX notifications - unified entry point for all platforms\ntriggers:\n - \"configure notifications\"\n - \"setup notifications\"\n - \"notification settings\"\n - \"configure discord\"\n - \"configure telegram\"\n - \"configure slack\"\n - \"configure openclaw\"\n - \"setup discord\"\n - \"setup telegram\"\n - \"setup slack\"\n - \"setup openclaw\"\n - \"discord notifications\"\n - \"telegram notifications\"\n - \"slack notifications\"\n - \"openclaw notifications\"\n - \"discord webhook\"\n - \"telegram bot\"\n - \"slack webhook\"\n---\n\n# Configure OMX Notifications\n\nUse this card for Discord, Telegram, Slack, generic command aliases, or OpenClaw. Shared safety, lifecycle, hook, team, autonomy, and cancellation rules live in `templates/AGENTS.md`.\n\n## 1. Inspect and choose a path\n\n```bash\nCONFIG_FILE=\"$HOME/.codex/.omx-config.json\"\nif [ -f \"$CONFIG_FILE\" ]; then\n jq -r '{notifications_enabled:(.notifications.enabled // false), discord:(.notifications.discord.enabled // false), discord_bot:(.notifications[\"discord-bot\"].enabled // false), telegram:(.notifications.telegram.enabled // false), slack:(.notifications.slack.enabled // false), openclaw:(.notifications.openclaw.enabled // false), custom_webhook_command:(.notifications.custom_webhook_command.enabled // false), custom_cli_command:(.notifications.custom_cli_command.enabled // false), verbosity:(.notifications.verbosity // \"session\"), idleCooldownSeconds:(.notifications.idleCooldownSeconds // 60), reply_enabled:(.notifications.reply.enabled // false)}' \"$CONFIG_FILE\"\nelse\n echo \"NO_CONFIG_FILE\"\nfi\n```\n\nUse AskUserQuestion to choose: Discord native (webhook or bot), Telegram native (bot token + chat id), Slack native (incoming webhook), `custom_webhook_command`, `custom_cli_command`, cross-cutting settings, or disable all notifications.\n\n## 2. Native providers\n\nCollect and validate provider values, then write only these native keys: `notifications.discord`, `notifications[\"discord-bot\"]`, `notifications.telegram`, or `notifications.slack`. Do not represent native providers with generic aliases.\n\n## 3. Generic aliases\n\nFor `custom_webhook_command`, collect URL, optional headers, method (`POST` default or `PUT`), events (`session-end`, `ask-user-question`, `session-start`, `session-idle`, `stop`), and an instruction template:\n\n```bash\njq --arg url \"$URL\" --arg method \"${METHOD:-POST}\" --arg instruction \"${INSTRUCTION:-OMX event {{event}} for {{projectPath}}}\" --argjson headers \"${HEADERS_JSON:-{}}\" '.notifications=(.notifications//{enabled:true})|.notifications.enabled=true|.notifications.custom_webhook_command={enabled:true,url:$url,headers:$headers,method:$method,instruction:$instruction,events:[\"session-end\",\"ask-user-question\"]}' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\nFor `custom_cli_command`, collect a command template (`{{event}}`, `{{instruction}}`, `{{sessionId}}`, `{{projectPath}}`), optional events, and an instruction template:\n\n```bash\njq --arg command \"$COMMAND_TEMPLATE\" --arg instruction \"${INSTRUCTION:-OMX event {{event}} for {{projectPath}}}\" '.notifications=(.notifications//{enabled:true})|.notifications.enabled=true|.notifications.custom_cli_command={enabled:true,command:$command,instruction:$instruction,events:[\"session-end\",\"ask-user-question\"]}' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\nOpenClaw dispatch requires `OMX_OPENCLAW=1`; command gateways additionally require `OMX_OPENCLAW_COMMAND=1`; timeout precedence is `gateways.<name>.timeout` > `OMX_OPENCLAW_COMMAND_TIMEOUT_MS` > `5000` ms.\n\n## 4. OpenClaw + Clawdbot agent mode\n\nUse this only when the requested route is a `clawdbot agent` turn delivered to Discord. The `session-stop` notification intentionally maps to the OpenClaw `stop` hook. OMX shell-escapes substitutions; keep instructions short, avoid untrusted shell metacharacters, append `|| true`, and append JSONL logs with `>>`.\n\n```bash\njq --arg command \"(clawdbot agent --session-id omx-hooks --message {{instruction}} --thinking minimal --deliver --reply-channel discord --reply-to 'channel:CHANNEL_ID' --timeout 120 --json >>/tmp/omx-openclaw-agent.jsonl 2>&1 || true)\" '.notifications=(.notifications//{enabled:true})|.notifications.enabled=true|.notifications.verbosity=\"verbose\"|.notifications.openclaw={enabled:true,gateways:{local:{type:\"command\",command:$command,timeout:120000}},hooks:{\"session-start\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-start project={{projectName}} session={{sessionId}} tmux={{tmuxSession}}. 한국어로 상태를 #omc-dev에 공유하고 SOUL.md를 참고하세요.\"},\"session-idle\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-idle session={{sessionId}} tmux={{tmuxSession}}. 한국어로 팔로업을 #omc-dev에 안내하세요.\"},\"ask-user-question\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=ask-user-question session={{sessionId}} tmux={{tmuxSession}} question={{question}}. 한국어로 응답 필요를 #omc-dev에 알리세요.\"},\"stop\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-stop session={{sessionId}} tmux={{tmuxSession}}. 한국어로 중단 상태를 전달하세요.\"},\"session-end\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-end session={{sessionId}} tmux={{tmuxSession}} reason={{reason}}. 한국어로 완료 요약을 #omc-dev에 남기세요.\"}}}' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\n### Compatibility + precedence contract\n\nExplicit `notifications.openclaw` wins when valid; generic aliases are ignored with a warning.\n\nVerify this mode and inspect evidence without hiding output:\n\n```bash\nclawdbot agent --session-id omx-hooks --message \"OMX hook test via clawdbot agent path\" --thinking minimal --deliver --reply-channel discord --reply-to 'channel:CHANNEL_ID' --timeout 120 --json\ntmux list-sessions -F '#{session_name}' | rg '^omx-' || true\njq '.notifications.openclaw.hooks' \"$CONFIG_FILE\"\ntail -n 120 /tmp/omx-openclaw-agent.jsonl | jq -s '.[] | {timestamp:(.timestamp // .time),status:(.status // .error // \"ok\")}'\nrg '\"error\"|\"failed\"|\"timeout\"' /tmp/omx-openclaw-agent.jsonl | tail -20\n```\n\nFor HTTP integrations, run both a `/hooks/wake` smoke test and `/hooks/agent` delivery verification.\n\n## 5. Cross-cutting settings and disable\n\n- Verbosity: `minimal`, `session` (recommended), `agent`, or `verbose`.\n- Idle cooldown: `notifications.idleCooldownSeconds` (environment override: `OMX_IDLE_COOLDOWN_SECONDS`).\n- Profiles: `notifications.profiles` and `notifications.defaultProfile`.\n- Reply listener: `notifications.reply.enabled`; gates are `OMX_REPLY_ENABLED=true` and, for Discord, `OMX_REPLY_DISCORD_USER_IDS=...`. An authorized Discord bot operator may exact-match `status` on a tracked notification for a bounded read-only session summary.\n\nDisable all notifications:\n\n```bash\njq '.notifications.enabled=false' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\n## Exit evidence\n\nRun `jq empty \"$CONFIG_FILE\"` after edits. Report the config path, enabled native providers, enabled aliases, whether valid `notifications.openclaw` overrides aliases, verbosity, idle cooldown, reply-listener state, and smoke-test results. Stop when the JSON parses and the selected path has its required evidence; do not claim delivery from configuration alone.\n","skills/deep-interview/SKILL.md":"---\nname: deep-interview\ndescription: Socratic deep interview with mathematical ambiguity gating before execution\nargument-hint: \"[--quick|--standard|--deep] [--autoresearch] <idea or vague description>\"\n---\n\n<Purpose>\nDeep Interview is an intent-first Socratic clarification loop before planning or implementation. It turns vague ideas into execution-ready specifications by asking targeted questions about why the user wants a change, how far it should go, what should stay out of scope, and what OMX may decide without confirmation.\n</Purpose>\n\n<Use_When>\n- The request is broad, ambiguous, or missing concrete acceptance criteria\n- The user says \"deep interview\", \"interview me\", \"ask me everything\", \"don't assume\", or \"ouroboros\"\n- The user wants to avoid misaligned implementation from underspecified requirements\n- You need a requirements artifact before handing off to `ralplan`, `autopilot`, `ultragoal`, or `team`\n</Use_When>\n\n<Do_Not_Use_When>\n- The request already has concrete file/symbol targets and clear acceptance criteria\n- The user explicitly asks to skip planning/interview and execute immediately\n- The user asks for lightweight brainstorming only (use `plan` instead)\n- A complete PRD/plan already exists and execution should start\n</Do_Not_Use_When>\n\n<Why_This_Exists>\nExecution quality is usually bottlenecked by intent clarity, not just missing implementation detail. A single expansion pass often misses why the user wants a change, where the scope should stop, which tradeoffs are unacceptable, and which decisions still require user approval. This workflow applies Socratic pressure + quantitative ambiguity scoring so orchestration modes begin with an explicit, testable, intent-aligned spec.\n</Why_This_Exists>\n\n<Depth_Profiles>\n- **Quick (`--quick`)**: fast pre-PRD pass; target threshold `<= 0.30`; max rounds 5\n- **Standard (`--standard`, default)**: full requirement interview; target threshold `<= 0.20`; max rounds 12\n- **Deep (`--deep`)**: high-rigor exploration; target threshold `<= 0.15`; max rounds 20\n- **Autoresearch (`--autoresearch`)**: same interview rigor as Standard, but specialized for `$autoresearch` mission readiness and `.omx/specs/` artifact handoff\n\nProfile `max rounds` is a hard cap, not a target. Do not continue only to reach a numbered round count. Extra Socratic rigor does not override the active threshold unless the profile/config changes.\n\nIf no flag is provided, use **Standard**.\n\n<Mode_Flags>\n- **`--autoresearch`**: switch the interview into autoresearch-intake mode for `$autoresearch` handoff. In this mode, the interview should converge on a validator-ready research mission, write canonical artifacts under `.omx/specs/`, and preserve the explicit `refine further` vs `launch` boundary for downstream skill intake.\n</Mode_Flags>\n</Depth_Profiles>\n\n<Execution_Policy>\n- Ask ONE question per round (never batch multiple interview rounds into one `questions[]` form)\n- Ask about intent and boundaries before implementation detail\n- Target the weakest clarity dimension each round after applying the stage-priority rules below\n- Treat every answer as a claim to pressure-test before moving on: the next question should usually demand evidence or examples, expose a hidden assumption, force a tradeoff or boundary, or reframe root cause vs symptom\n- Do not rotate to a new clarity dimension just for coverage when the current answer is still vague; stay on the same thread until one layer deeper, one assumption clearer, or one boundary tighter\n- Before crystallizing, complete at least one explicit pressure pass that revisits an earlier answer with a deeper, assumption-focused, or tradeoff-focused follow-up\n- Gather codebase facts via `explore` before asking user about internals\n- `omx explore` is deprecated. Use normal repository inspection tools/subagents for simple read-only brownfield fact gathering; use `omx sparkshell` only for explicit shell-native read-only evidence, and keep ambiguous or non-shell-only investigation on the richer normal path.\n- Always run a preflight context intake before the first interview question\n- For brownfield work, preflight must include doc/context grounding before user-facing questions: inspect applicable `AGENTS.md` files, README/getting-started docs, relevant `docs/` contracts/plans/ADRs, existing `.omx/context/` snapshots, and any project-local glossary/context files such as `CONTEXT.md` or `CONTEXT-MAP.md` when present.\n- Treat existing repo language as evidence, not authority: if the user uses a fuzzy, overloaded, or conflicting term, surface the specific doc/code wording and ask which meaning should govern before implementation.\n- Cross-check user claims about current behavior against code or documented contracts when discoverable. If docs and code disagree, ask a confirmation question that names both sources instead of silently choosing one.\n- Use scenario-based edge-case grilling when relationships, boundaries, or handoff behavior are unclear: invent one concrete scenario that stresses the ambiguous boundary, then ask one focused question about the expected outcome.\n- Durable docs, glossary, ADR, or memory updates are opt-in and public-safe only. Deep-interview may recommend such updates in the handoff summary, but must not automatically create or dump public docs from interview transcripts unless the user explicitly chooses that as in-scope.\n- If initial context is oversized or would exceed the prompt budget, do not paste or forward the raw payload into interview prompts; request and record a prompt-safe initial-context summary first\n- The oversized initial-context summary gate is blocking: wait for the concise summary before ambiguity scoring, crystallizing artifacts, or any downstream execution handoff\n- The summary must preserve goals, constraints, success criteria, non-goals, decision boundaries, and references to any full source documents so downstream consumers receive a prompt-safe but faithful context\n- Keep total prompt payloads within a safe budget by summarizing or trimming retained history; preserve newest/highest-signal answers and never let raw oversized context crowd out the current question\n- Reduce user effort: ask only the highest-leverage unresolved question, and never ask the user for codebase facts that can be discovered directly\n- For brownfield work, prefer evidence-backed confirmation questions such as \"I found X in Y. Should this change follow that pattern?\"\n- Route facts before judgment in the Ouroboros style: before presenting a user-facing interview round, classify whether the needed information is a discoverable fact, a fact needing confirmation, or a human decision. The interview is with the human for judgment, not for facts the agent can inspect.\n- When unresolved ambiguity depends on current external best practices, official/upstream guidance, standards, or version-aware behavior, use `$best-practice-research` as the bounded evidence wrapper before crystallizing requirements or handing off to planning/execution.\n- Use these transcript/spec labels only; never use them as `omx question` `source` values, and never replace the runtime `source: \"deep-interview\"` contract for user-facing deep-interview questions:\n - `[from-code][auto-confirmed]` — exact, high-confidence codebase facts from manifests/configs or direct source evidence, with no prescription attached.\n - `[from-code]` — codebase findings that are useful but inferred, pattern-based, or low/medium confidence and therefore need a confirmation-style user-facing round before being treated as settled.\n - `[from-research]` — externally sourced facts such as API limits, compatibility, or public documentation; facts only, not decisions.\n - `[from-user]` — goals, preferences, business logic, scope, non-goals, acceptance criteria, tradeoffs, and any decision-bearing interpretation.\n- Treat `[from-code][auto-confirmed]` and other non-user fact discoveries as context/transcript updates, not interview rounds: do not call `omx question`, do not create a pending deep-interview question obligation, and do not increment the user-facing round number for facts the agent can safely establish.\n- Auto-confirm only descriptive facts. If a finding implies what the new feature should do, which pattern it should follow, which tradeoff to accept, or what should stay in/out of scope, route the entire decision-bearing question to the user as `[from-user]` even when code or research facts are available.\n- In attached-tmux Codex CLI, deep-interview uses `omx question` as the required OMX-owned structured questioning path for every interview round\n- When invoking `omx question` through attached-tmux Bash/tool paths, preserve the leader-pane return target by prefixing the command with `OMX_QUESTION_RETURN_PANE=$TMUX_PANE` (or a concrete `%pane` value)\n- If you launch `omx question` in a background terminal, immediately wait for that background terminal to finish and read its JSON answer before scoring ambiguity, asking another round, or handing off\n- Treat `answers[]` as the primary `omx question` success contract. For a single interview round, read `answers[0].answer`; use legacy top-level `answer` only as a compatibility fallback when needed.\n- If the current runtime is outside tmux and cannot render `omx question`, use the native structured question tool when available; otherwise ask exactly one concise plain-text question and wait for the answer\n- Re-score ambiguity after each answer and show progress transparently\n- Once ambiguity is at or below the active profile threshold, stop ordinary questioning. Run the practical closure audit: crystallize/handoff when readiness gates pass; otherwise ask only the final closure question needed to satisfy a named gate.\n- Treat `max_rounds` as a stop cap, not evidence that more rounds are needed.\n- Do not hand off to execution while ambiguity remains above threshold unless user explicitly opts to proceed with warning\n- Do not crystallize or hand off while `Non-goals` or `Decision Boundaries` remain unresolved, even if the weighted ambiguity threshold is met\n- Treat early exit as a safety valve, not the default success path\n- Persist mode state for resume safety only through the CLI/programmatic single-writer authority (`omx state write/read --input '<json>' --json`, backed by `src/state/operations.ts`). The MCP state server is a read-only projection and must never become a second writer.\n</Execution_Policy>\n\n<Steps>\n\n## Phase 0: Preflight Context Intake\n\n1. Parse `{{ARGUMENTS}}` and derive a short task slug.\n2. Attempt to load the latest relevant context snapshot from `.omx/context/{slug}-*.md`.\n3. Check whether the provided initial context or loaded snapshot is too large for safe prompt use. If it is oversized, the first interview round must ask for a concise prompt-safe summary instead of scoring ambiguity or continuing to downstream handoff.\n4. If no snapshot exists, create a minimum context snapshot with:\n - Task statement\n - Desired outcome\n - Stated solution (what the user asked for)\n - Probable intent hypothesis (why they likely want it)\n - Known facts/evidence\n - Constraints\n - Unknowns/open questions\n - Decision-boundary unknowns\n - Likely codebase touchpoints\n - Relevant repo docs/rules/context inspected\n - Terminology or doc/code conflicts found\n - Prompt-safe initial-context summary status (`not_needed`, `needed`, or `recorded`)\n5. For brownfield tasks, inspect the applicable documentation/rule surface before the first user-facing round. Prefer exact, nearby sources over broad scans:\n - governing `AGENTS.md` files and template/runtime instruction surfaces that apply to the touched paths\n - README/getting-started docs and relevant docs under `docs/`, especially contracts, plans, ADR-like records, and workflow docs\n - existing `.omx/context/` snapshots, `.omx/specs/`, and planning artifacts relevant to the slug\n - project-local glossary/context files such as `CONTEXT.md`, `CONTEXT-MAP.md`, or context-specific docs when they exist\n6. Save snapshot to `.omx/context/{slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`) and reference it in mode state.\n\n## Phase 1: Initialize\n\n1. Parse `{{ARGUMENTS}}` and depth profile (`--quick|--standard|--deep`).\n2. Detect project context:\n - Run `explore` to classify **brownfield** (existing codebase target) vs **greenfield**.\n - For brownfield, collect relevant codebase context before questioning.\n3. Initialize state via `omx state write --input '{\"mode\":\"deep-interview\",\"active\":true}' --json`:\n\n```json\n{\n \"active\": true,\n \"current_phase\": \"deep-interview\",\n \"state\": {\n \"interview_id\": \"<uuid>\",\n \"profile\": \"quick|standard|deep\",\n \"type\": \"greenfield|brownfield\",\n \"initial_idea\": \"<user input>\",\n \"rounds\": [],\n \"current_ambiguity\": 1.0,\n \"threshold\": 0.3,\n \"max_rounds\": 5,\n \"challenge_modes_used\": [],\n \"codebase_context\": null,\n \"current_stage\": \"intent-first\",\n \"current_focus\": \"intent\",\n \"context_snapshot_path\": \".omx/context/<slug>-<timestamp>.md\"\n }\n}\n```\n\n4. Announce kickoff with profile, threshold, and current ambiguity.\n\n## Phase 2: Socratic Interview Loop\n\nRepeat until ambiguity `<= threshold`, the pressure pass is complete, the readiness gates are explicit, the user exits with warning, or max rounds are reached. This is a stop condition: below threshold, do not open a new ordinary interview branch.\n\n### 2a) Generate next question\nIf the initial context is oversized and no prompt-safe summary has been recorded yet, the next question must be only a summary request. Do not score ambiguity, do not run readiness gates, and do not hand off to `$ultragoal`, `$ralplan`, `$autopilot`, or `$team` until that summary answer is captured.\n\nUse:\n- Original idea\n- Prior Q&A rounds\n- Current dimension scores\n- Brownfield context (if any)\n- Doc/context grounding notes, including existing terminology, governing rules, and any doc/code mismatch\n- Activated challenge mode injection (Phase 3)\n\nTarget the lowest-scoring dimension, but respect stage priority:\n- **Stage 1 — Intent-first:** Intent, Outcome, Scope, Non-goals, Decision Boundaries\n- **Stage 2 — Feasibility:** Constraints, Success Criteria\n- **Stage 3 — Brownfield grounding:** Context Clarity (brownfield only)\n\nFollow-up pressure ladder after each answer:\n1. Ask for a concrete example, counterexample, or evidence signal behind the latest claim\n2. Probe the hidden assumption, dependency, or belief that makes the claim true\n3. Force a boundary or tradeoff: what would you explicitly not do, defer, or reject?\n4. Challenge fuzzy or conflicting terms against the repo's documented language and current code behavior\n5. Stress-test the boundary with one concrete scenario or edge case when a relationship or handoff remains ambiguous\n6. If the answer still describes symptoms, reframe toward essence / root cause before moving on\n\nPrefer staying on the same thread for multiple rounds when it has the highest leverage. Breadth without pressure is not progress.\n\nMaintain a **Breadth Ledger** across independent ambiguity tracks: scope, constraints, outputs, verification, brownfield integration, and any user-mentioned deliverable tracks. The ledger is a guard, not a mandatory rotation rule: stay deep on the current thread until it has been pressure-tested, then zoom out only when another material track remains unresolved and would change execution.\n\nMaintain a **Docs/Terminology Ledger** for brownfield interviews:\n- repo docs/rules/context sources inspected, with path references\n- canonical terms already used by the repo and terms to avoid or disambiguate\n- user terms that conflict with docs or current code behavior\n- doc/code mismatches that require a human decision before implementation\n- optional durable-doc follow-ups that are safe to propose but not auto-apply\n\nDetailed dimensions:\n- Intent Clarity — why the user wants this\n- Outcome Clarity — what end state they want\n- Scope Clarity — how far the change should go\n- Constraint Clarity — technical or business limits that must hold\n- Success Criteria Clarity — how completion will be judged\n- Context Clarity — existing codebase understanding (brownfield only)\n\n`Non-goals` and `Decision Boundaries` are mandatory readiness gates. Ask about them early and keep revisiting them until they are explicit.\n\n### 2b) Ask the question\nUse the surface-appropriate structured questioning path for every interview round. In attached-tmux sessions, use OMX-owned structured questioning via `omx question` (this is the required structured-question equivalent and required `AskUserQuestion` equivalent for deep-interview). Outside tmux, use native structured input when available; otherwise ask exactly one concise plain-text question and wait for the answer. Present:\n\n```\nRound {n} | Target: {weakest_dimension} | Ambiguity: {score}%\n\n{question}\n```\n\n`omx question` payload guidance for interview rounds:\n- Deep-interview is Socratic: ask one focused round at a time. Do not use batch `questions[]` to combine multiple interview rounds, even though `omx question` supports batch forms for other workflows.\n- Use canonical `type` values instead of authoring raw `multi_select` flags by hand. `type: \"single-answerable\"` is the default for one-path decisions; `type: \"multi-answerable\"` is the canonical shape for bounded multi-select rounds. The runtime will keep `multi_select` aligned with `type`.\n- Use `single-answerable` when exactly one answer should drive the next branch, the options are mutually exclusive, or selecting more than one answer would blur the decision boundary. Typical cases: handoff lane selection, choosing the primary failure mode, or confirming which of several competing interpretations is correct.\n- Use `multi-answerable` when multiple options may all be true at once and you need to capture a bounded set of coexisting constraints, non-goals, risks, or acceptance checks in one round. Typical cases: selecting all out-of-scope items, all success metrics that must hold, or all deployment constraints that apply together.\n- If one selected option would immediately require a follow-up question to disambiguate the others, prefer a `single-answerable` round now and ask the follow-up next. Do not hide a branching interview tree inside one overloaded multi-select prompt.\n- Keep interview options bounded and concrete. If the valid answers are already known, set `allow_other: false`; only leave `allow_other: true` when the interview genuinely needs one user-supplied option that cannot be enumerated in advance.\n- Read answers structurally from the primary `answers[]` array. For a normal single-round interview response, use `answers[0].answer` as the source of truth; the top-level `answer` field is a legacy single-question projection/fallback only.\n- For `single-answerable`, expect one decisive selection in the `value` field of `answers[0].answer` plus its selected-values metadata. For `multi-answerable`, treat the selected-values field inside `answers[0].answer` as the source of truth for all chosen constraints/non-goals and preserve the full set in the transcript/spec. In legacy single-question projections, this is equivalent to: For `multi-answerable`, treat `answer.selected_values` as the source of truth.\n\nCanonical bounded single-choice payload:\n\n```json\n{\n \"question\": \"Which execution lane should own this once the interview is complete?\",\n \"type\": \"single-answerable\",\n \"options\": [\n {\n \"label\": \"Plan first\",\n \"value\": \"ralplan\",\n \"description\": \"Need architecture and test-shape review before execution\"\n },\n {\n \"label\": \"Execute directly\",\n \"value\": \"autopilot\",\n \"description\": \"Requirements are already explicit enough for planning plus execution\"\n },\n {\n \"label\": \"Refine further\",\n \"value\": \"refine\",\n \"description\": \"Clarification is still needed before any handoff\"\n }\n ],\n \"allow_other\": false,\n \"other_label\": \"Other\",\n \"source\": \"deep-interview\"\n}\n```\n\nCanonical bounded multi-select payload:\n\n```json\n{\n \"question\": \"Which non-goals must stay out of scope for the first pass?\",\n \"type\": \"multi-answerable\",\n \"options\": [\n {\n \"label\": \"No UI redesign\",\n \"value\": \"no-ui-redesign\",\n \"description\": \"Keep layout and styling unchanged\"\n },\n {\n \"label\": \"No new dependencies\",\n \"value\": \"no-new-dependencies\",\n \"description\": \"Work within the existing toolchain\"\n },\n {\n \"label\": \"No API contract changes\",\n \"value\": \"no-api-contract-changes\",\n \"description\": \"Preserve external request and response shapes\"\n }\n ],\n \"allow_other\": false,\n \"other_label\": \"Other\",\n \"source\": \"deep-interview\"\n}\n```\n\nCanonical answer-shape reminders:\n\n```json\n{\n \"answer\": {\n \"kind\": \"option\",\n \"value\": \"ralplan\",\n \"selected_labels\": [\"Plan first\"],\n \"selected_values\": [\"ralplan\"]\n }\n}\n```\n\n```json\n{\n \"answer\": {\n \"kind\": \"multi\",\n \"value\": [\"no-new-dependencies\", \"no-api-contract-changes\"],\n \"selected_labels\": [\"No new dependencies\", \"No API contract changes\"],\n \"selected_values\": [\"no-new-dependencies\", \"no-api-contract-changes\"]\n }\n}\n```\n\n### 2c) Score ambiguity\nScore each weighted dimension in `[0.0, 1.0]` with justification + gap.\n\nGreenfield: `ambiguity = 1 - (intent × 0.30 + outcome × 0.25 + scope × 0.20 + constraints × 0.15 + success × 0.10)`\n\nBrownfield: `ambiguity = 1 - (intent × 0.25 + outcome × 0.20 + scope × 0.20 + constraints × 0.15 + success × 0.10 + context × 0.10)`\n\nReadiness gate:\n- `Non-goals` must be explicit\n- `Decision Boundaries` must be explicit\n- A pressure pass must be complete: at least one earlier answer has been revisited with an evidence, assumption, or tradeoff follow-up\n- A practical closure audit must pass: another question would change execution materially, not merely polish wording or chase a narrow edge case\n- If either gate is unresolved, or the pressure pass is incomplete, continue below threshold only with a final closure question that names the unresolved gate and would materially change execution.\n- Treat a low ambiguity score as permission to audit closure, not permission to keep drilling indefinitely. If remaining uncertainty would not change implementation, crystallize the spec instead of opening a new branch.\n- If ambiguity is `<= 0.10`, another user-facing question is allowed only as that final closure question; otherwise crystallize immediately.\n\n### 2d) Report progress\nShow weighted breakdown table, readiness-gate status (`Non-goals`, `Decision Boundaries`), and the next focus dimension.\n\n### 2e) Persist state\nAppend round result and updated scores via `omx state write --input '<json>' --json`. Do not write `{mode}-state.json` directly and do not use the read-only MCP state projection as a writer.\n\n### 2f) Round controls\n- Do not offer early exit before the first explicit assumption probe and one persistent follow-up have happened\n- Apply a **Dialectic Rhythm Guard**: track consecutive non-user fact discoveries and confirmation-style answers (`[from-code][auto-confirmed]`, `[from-code]`, or `[from-research]`). After 3 consecutive non-user or confirmation answers, the next material user-facing round must solicit direct human judgment (`[from-user]`) unless the closure audit says the interview is ready to crystallize.\n- Round 4+: allow explicit early exit with risk warning\n- Soft warning at profile midpoint (e.g., round 3/6/10 depending on profile)\n- Hard cap at profile `max_rounds`; never treat this cap as a desired interview length or quota\n\n## Phase 3: Challenge Modes (assumption stress tests)\n\nUse each mode once when applicable. These are normal escalation tools, not rare rescue moves:\n\n- **Contrarian** (round 2+ or immediately when an answer rests on an untested assumption): challenge core assumptions\n- **Terminologist** (brownfield, whenever a key term is fuzzy, overloaded, or conflicts with repo docs/code): force a canonical meaning against existing project language before implementation\n- **Simplifier** (round 4+ or when scope expands faster than outcome clarity): probe minimal viable scope\n- **Ontologist** (round 5+ and ambiguity > 0.25, or when the user keeps describing symptoms): ask for essence-level reframing\n\nTrack used modes in state to prevent repetition.\n\n## Phase 4: Crystallize Artifacts\n\nWhen threshold is met (or user exits with warning / hard cap):\n\n1. Write interview transcript summary to:\n - `.omx/interviews/{slug}-{timestamp}.md`\n (kept for ralph PRD compatibility)\n2. Write execution-ready spec to:\n - `.omx/specs/deep-interview-{slug}.md`\n\nSpec should include:\n- Metadata (profile, rounds, final ambiguity, threshold, context type)\n- Context snapshot reference/path (for ralplan/team reuse)\n- Prompt-safe initial-context summary when oversized context was provided, plus references to any full source documents\n- Clarity breakdown table\n- Intent (why the user wants this)\n- Desired Outcome\n- In-Scope\n- Out-of-Scope / Non-goals\n- Decision Boundaries (what OMX may decide without confirmation)\n- Constraints\n- Testable acceptance criteria\n- Assumptions exposed + resolutions\n- Pressure-pass findings (which answer was revisited, and what changed)\n- Brownfield evidence vs inference notes for any repository-grounded confirmation questions\n- Docs/Terminology Ledger with inspected repo docs/rules/context, term conflicts, and any doc/code mismatch decisions\n- Scenario/edge-case pressure findings that materially shaped scope or acceptance criteria\n- Optional durable documentation recommendations, explicitly marked opt-in and public-safe; do not include raw private transcript dumps\n- Technical context findings\n- Full or condensed transcript\n\n### Autoresearch specialization\n\nWhen the clarified task is specifically about `$autoresearch`, or the skill is invoked with `--autoresearch`, keep the interview domain-specific and emit skill-consumable artifacts without skipping clarification.\n\n- **Accepted seed inputs:** `topic`, `evaluator`, `keep-policy`, `slug`, existing mission draft text, and prior evaluator examples/templates\n- **Required interview focus:** mission clarity, evaluator readiness, keep policy, slug/session naming, and whether the draft is ready to launch now or should refine further\n- **Canonical artifact path:** `.omx/specs/deep-interview-autoresearch-{slug}.md`\n- **Launch artifact bundle:** `.omx/specs/autoresearch-{slug}/mission.md`, `.omx/specs/autoresearch-{slug}/sandbox.md`, and `.omx/specs/autoresearch-{slug}/result.json`\n- **Launch artifact directory:** `.omx/specs/autoresearch-{slug}/`\n- **Required artifact sections:**\n - `Mission Draft`\n - `Evaluator Draft`\n - `Launch Readiness`\n - `Seed Inputs`\n - `Confirmation Bridge`\n- **Required launch artifacts under `.omx/specs/autoresearch-{slug}/`:**\n - `mission.md`\n - `sandbox.md`\n - `result.json`\n- **Launch-readiness rule:** mark the draft as **not launch-ready** while the evaluator command still contains placeholder markers such as `<...>`, `TODO`, `TBD`, `REPLACE_ME`, `CHANGEME`, or `your-command-here`\n- **Structured result contract:** `result.json` should point to the draft + mission/sandbox artifacts and carry the finalized `topic`, `evaluatorCommand`, `keepPolicy`, `slug`, `launchReady`, and `blockedReasons` fields so `$autoresearch` can consume it directly\n- **Confirmation bridge:** after artifact generation, offer at least `refine further` and `launch`; do not run direct CLI launch or detached/split tmux launch, and only hand off to `$autoresearch` after explicit confirmation\n- **Handoff rule:** downstream execution must preserve the clarified mission intent, evaluator expectations, decision boundaries, and launch-readiness status from this artifact rather than bypassing the draft review step\n\n## Phase 5: Execution Bridge\n\nPresent execution options after artifact generation using explicit handoff contracts. Treat the deep-interview spec as the current requirements source of truth and preserve intent, non-goals, decision boundaries, acceptance criteria, docs/terminology grounding, and any residual-risk warnings across the handoff.\n\n### Optional execution contract foundation\n\nWhen an Autopilot/deep-interview handoff explicitly requires a stride contract, emit it as structured data rather than prose. This is a validation foundation, not a broadness-inference feature: do not infer stride from task length, phase labels, snapshots, or freeform wording.\n\nCanonical location under Autopilot state:\n\n```json\n{\n \"handoff_artifacts\": {\n \"deep_interview\": {\n \"execution_contract_required\": true,\n \"execution_contract\": {\n \"version\": 1,\n \"execution_stride\": \"task\",\n \"source\": \"deep-interview\",\n \"selected_by\": \"user\",\n \"allow_task_shrink\": true,\n \"completion_unit\": \"One focused task\",\n \"stop_condition\": \"Stop after that task is implemented and verified\",\n \"acceptance_coverage_scope\": \"task\",\n \"shrink_policy\": \"allowed\"\n }\n }\n }\n}\n```\n\nStride meanings:\n- `task`: conservative, small-step execution; `allow_task_shrink:true`, `acceptance_coverage_scope:\"task\"`, `shrink_policy:\"allowed\"`.\n- `deliverable`: finish the named deliverable before stopping; `allow_task_shrink:false`, `acceptance_coverage_scope:\"deliverable\"`, `shrink_policy:\"ask_before_shrink\"`.\n- `milestone`: finish the larger approved milestone unless blocked; `allow_task_shrink:false`, `acceptance_coverage_scope:\"milestone\"`, `shrink_policy:\"deny_unless_blocked\"`.\n\nOnly set `execution_contract_required:true` when the selected downstream workflow needs this explicit stride/stop-condition guard. New artifacts must write the canonical snake_case schema shown above under `handoff_artifacts.deep_interview`; runtime readers may accept legacy camelCase field/marker aliases and direct/nested `execution_contract` locations only as compatibility input. If `execution_contract_required` is absent or false, downstream Autopilot compatibility behavior is unchanged.\n\n### Goal-mode follow-ups\n\nInclude these product-facing suggestions when they fit the clarified spec, without removing the existing `$ultragoal`, `$ralplan`, `$autopilot`, and `$team` handoff options:\n\n- **`$ultragoal`** — default goal-mode follow-up for implementation or general goal-oriented follow-up specs that should be converted into durable Codex/OMX goals with sequential completion tracking.\n- **`$autoresearch`** — use when the clarified context is a research project: a research question, reference/literature gathering, evaluator-backed analysis, or professor/critic-style deliverable.\n- **`$performance-goal`** — use when the clarified context is an optimization or performance project with measurable speed, latency, throughput, memory, benchmark, or evaluator criteria.\n\nRecommend `$ultragoal` as the default durable goal-mode follow-up because it supersedes Ralph for goal tracking. Preserve `$team` for coordinated parallel implementation.\n\n### 1. **`$ultragoal` (Default durable execution follow-up)**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md` (optionally accompanied by the transcript/context snapshot for traceability)\n- **Invocation:** `$ultragoal create-goals --brief-file <spec-path>` followed by `$ultragoal complete-goals` in the active execution lane\n- **Consumer Behavior:** Convert the clarified spec into durable goal-mode work. Preserve intent, non-goals, decision boundaries, acceptance criteria, docs/terminology grounding, scenario-pressure findings, and residual-risk warnings as binding story constraints.\n- **Skipped / Already-Satisfied Stages:** Requirement interview, ambiguity clarification, doc/context preflight, and early intent-boundary elicitation\n- **Expected Output:** `.omx/ultragoal/brief.md`, `.omx/ultragoal/goals.json`, `.omx/ultragoal/ledger.jsonl`, implementation evidence, verification evidence, and final cleanup/review-gate evidence\n- **Best When:** The clarified spec is execution-ready or the user explicitly wants durable goal tracking as the next step\n- **Next Recommended Step:** Run the Ultragoal completion loop; launch `$team` only inside an active Ultragoal story when parallel lanes are warranted\n\n### 2. **`$ralplan` (Recommended when architecture/test-shape review is still needed)**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md` (optionally accompanied by the transcript/context snapshot for traceability)\n- **Invocation:** `$ralplan <spec-path>`\n- **Consumer Behavior:** Treat the deep-interview spec as the requirements source of truth. Do not repeat the interview by default; refine architecture/feasibility around the clarified intent and boundaries instead.\n- **Skipped / Already-Satisfied Stages:** Requirements discovery, ambiguity clarification, and early intent-boundary elicitation\n- **Expected Output:** Canonical planning artifacts under `.omx/plans/`, especially `prd-*.md` and `test-spec-*.md`\n- **Best When:** Requirements are clear enough to stop interviewing, but architectural validation / consensus planning is still desirable\n- **Next Recommended Step:** Use the approved planning artifacts with `$ultragoal` as the default durable goal-mode follow-up (optionally with `$team` for parallel lanes); choose `$autoresearch` for research validation or `$performance-goal` for measurable optimization\n\n### 3. **`$autopilot`**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md`\n- **Invocation:** `$autopilot <spec-path>`\n- **Consumer Behavior:** Use the deep-interview spec as the clarified execution brief. Preserve intent, non-goals, decision boundaries, and acceptance criteria as binding context for planning/execution.\n- **Skipped / Already-Satisfied Stages:** Initial requirement discovery and ambiguity reduction\n- **Expected Output:** Planning/execution progress, QA evidence, and validation artifacts produced by autopilot\n- **Best When:** The clarified spec is already strong enough for direct planning + execution without an additional consensus gate\n- **Next Recommended Step:** Continue through autopilot's execution/QA/validation flow; if coordination-heavy execution emerges, prefer `$team` under a leader-owned `$ultragoal` ledger\n\n### 4. **`$team`**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md`\n- **Invocation:** `$team <spec-path>`\n- **Consumer Behavior:** Treat the spec as shared execution context for coordinated parallel work. Preserve the clarified intent, non-goals, decision boundaries, and acceptance criteria as common lane constraints.\n- **Skipped / Already-Satisfied Stages:** Requirement clarification and early ambiguity reduction\n- **Expected Output:** Coordinated multi-agent execution against the shared spec, with final verification evidence and checkpoints in an already-active Ultragoal ledger when applicable\n- **Best When:** The task is large, multi-lane, or blocker-sensitive enough to justify coordinated parallel execution instead of a single persistent loop\n- **Next Recommended Step:** Follow the team verification path when the coordinated execution phase finishes; checkpoint an already-active `$ultragoal` ledger when applicable. Do not start another execution loop solely to verify.\n\n### 5. **Refine further**\n- **Input Artifact:** Existing transcript, context snapshot, and current spec draft\n- **Invocation:** Continue the interview loop\n- **Consumer Behavior:** Re-enter questioning to resolve the highest-leverage remaining uncertainty\n- **Skipped / Already-Satisfied Stages:** None beyond already-captured context\n- **Expected Output:** A lower-ambiguity spec with tighter boundaries and fewer unresolved assumptions\n- **Best When:** Residual ambiguity is still too high, the user wants stronger clarity, or the above-threshold / early-exit warning indicates too much risk to proceed cleanly\n- **Next Recommended Step:** Return to one of the execution handoff contracts above once the spec is sufficiently clarified\n\n**Residual-Risk Rule:** If the interview ended via early exit, hard-cap completion, or above-threshold proceed-with-warning, explicitly preserve that residual-risk state in the handoff so the downstream skill knows it inherited a partially clarified brief.\n\n**IMPORTANT:** Deep-interview is a requirements mode. On handoff, invoke the selected skill using the contract above. **Do NOT implement directly** inside deep-interview.\n\n</Steps>\n\n<Tool_Usage>\n- Use `explore` for codebase fact gathering\n- Use `omx question` as the OMX-native structured user-input tool for each interview round when an attached tmux renderer is available\n- From attached-tmux Bash/tool paths, call it as `OMX_QUESTION_RETURN_PANE=$TMUX_PANE omx question ...` unless an explicit `%pane` return target is already known\n- If the current runtime is outside tmux and cannot render `omx question`, use native structured input when available; otherwise ask exactly one concise plain-text question and wait for the answer\n- After `omx question` returns JSON, prefer `answers[0].answer` / `answers[]`; use legacy `answer` only as a fallback for older records\n- Use `omx state write/read --input '<json>' --json` for resumable mode state through the sole-writer state operations path; the MCP state server is read-only and is not a fallback writer\n- If the interview cannot ask a required `omx question` round, persist the blocker as terminal state with `active: false` and `current_phase: \"blocked\"`; do not write a terminal blocked phase with `active: true`\n- Read/write context snapshots under `.omx/context/`\n- Read applicable repo docs/rules/context during preflight; write durable docs, glossary, ADR, or memory updates only when the user explicitly opts in and the content is public-safe\n- Record whether the oversized-context summary gate is not needed, pending, or satisfied before any scoring or handoff step\n- Save transcript/spec artifacts under `.omx/interviews/` and `.omx/specs/`\n</Tool_Usage>\n\n<Escalation_And_Stop_Conditions>\n- User says stop/cancel/abort -> persist state and stop\n- Ambiguity stalls for 3 rounds (+/- 0.05) -> force Ontologist mode once\n- Max rounds reached -> proceed with explicit residual-risk warning\n- All dimensions >= 0.9 -> allow early crystallization even before max rounds\n</Escalation_And_Stop_Conditions>\n\n<Final_Checklist>\n- [ ] Preflight context snapshot exists under `.omx/context/{slug}-{timestamp}.md`\n- [ ] Oversized initial context, if present, has a prompt-safe summary recorded before ambiguity scoring or downstream handoff\n- [ ] Ambiguity score shown each round\n- [ ] Intent-first stage priority used before implementation detail\n- [ ] Weakest-dimension targeting used within the active stage\n- [ ] At least one explicit assumption probe happened before crystallization\n- [ ] At least one persistent follow-up / pressure pass deepened a prior answer\n- [ ] Challenge modes triggered at thresholds (when applicable)\n- [ ] Transcript written to `.omx/interviews/{slug}-{timestamp}.md`\n- [ ] Spec written to `.omx/specs/deep-interview-{slug}.md`\n- [ ] Brownfield questions use evidence-backed confirmation when applicable\n- [ ] Brownfield preflight inspected applicable repo docs/rules/context before user-facing questions\n- [ ] Fuzzy or conflicting terminology was challenged against repo language/current code behavior when applicable\n- [ ] Scenario-based edge-case grilling was used when boundary ambiguity would materially affect implementation\n- [ ] Durable docs/ADR/memory updates, if any, were explicitly opted into and public-safe\n- [ ] Handoff options provided (`$ultragoal`, `$ralplan`, `$autopilot`, `$team`) plus context-sensitive goal-mode suggestions (`$autoresearch`, `$performance-goal`) when applicable\n- [ ] No direct implementation performed in this mode\n</Final_Checklist>\n\n<Advanced>\n## Suggested Config (optional)\n\nDeep-interview reads runtime defaults from the first existing config source in this order:\n\n1. Repository-local `.omx/config.toml`\n2. Repository-root `omx.toml`\n3. User-global `~/.omx/config.toml`\n\nThis section is currently a deep-interview-specific runtime override surface, not a general replacement for Codex `config.toml` or `.omx-config.json` model/env routing.\nMalformed config files are ignored fail-soft so `$deep-interview` activation can continue with built-in defaults.\nExplicit `--quick`, `--standard`, or `--deep` invocation flags override `defaultProfile`.\n\n```toml\n[omx.deepInterview]\ndefaultProfile = \"standard\"\nquickThreshold = 0.30\nstandardThreshold = 0.20\ndeepThreshold = 0.15\nquickMaxRounds = 5\nstandardMaxRounds = 12\ndeepMaxRounds = 20\nenableChallengeModes = true\n```\n\n## Resume\n\nIf interrupted, rerun `$deep-interview`. Resume from persisted mode state via `omx state read --input '{\"mode\":\"deep-interview\"}' --json`.\n\n## Canonical Autopilot Entry Pipeline\n\n```\nautopilot -> deep-interview -> ralplan -> ultragoal\n```\n\n- Autopilot begins with this independent deep-interview clarity gate; it must not substitute `$plan --interview`.\n- Stage 1 (deep-interview): ambiguity clearance and execution-ready requirements artifact\n- Stage 2 (ralplan): feasibility, architecture, and consensus gate\n- Stage 3 (ultragoal): durable execution, verification, and completion receipts\n</Advanced>\n","skills/design/SKILL.md":"---\nname: design\ndescription: Canonical repo-local DESIGN.md workflow for product, UI/UX, and frontend decision source of truth\n---\n\n# Design Skill\n\nUse `$design` to discover product and UI evidence, close only design-critical context gaps, and create or refresh the repository’s durable `DESIGN.md` contract. It is a maintained design brief, not a pixel-matching loop or one-off critique.\n\nShared operating, delegation, state, hook, team, cancellation, and verification invariants live in [`templates/AGENTS.md`](../../templates/AGENTS.md). Follow that source instead of duplicating its rules here.\n\n## Use when\n\n- Product, UX, frontend, or design-system decisions need a repo-local source of truth.\n- A feature needs a design brief before a designer lane or implementation.\n- Existing UI, assets, screenshots, or constraints need an actionable design summary.\n\nDo not use it for visual-reference implementation matching (use `$visual-ralph`), screenshot comparison alone, or backend/infrastructure work without user-facing design impact.\n\n## Relationship to `$visual-ralph`\n\n`$design` owns product goals, users, information architecture, visual language, components, accessibility, constraints, and open questions in `DESIGN.md`. `$visual-ralph` owns implementation against an approved visual reference or live-URL baseline, measured verdicts, and pixel-diff evidence. Run `$design` first when both are needed; `DESIGN.md` supports but does not replace the visual verdict target.\n\n## Workflow\n\n### 1. Discover local evidence\n\nInspect and cite existing `DESIGN.md`, design/UX/frontend docs, README/specs/issues, routes/pages/layouts/components/stories, theme and token files, assets, screenshots/mockups, Storybook or Playwright baselines, and accessibility/responsive/i18n/platform constraints. Separate observations from inferences; note absent evidence.\n\n### 2. Interview only missing context\n\nAsk concise questions only for gaps the repository cannot resolve: users/jobs, goals/non-goals, brand personality and forbidden aesthetics, primary flows, accessibility/device/browser targets, or unavailable assets/references. If answers are unavailable, record explicit assumptions and open questions rather than blocking.\n\n### 3. Create or refresh `DESIGN.md`\n\nPreserve useful content, remove contradictions, mark unknowns, and keep decisions actionable. The root file must contain these sections:\n\n# Design\n## Source of truth\nStatus (Draft | Active | Needs refresh), date, product surfaces, evidence reviewed.\n## Brand\nPersonality, trust signals, avoid.\n## Product goals\nGoals, non-goals, success signals.\n## Personas and jobs\nPrimary personas, user jobs, contexts of use.\n## Information architecture\nNavigation, routes/screens, content hierarchy.\n## Design principles\nPrinciples and tradeoffs.\n## Visual language\nColor, typography, spacing, shape/elevation, motion, imagery/iconography.\n## Components\nExisting/new components, variants/states, token ownership.\n## Accessibility\nTarget standard, keyboard/focus, contrast, semantics, reduced motion/sensory concerns.\n## Responsive behavior\nBreakpoints/devices, layout adaptations, touch/hover differences.\n## Interaction states\nLoading, empty, error, success, disabled, offline/slow network where applicable.\n## Content voice\nTone, terminology, microcopy rules.\n## Implementation constraints\nFramework/styling, tokens, performance, compatibility, test/screenshot expectations.\n## Open questions\n`[ ]` question, owner, and impact.\n\n### 4. Apply the contract\n\nBefore UI decisions, cite relevant `DESIGN.md` sections, reuse documented components/tokens, and update the file or add an open question when implementation exposes a contradiction. Do not invent a parallel design-system layer.\n\n### 5. Handoff\n\nFor normal frontend work, provide the relevant sections, repo evidence, and acceptance criteria. For visual-reference, image, or live-URL matching, hand off to `$visual-ralph` with the approved baseline and identify `DESIGN.md` as supporting context only.\n\n## Evidence and completion\n\nComplete only when design docs/assets/components/screenshots were inspected or noted absent; missing context is answered, assumed, or listed; root `DESIGN.md` contains every required section; recommendations cite it; and any Visual Ralph handoff is clearly separated from design governance.\n\nTask: {{ARGUMENTS}}\n","skills/doctor/SKILL.md":"---\nname: doctor\ndescription: Diagnose and fix oh-my-codex installation issues\n---\n\n# OMX Doctor\n\nUse this task card to diagnose installation/discovery problems. Shared safety, lifecycle, hook, team, autonomy, and cancellation rules live in `templates/AGENTS.md`. `~/.codex` means `${CODEX_HOME:-~/.codex}` when `CODEX_HOME` is set.\n\n## Run diagnostics\n\n```bash\nomx doctor\nomx doctor --team # include Team runtime checks\nomx doctor --verbose # include detailed check evidence\nomx doctor --force # repair eligible repo artifact ownership issues\nomx doctor --dry-run --force # preview eligible ownership repairs\n```\n\nFor a local source checkout, build first and invoke `node dist/cli/omx.js doctor`. Keep command output and exact paths for the report.\n\n### Plugin cache and version\n\n```bash\nPLUGIN_CACHE_ROOT=\"${CODEX_HOME:-$HOME/.codex}/plugins/cache\"\nCACHE_ENTRIES=$(find \"$PLUGIN_CACHE_ROOT\" -path \"*/oh-my-codex/*\" -mindepth 3 -maxdepth 3 -type d 2>/dev/null)\nif [[ -z \"$CACHE_ENTRIES\" ]]; then\n echo \"Installed plugin cache: none\"\nelse\n while IFS= read -r d; do\n m=$(basename \"$(dirname \"$(dirname \"$d\")\")\"); v=$(basename \"$d\")\n printf 'Installed plugin cache: marketplace=%s version=%s path=%s\\n' \"$m\" \"$v\" \"$d\"\n done <<<\"$CACHE_ENTRIES\"\nfi\nLATEST=$(npm view oh-my-codex version 2>/dev/null)\necho \"Latest npm: $LATEST\"\n```\n\nNo cache is INFO (normal for npm/setup-only installs). A non-`local` cache version differing from `LATEST`, or multiple versions for one marketplace, is WARN. Plugin discovery does not replace npm installation plus `omx setup`; native/runtime wiring remains setup-owned.\n\n### Hooks, AGENTS, and skill roots\n\n```bash\nCODEX_DIR=\"${CODEX_HOME:-$HOME/.codex}\"\nls -la \"$CODEX_DIR/config.toml\" \"$CODEX_DIR/settings.json\" 2>/dev/null\nrg 'keyword-detector|persistent-mode|session-start|stop-continuation' \"$CODEX_DIR/config.toml\" \"$CODEX_DIR/settings.json\" 2>/dev/null || true\nls -la \"$CODEX_DIR/hooks\"/*.sh 2>/dev/null\nls -la \"$CODEX_DIR/AGENTS.md\" 2>/dev/null\ngrep -q \"oh-my-codex Multi-Agent System\" \"$CODEX_DIR/AGENTS.md\" 2>/dev/null && echo \"Has OMX config\" || echo \"Missing OMX config\"\nls -la \"$CODEX_DIR/agents\" \"$CODEX_DIR/commands\" \"$CODEX_DIR/skills\" \"$HOME/.agents/skills\" 2>/dev/null\n```\n\nClassify legacy hook references as **CRITICAL** (duplicate hooks). The scripts `keyword-detector.sh`, `persistent-mode.sh`, `session-start.sh`, and `stop-continuation.sh` are **WARN**. Missing AGENTS.md is **CRITICAL**; missing the OMX marker is **WARN**. `${CODEX_HOME:-~/.codex}/skills` is the canonical user root. `~/.agents/skills` is historical and overlapping trees can duplicate skill entries. OMX files under legacy `agents/` or `commands/` are **WARN**.\n\nWith `--team`, retain any `resume_blocker`, `slow_shutdown`, `delayed_status_lag`, `stale_leader`, or `orphan_tmux_session` diagnostics; failed checks set a non-zero exit status.\n\n## Report contract\n\n```text\n## OMX Doctor Report\n### Summary\n[HEALTHY / ISSUES FOUND]\n### Checks\n| Check | Status | Details |\n| Plugin Version | OK/WARN/INFO | ... |\n| Hook Config (config.toml / legacy settings.json) | OK/CRITICAL | ... |\n| Legacy Scripts (~/.codex/hooks/) | OK/WARN | ... |\n| AGENTS.md | OK/WARN/CRITICAL | ... |\n| Plugin Cache | OK/WARN | ... |\n| Legacy Agents / Commands | OK/WARN | ... |\n| Skills (canonical / historical root) | OK/WARN | ... |\n### Issues Found\n1. ...\n### Recommended Fixes\n...\n```\n\n## Remediation (after user confirmation and confirming each target is OMX-owned)\n\nRemove only confirmed OMX legacy content; preserve unrelated user files:\n\n```bash\n# If settings.json exists, remove only its legacy \"hooks\" section.\nrm -f \"$CODEX_DIR/hooks/keyword-detector.sh\" \"$CODEX_DIR/hooks/persistent-mode.sh\" \"$CODEX_DIR/hooks/session-start.sh\" \"$CODEX_DIR/hooks/stop-continuation.sh\"\nPLUGIN_CACHE_ROOT=\"${CODEX_HOME:-$HOME/.codex}/plugins/cache\"\nfind \"$PLUGIN_CACHE_ROOT\" -path \"*/oh-my-codex\" -type d -prune -exec rm -rf {} +\n```\n\nFor older curl installs, inspect first and remove only directories containing OMX-managed files:\n\n```bash\nls -la \"$CODEX_DIR/agents\" \"$CODEX_DIR/commands\" \"$CODEX_DIR/skills\" \"$HOME/.agents/skills\" 2>/dev/null\n# Optional backups:\n# mv \"$CODEX_DIR/agents\" \"$CODEX_DIR/agents.bak\"\n# mv \"$CODEX_DIR/commands\" \"$CODEX_DIR/commands.bak\"\n# mv \"$HOME/.agents/skills\" \"$HOME/.agents/skills.bak\"\nrm -rf \"$CODEX_DIR/agents\" \"$CODEX_DIR/commands\" \"$HOME/.agents/skills\"\n```\n\nIf AGENTS.md is missing/outdated, fetch the current raw file and write it to `$CODEX_DIR/AGENTS.md`:\n\n```text\nWebFetch(url: \"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/main/docs/AGENTS.md\", prompt: \"Return the complete raw markdown content exactly as-is\")\n```\n\nTo keep only the newest cache version for a selected marketplace:\n\n```bash\nPLUGIN_CACHE_DIR=\"$PLUGIN_CACHE_ROOT/$MARKETPLACE_NAME/oh-my-codex\"\nKEEP_VERSION=$(for d in \"$PLUGIN_CACHE_DIR\"/*; do [[ -d \"$d\" ]] && basename \"$d\"; done | sort -V | tail -1)\n[[ -n \"$KEEP_VERSION\" ]] && find \"$PLUGIN_CACHE_DIR\" -mindepth 1 -maxdepth 1 -type d ! -name \"$KEEP_VERSION\" -exec rm -rf {} +\n```\n\nIf AGENTS.md is missing or stale, refresh it from the current release source, then rerun `omx doctor`. If legacy `~/.agents/skills` overlaps the canonical root, archive/remove that tree only after checking for custom skills. Restart Codex after fixes and report before/after evidence.\n\n## Exit conditions\n\nStop with **HEALTHY** only when required paths, hook/config checks, AGENTS marker, plugin cache status, and (when requested) Team checks pass. Otherwise report **ISSUES FOUND**, exact failed evidence, and the smallest confirmed remediation; do not claim a fix from a recommendation alone.\n","skills/git-master/SKILL.md":"---\nname: git-master\ndescription: Git expert for atomic commits, rebasing, and history management\n---\n\n# Git Master Command\n\nRoutes to the git-master agent for git operations.\n\n## Usage\n\n```\n/git-master <git task>\n```\n\n## Routing\n\n```text\nUse /prompts:git-master with the user task.\n```\n\n## Capabilities\n- Atomic commits with conventional format\n- Interactive rebasing\n- Branch management\n- History cleanup\n- Style detection from repo history\n","skills/hud/SKILL.md":"---\nname: \"hud\"\ndescription: \"Show or configure the OMX HUD (two-layer statusline)\"\nrole: \"display\"\nscope: \".omx/**\"\n---\n\n# HUD Skill\n\nThe OMX HUD uses a two-layer architecture:\n\n1. **Layer 1 - Codex built-in statusLine**: Real-time TUI footer showing model, git branch, and context usage. Configured via `[tui] status_line` in `~/.codex/config.toml`. Zero code required.\n\n2. **Layer 2 - `omx hud` CLI command**: Shows OMX-specific orchestration state (ralph, ultrawork, autopilot, team, pipeline, ecomode, turns). Reads `.omx/state/` files.\n\n## Quick Commands\n\n| Command | Description |\n|---------|-------------|\n| `omx hud` | Show current HUD (modes, turns, activity) |\n| `omx hud --watch` | Live-updating display (polls every 1s) |\n| `omx hud --json` | Raw state output for scripting |\n| `omx hud --preset=minimal` | Minimal display |\n| `omx hud --preset=focused` | Default display |\n| `omx hud --preset=full` | All elements |\n\n## Presets\n\n### minimal\n```\n[OMX] ralph:3/10 | turns:42\n```\n\n### focused (default)\n```\n[OMX] ralph:3/10 | ultrawork | team:3 workers | turns:42 | last:5s ago\n```\n\n### full\n```\n[OMX] ralph:3/10 | ultrawork | autopilot:execution | team:3 workers | pipeline:exec | turns:42 | last:5s ago | total-turns:156\n```\n\n## Setup\n\n`omx setup` automatically configures both layers:\n- Adds `[tui] status_line` to `~/.codex/config.toml` (Layer 1)\n- Writes `.omx/hud-config.json` with default preset (Layer 2)\n- Default preset is `focused`; if HUD/statusline changes do not appear, restart Codex CLI once.\n\n## Layer 1: Codex Built-in StatusLine\n\nConfigured in `~/.codex/config.toml`:\n```toml\n[tui]\nstatus_line = [\"model-with-reasoning\", \"git-branch\", \"context-remaining\"]\n```\n\nAvailable built-in items (Codex CLI v0.101.0+):\n`model-name`, `model-with-reasoning`, `current-dir`, `project-root`, `git-branch`, `context-remaining`, `context-used`, `five-hour-limit`, `weekly-limit`, `codex-version`, `context-window-size`, `used-tokens`, `total-input-tokens`, `total-output-tokens`, `session-id`\n\n## Layer 2: OMX Orchestration HUD\n\nThe `omx hud` command reads these state files:\n- `.omx/state/ralph-state.json` - Ralph loop iteration\n- `.omx/state/ultrawork-state.json` - Ultrawork mode\n- `.omx/state/autopilot-state.json` - Autopilot phase\n- `.omx/state/team-state.json` - Team workers\n- `.omx/state/pipeline-state.json` - Pipeline stage\n- `.omx/state/ecomode-state.json` - Ecomode active\n- `.omx/state/hud-state.json` - Last activity (from notify hook)\n- `.omx/metrics.json` - Turn counts\n\n## Configuration\n\nHUD config stored at `.omx/hud-config.json`:\n```json\n{\n \"preset\": \"focused\"\n}\n```\n\n## Color Coding\n\n- **Green**: Normal/healthy\n- **Yellow**: Warning (ralph >70% of max)\n- **Red**: Critical (ralph >90% of max)\n\n## Troubleshooting\n\nIf the TUI statusline is not showing:\n1. Ensure Codex CLI v0.101.0+ is installed\n2. Run `omx setup` to configure `[tui]` section\n3. Restart Codex CLI\n\nIf `omx hud` shows \"No active modes\":\n- This is expected when no workflows are running\n- Start an explicitly requested supported workflow (`$autopilot` or `$ultragoal`) and check again\n","skills/omx-setup/SKILL.md":"---\nname: omx-setup\ndescription: Setup and configure oh-my-codex using current CLI behavior\n---\n\n# OMX Setup\n\nUse this task card to install or refresh OMX for the current project and/or user scope. Shared safety, lifecycle, hook, team, autonomy, and cancellation rules live in `templates/AGENTS.md`. Do not infer new CLI behavior from this card; the implementation is authoritative.\n\n## Command and alternatives\n\n```bash\nomx setup [--force] [--merge-agents|--no-merge-agents|--clear-merge-agents-policy] [--dry-run] [--verbose] [--scope <user|project>] [--plugin|--legacy|--install-mode <legacy|plugin>] [--mcp <none|compat>] [--no-mcp|--with-mcp] [--disable-team|--enable-team|--team-mode <enabled|disabled>]\nomx agents-init [path] [--dry-run] [--force] [--verbose]\n```\n\nUse `agents-init` for lightweight AGENTS.md scaffolding only, not a full install.\n\nSupported setup options:\n- `--force`: overwrite/reinstall managed artifacts; transient, not persisted or replayed.\n- `--merge-agents`, `--no-merge-agents`, `--clear-merge-agents-policy`: exact bare selectors (no values/equals). Repeated identical selectors are idempotent; conflicting selectors fail before mutations. Set persists an explicit policy per invoking project root; clear removes it and cannot combine with a set. Merge refreshes managed sections; no-merge only suppresses that branch and is not a preserve mode.\n- `--dry-run`, `--verbose`: preview actions or show per-file/per-step detail.\n- `--scope user|project`: choose user (`~/.codex`, `~/.omx/agents`) or project (`./.codex`, `./.omx/agents`) targets.\n- `--plugin` / `--legacy`: select delivery mode; `--install-mode legacy|plugin` is the canonical scripted spelling. Conflicting mode flags fail.\n- `--mcp none|compat` (plus `--no-mcp` / `--with-mcp`): omit or enable first-party MCP compatibility and shared registry sync.\n- `--disable-team`, `--enable-team`, `--team-mode enabled|disabled`: select Team skill/context generation; conflicting selectors fail.\n\n## Resolve setup\n\n1. Scope: explicit flag, valid persisted `./.omx/setup-scope.json`, TTY choice (default `user`), or non-interactive `user`. Legacy `project-local` migrates to `project`.\n2. Mode: explicit flag, persisted mode when retained, discovered `${CODEX_HOME:-~/.codex}/plugins/cache/**/.codex-plugin/plugin.json` with `name: oh-my-codex` (plugin default), otherwise legacy. TTY reruns summarize saved choices and offer keep/review/reset; non-interactive runs do not block.\n3. Create required directories and atomically persist preferences only after successful setup.\n\n## What setup changes\n\n- Legacy mode installs prompts/native agents/skills and merges full config.toml.\n- Plugin mode archives/removes legacy OMX-managed prompts/skills, refreshes installable native agent TOMLs and stale generated non-installable agents, and keeps setup-owned runtime hooks.\n- Both modes verify Team CLI interop markers in built `dist/cli/team.js`, generate AGENTS defaults only when selected/allowed, and write `./.omx/hud-config.json`; notification hook references are setup-owned outside plugin skill delivery.\n- `AGENTS.md` is `./AGENTS.md`. Without `--force` or `--merge-agents`, interactive runs ask before overwrite and non-interactive runs preserve it. Active-session safeguards may skip writes. Plugin mode may separately prompt for AGENTS and `developer_instructions` defaults; non-interactive runs preserve existing files.\n- Plugin mode enables setup-owned runtime flags (`plugin_hooks`, `goals`, or legacy `hooks`/`codex_hooks` fallback). Project scope uses `CODEX_HOME=./.codex` unless explicitly overridden.\n\n## Verify\n\n```bash\nomx setup --force --verbose\nomx doctor\n```\n\nExpect doctor evidence for prompts and skills in the selected scope, project-root AGENTS.md, `.omx/state`, and CLI-first config in the scope target `config.toml`. First-party MCP and shared registry sync are omitted unless setup used `--mcp compat` (if supported by the installed CLI).\n\nIf using local source, run `npm run build` before `node dist/cli/omx.js setup --force --verbose` and `node dist/cli/omx.js doctor`. If AGENTS was not overwritten or merged, stop the active OMX session and rerun with `--force` or `--merge-agents`; do not edit lifecycle state manually.\n\n## Discovery troubleshooting\n\nIf `$omx-setup` is absent/stale: run `omx setup --verbose`, then `omx doctor`; verify `./.codex/skills/omx-setup/SKILL.md` for project scope or `${CODEX_HOME:-~/.codex}/skills/omx-setup/SKILL.md` for legacy user scope. In plugin mode verify the oh-my-codex plugin is installed/discovered. For duplicates, inspect historical `~/.agents/skills` overlap and follow doctor/setup cleanup guidance.\n\n## Exit contract\n\nReport selected scope/mode, dry-run versus mutation, AGENTS policy, affected roots, and doctor indicators. Stop only after setup completes successfully and verification identifies the expected files/config; on failure preserve the exact command output and rerun the smallest corrective command. Do not claim installation from a dry-run alone.\n","skills/performance-goal/SKILL.md":"---\nname: performance-goal\ndescription: \"Run an evaluator-gated performance optimization workflow over Codex goal mode with durable OMX artifacts and safe goal handoffs.\"\n---\n\n# Performance Goal Workflow\n\nUse this skill when a user asks OMX to optimize performance and wants a goal-oriented loop rather than a one-off review.\n\n## Contract\n\n- OMX owns durable workflow state under `.omx/goals/performance/<slug>/`.\n- Codex goal mode owns only the active-thread focus/accounting primitive.\n- Shell commands do **not** mutate hidden Codex goal state. They write artifacts and emit model-facing handoff text.\n- No optimization work may start until an evaluator command and pass/fail contract exist.\n- Do not call `update_goal({status: \"complete\"})` until the evaluator has a passing checkpoint and a completion audit proves the objective is done; then call `get_goal` again and pass that fresh snapshot to `omx performance-goal complete --codex-goal-json`.\n\n## CLI\n\nCreate the workflow and evaluator contract:\n\n```sh\nomx performance-goal create \\\n --objective \"Reduce CLI startup latency by 20%\" \\\n --evaluator-command \"npm run perf:startup\" \\\n --evaluator-contract \"PASS when p95 latency improves by 20% and regression tests pass\" \\\n --slug startup-latency\n```\n\nEmit the Codex goal handoff:\n\n```sh\nomx performance-goal start --slug startup-latency\n```\n\nRecord evaluator evidence:\n\n```sh\nomx performance-goal checkpoint --slug startup-latency --status pass --evidence \"benchmark + tests passed\"\nomx performance-goal checkpoint --slug startup-latency --status fail --evidence \"benchmark regressed\"\nomx performance-goal checkpoint --slug startup-latency --status blocked --evidence \"missing fixture\"\n```\n\nComplete only after a passing checkpoint:\n\n```sh\nomx performance-goal complete --slug startup-latency --evidence \"final evaluator evidence\" --codex-goal-json <get_goal-json-or-path>\n```\n\n## Agent Loop\n\n1. Run `omx performance-goal create` if no workflow exists.\n2. Run `omx performance-goal start` and follow the handoff:\n - call `get_goal`;\n - call `create_goal` only when no active goal exists and the objective is explicit;\n - work only against the evaluator contract;\n - after evaluator pass and completion audit, call `update_goal({status: \"complete\"})`, call `get_goal` again, and pass that snapshot to `omx performance-goal complete --codex-goal-json`;\n - after `omx performance-goal complete` succeeds, run `/goal clear` in the Codex UI before starting another goal in this same thread/session; OMX prints this terminal cleanup step but does not invoke hidden clear routes;\n3. Optimize in small reversible patches.\n4. Run the evaluator and related regression tests.\n5. Record each pass/fail/blocker with `checkpoint`.\n6. Complete only when the pass artifact exists and no required work remains.\n\n## Completion Gate\n\nA performance goal is incomplete unless `.omx/goals/performance/<slug>/state.json` contains a `lastValidation.status` of `pass` and `omx performance-goal complete` receives a matching complete Codex `get_goal` snapshot via `--codex-goal-json`. Passing ordinary tests alone is not sufficient unless they are the declared evaluator contract.\n\nLifecycle: `create_goal` starts the Codex thread goal, `update_goal({status: \"complete\"})` marks terminal success after the evaluator and audit pass, and `/goal clear` removes the completed thread goal when another same-thread goal is needed. OMX shell commands and hooks reconcile snapshots and print the cleanup instruction; they must not mutate hidden Codex goal state.\n","skills/pipeline/SKILL.md":"---\nname: pipeline\ndescription: Sunset stub — use $plan and $team directly instead\n---\n\n# Pipeline — removed\n\n`$pipeline` was removed in OMX 0.21.\n\nPipeline's configurable stage sequencing overlapped `$plan` (planning) and `$team` (execution) without a unique runtime. Use the canonical skills directly: `$plan` for optional planning, `$team` for coordinated parallel execution, `$ultragoal` for durable goal-mode runs.\n\nMigration: replace `$pipeline` with explicit `$plan` and `$team` invocations as the task warrants.\n\nTask: {{ARGUMENTS}}\n","skills/plan/SKILL.md":"---\nname: plan\ndescription: Lightweight planning with optional interview\n---\n\n<Purpose>\nPlan creates concise, actionable work plans. Auto-detects interview vs direct, supports `--interview` for Socratic clarification and `--review` for evaluation.\n</Purpose>\n\n<Use_When>\n- Planning before implementation — \"plan this\", \"let's plan\"\n- Requirements are vague and need scoping — use `--interview`\n- Reviewing an existing plan — `--review`\n</Use_When>\n\n<Do_Not_Use_When>\n- Want direct execution — execute the scoped task directly; use `ultragoal` only for durable goals or `team` for coordinated parallel work\n- Simple focused fix with obvious scope — skip planning\n</Do_Not_Use_When>\n\n<Execution_Policy>\n- Auto-detect interview vs direct; `--interview` forces Socratic mode, `--direct` skips it\n- Ask one question at a time; gather codebase facts first\n- `omx explore` is deprecated. Use normal repository inspection for codebase facts; `omx sparkshell` only for explicit shell-native evidence\n- Plans must be evidence-backed: 80%+ claims cite file/line, 90%+ criteria testable\n- Right-size steps to scope; save to `.omx/plans/`\n</Execution_Policy>\n\n<Steps>\n\n### Mode Selection\n| Mode | Trigger | Behavior |\n|------|---------|----------|\n| Interview | `--interview` or broad request | Socratic requirements gathering |\n| Direct | `--direct` or detailed request | Generate plan immediately |\n| Review | `--review` | Critic evaluation of existing plan |\n\n### Interview (`--interview`)\n1. Classify request; ask one focused question via `omx question`\n2. Gather codebase facts first, then ask informed follow-ups\n3. Build on answers; consult Analyst for hidden requirements\n4. Create plan when user signals readiness\n\n### Direct\n1. Quick analysis (optional Analyst)\n2. Generate plan immediately\n3. Optional Critic review if requested\n\n### Review (`--review`)\n1. Read plan from `.omx/plans/`\n2. Evaluate via Critic; verdict APPROVED/REVISE/REJECT\n3. If author == reviewer, hand off to `$code-review`\n\n### Output\nEvery plan includes: Requirements Summary, Acceptance Criteria (testable), Implementation Steps (with file refs, adaptive count), Risks/Mitigations, Verification. Saved to `.omx/plans/`.\n\nOutcome-first framing: apply outcome-first framing, concise visible updates for multi-step planning. Local overrides for the active workflow branch apply via newer user task updates. If the user says `continue`, continue the current branch instead of restarting.\n\n</Steps>\n\n<Tool_Usage>\n- `omx explore` is deprecated. Use normal repository inspection; `omx sparkshell` only for explicit shell-native evidence\n- Use `omx question` for interview questions; plain text only as fallback\n- Use `ask_codex` with `planner`/`analyst`/`critic` as needed\n</Tool_Usage>\n\n<Escalation_And_Stop_Conditions>\n- Stop interviewing when requirements are clear — do not over-interview\n- Escalate on irreconcilable trade-offs requiring business decision\n- \"just do it\" / \"skip planning\" → hand off to `$ultragoal`\n</Escalation_And_Stop_Conditions>\n\n<Final_Checklist>\n- [ ] Acceptance criteria testable (90%+ concrete)\n- [ ] Claims cite file/line (80%+)\n- [ ] Risks have mitigations, no vague terms\n- [ ] Plan saved to `.omx/plans/`\n</Final_Checklist>\n\n<Advanced>\n## Question Classification\n| Type | Examples | Action |\n|------|----------|--------|\n| Codebase Fact | \"Where is X?\" | Explore first, do not ask |\n| User Preference | \"Priority?\" | Ask via `omx question` |\n| Scope Decision | \"Include Y?\" | Ask user |\n\n## Review Quality Criteria\n| Criterion | Standard |\n|-----------|----------|\n| Clarity | 80%+ claims cite file/line |\n| Testability | 90%+ criteria concrete |\n| Verification | File refs exist |\n</Advanced>\n","skills/ralph/SKILL.md":"---\nname: ralph\ndescription: Sunset stub — use $ultragoal instead\n---\n\n# Ralph — removed\n\n`$ralph` was removed in OMX 0.21; use `$ultragoal` instead.\n\nRalph's loop-until-done behavior is a degenerate single-goal ultragoal run. `$ultragoal` owns durable Codex goal handoffs, `.omx/ultragoal` ledger checkpoints, implementation, tests, build/lint/typecheck evidence, and resume across stories. A single-goal ultragoal run reuses the same persistence and verified-completion promise that Ralph provided.\n\nMigration: replace `$ralph` with `$ultragoal`.\n\nTask: {{ARGUMENTS}}\n","skills/ralplan/SKILL.md":"---\nname: ralplan\ndescription: Consensus planning stage for Planner -> Architect -> Critic handoff to $ultragoal\n---\n\n# Ralplan (Consensus Planning Alias)\n\nRalplan is the canonical consensus-planning stage used by Autopilot between `$deep-interview` and `$ultragoal`. It drives Planner, Architect, and Critic planning and records their review lifecycle with **RALPLAN-DR structured deliberation** (short mode by default, deliberate mode for high-risk work). Local lifecycle evidence is not host-issued security authority, but ordinary progression to Ultragoal must remain reachable after the execution-ready plan and sequential review evidence are durable; missing host provenance must not terminalize Ralplan or block cancel, clear, or recovery.\n\n## Usage\n\n```\n$ralplan \"task description\"\n```\n\nStandalone advisory planning is explicitly opt-in:\n\n```text\n$ralplan --advisory \"task description\"\n```\n\nAdvisory runs the same sequential Planner → Architect → Critic review lifecycle, binds the plan and both review artifacts to exact bytes and one tracker-backed iteration, then returns to the caller with `active:false`. It is a cooperative workflow pause, not a security fence or permission system. It never emits a `PreToolUse` allow/block decision, never completes the host consensus gate, never authorizes execution, and never suppresses unrelated host behavior. Terminal state must carry explicit `false` values for the consensus gate, host verification, and execution handoff rather than omitting them. A later concrete affirmative execution request may produce non-authoritative routing context, but it does not persist a permission, rewrite terminal evidence, or create an automatic handoff; quotations, code, examples, documentation, questions, modal requests, negations, and vague approval remain classifier negatives. `approved+proven` requires complete lifecycle digests plus post-write revalidation. Administrative abandonment is append-only, idempotent for prepared or committed journals, and records a separate byte-bound admin event without rewriting the original closeout journal. Real enforcement requires an explicit host-issued, host-verified receipt or capability on a non-user-mintable surface; local Advisory files, prompts, session/thread fields, tracker records, and HERDR observability cannot substitute for it. On Darwin, each Advisory evidence artifact is limited to 128 KiB by the pinned-directory reader; other supported platforms allow up to 8 MiB.\n\n## Flags\n\n- `--interactive`: Enables user prompts at key decision points (draft review in step 2 and final approval in step 6). Without this flag the workflow runs fully automated — Planner → Architect → Critic loop — and outputs the final plan without asking for confirmation.\n- `--deliberate`: Forces deliberate mode for high-risk work. Adds pre-mortem (3 scenarios) and expanded test planning (unit/integration/e2e/observability). Without this flag, deliberate mode can still auto-enable when the request explicitly signals high risk (auth/security, migrations, destructive changes, production incidents, compliance/PII, public API breakage).\n- `--advisory`: Standalone only. It cannot be combined with Autopilot, Pipeline, Team, Ralph, Ultragoal, execution flags, or unknown flags. Activation requires canonical session, root thread, and turn identity.\n\n## Ontology-heavy review\n\nFor requirements semantics, taxonomy, prompt/spec design, policy distinctions, or category-risk architecture, cite the `architect` role agent's read-only review as advisory evidence. Its findings can inform the plan or follow-up evidence when explicitly used, but `$ralplan` itself records Architect→Critic lifecycle evidence only, and advisory review is never a durable execution authorization.\n\n## Usage with interactive mode\n\n```\n$ralplan --interactive \"task description\"\n```\n\n## Behavior\n\n## GPT-5.6 Guidance Alignment\n\nUse the shared workflow guidance pattern: outcome-first framing, concise visible updates for multi-step planning, local overrides for the active workflow branch, evidence-backed planning and validation expectations, explicit stop rules, right-sized implementation/PRD shape, and automatic continuation for safe reversible steps. Ask only for material, destructive, credentialed, external-production, or preference-dependent branches.\n\nThis skill runs its own consensus runtime; it does not delegate to a nonexistent Plan consensus mode:\n\n```\nomx ralplan run --task <arguments> [--session <id>]\n```\n\nThe consensus workflow:\n1. **Planner** creates an adaptive plan (right-sized to task scope; do not default to exactly five steps) and a compact **RALPLAN-DR summary** before review. Current `[main]` vs `[planner]` behavior: standalone `$ralplan` may be authored by the active main planning lane unless the caller/runtime supplies a dedicated planner routing record; inside `$autopilot`, state field `planning_routing.owner:\"planner\"` means the initial Planner draft/decomposition must use dedicated `[planner]`. Set `.omx-config.json` `agentModels.planner` to opt into a specific planner model and force dedicated planner ownership for complex Autopilot planning even when `[main]` is not cheap/mini. The RALPLAN-DR summary includes:\n - Principles (3-5)\n - Decision Drivers (top 3)\n - Viable Options (>=2) with bounded pros/cons\n - If only one viable option remains, explicit invalidation rationale for alternatives\n - Deliberate mode only: pre-mortem (3 scenarios) + expanded test plan (unit/integration/e2e/observability)\n2. **User feedback** *(--interactive only)*: If `--interactive` is set, use the structured question UI (`omx question` in attached tmux; native structured input outside tmux when available) to present the draft plan **plus the Principles / Drivers / Options summary** before review (Proceed to review / Request changes / Skip review). Otherwise, automatically proceed to review.\n**Native role-routing preflight:** Keyword routing may already have selected Ralplan, but it is not authority. Run `omx ralplan preflight --json` only when the native task surface reports `role_routing_unavailable` and this workflow attempts adapted Ralplan Planner, Architect, or Critic authority, adapted role-intent, or adapted consensus authority. On `unsupported_documented_leader_proof`, stop before that adapted authority and use a Codex surface with documented root proof or a reviewed alternative workflow. Do not infer root identity from `session_id`, undocumented `thread_id`, session/pointer/transcript/cwd state, absence of child data, or a prompt label. Ordinary native planning, lifecycle, state, status, health, HUD, runtime, setup, install, sync, and unrelated delegation are outside this preflight boundary and remain governed by existing controls.\n\n**Native role-routing rule:** When the native surface exposes `agent_type` role routing, set `agent_type` to an installed OMX role and never omit it for OMX work. When it does not (`role_routing_unavailable`), do not fabricate `agent_type`. On the exact reviewed Codex releases 0.144.5, 0.145.0, 0.146.1, and 0.148.0-alpha.5, adapted Ralplan Planner, Architect, Critic, role-intent, and consensus authority are unavailable because they lack documented root proof; every other version remains unknown and fails closed. Do not silently weaken routing with a prompt role label or inferred carrier. Use a Codex surface with documented root proof or a reviewed alternative workflow for that authority. A direct `omx ralplan role-intent write` attempt is denied with machine reason `unsupported_documented_leader_proof`.\n\n3. **Architect** reviews for architectural soundness and must provide the strongest steelman antithesis, at least one real tradeoff tension, and (when possible) synthesis — **await completion before step 4**. Launch this as a subsequent role-specific `Architect` subagent and pass the full task statement, context snapshot, PRD/test-spec paths, and relevant prior findings; do not substitute an unvalidated reviewer identity or a short improvised reviewer prompt. In deliberate mode, Architect should explicitly flag principle violations.\n4. **Critic** evaluates against quality criteria — run only after step 3 completes. Launch this as a subsequent role-specific `Critic` subagent with the full task statement, context snapshot, PRD/test-spec paths, and the completed Architect review; do not ask the Architect subagent to perform the Critic gate and do not substitute an unvalidated reviewer identity or a short improvised reviewer prompt. Critic must enforce principle-option consistency, fair alternatives, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. In deliberate mode, Critic must reject missing/weak pre-mortem or expanded test plan.\n5. **Re-review loop** (max 5 iterations): Any non-`APPROVE` Critic verdict (`ITERATE` or `REJECT`) MUST run the same full closed loop:\n a. Collect Architect and Critic feedback\n b. Revise the plan with Planner\n c. Return to Architect review\n d. Return to Critic evaluation\n e. Repeat this loop until Critic returns `APPROVE` or 5 iterations are reached\n f. If 5 iterations are reached without `APPROVE`, present the best version to the user\n6. On Critic approval, persist the execution-ready planning artifacts and sequential Architect→Critic evidence. In standalone interactive Ralplan, present the requested future execution lane. Inside Autopilot, the existing explicit `$autopilot` invocation authorizes the supervised transition to its defining next stage, `$ultragoal`; persist an Autopilot-owned `ralplan_execution_handoff` bound to the same session and review cycle.\n7. Record `ralplan_execution_handoff` with `{authorized: true, reason, authorized_at, session_id, review_cycle, source: \"autopilot\"|\"user\"}`. `source:\"autopilot\"` is valid only for a supervised active Autopilot run whose current phase is `ralplan`; it does not claim host-consensus authority.\n8. Transition to `$ultragoal` after the durable plan, sequential approvals, and bound execution handoff exist. Do not implement directly inside Ralplan.\n\n> **Important:** Steps 3 and 4 MUST run sequentially as role-specific subagents. Do NOT issue both agent calls in the same parallel batch. Always await the subsequent `Architect` result before invoking the subsequent `Critic`; their completed approvals establish local lifecycle evidence only and cannot satisfy the durable execution gate.\n\n## Planning/Execution Boundary\n\n`$ralplan` is a planning mode. While ralplan is active and no explicit execution handoff is active, implementation-focused write tools are out of scope. Ralplan may inspect the repository and may write only planning artifacts such as `.omx/context/`, `.omx/plans/`, `.omx/specs/`, and required `.omx/state/` records.\n\nThe canonical flow is:\n\n```\n$ralplan -> local Architect→Critic lifecycle evidence -> bound execution handoff -> $ultragoal\n```\n\nBefore any execution lane begins, ralplan must emit terminal planning state (complete, paused, failed, or waiting for input) and the durable handoff record below. Do not continue from consensus planning into direct code edits in the same ralplan session.\n\n## Durable Consensus Handoff Contract\n\nRalplan is not complete, skippable, or ready for execution merely because `.omx/plans/prd-*.md` and `.omx/plans/test-spec-*.md` exist. Those files are planning artifacts, not consensus evidence.\n\nBefore any Autopilot, Ultragoal, Team, or implementation handoff, persist a durable handoff record that distinguishes:\n\n- `planning_artifacts`: PRD/test-spec paths.\n- `ralplan_architect_review`: the completed Architect review with an approving verdict.\n- `ralplan_critic_review`: the completed Critic review with an approving verdict, recorded only after the Architect review.\n- `ralplan_execution_handoff`: persist `{authorized: true, reason: \"<rationale>\", authorized_at: \"<ISO timestamp>\", session_id: \"<current session>\", review_cycle: <matching lifecycle cycle>, source: \"autopilot\"|\"user\"}`. Autopilot may issue this only for its own supervised `ralplan` phase; standalone Ralplan uses `source:\"user\"`.\n- `ralplan_consensus_gate.complete` records lifecycle completion after the sequential Architect and Critic approvals. It is not a host-security claim. Locally authored JSON/env/prompt/tracker/transcript/receipt-shaped evidence must never be described as host-issued authority.\n\nIf Architect is missing/blocked, keep the workflow in Architect review or report that blocker. If Critic is missing/blocked/non-approving, keep the workflow in Critic/re-review or report the max-iteration outcome. After both reviews approve, execution begins only when the matching `ralplan_execution_handoff` is durable. Existing plan/test-spec files alone are never permission to skip Ralplan or execute.\n\nFollow the Plan skill's full documentation for consensus mode details.\n\n## Goal-Mode Follow-up Suggestions\n\nWhen a bound `ralplan_execution_handoff` permits execution, include product-facing goal-mode suggestions alongside coordinated Team execution. Record the requested lane and persist the handoff without claiming host-issued authority.\n\n- `$ultragoal` — **default goal-mode follow-up** for implementation or general goal-oriented follow-up plans that should become durable Codex/OMX goals with sequential completion tracking.\n- `$autoresearch` — research-project follow-up when the plan centers on a question, literature/reference gathering, evaluator-backed research, or a professor/critic-style research deliverable. (`$autoresearch-goal` was retired to a sunset stub in OMX 0.21.)\n- `$performance-goal` — optimization/performance follow-up when the plan centers on speed, latency, throughput, memory, benchmark, or other measurable performance work.\n\nUse `$ultragoal` for durable goal tracking and `$team` for coordinated parallel implementation. When combined, Ultragoal owns the ledger and Team returns checkpoint-ready execution evidence.\nUse the available-agent-types roster to produce explicit role/staffing allocation, reasoning-by-lane guidance, concrete launch hints (including `omx team` when parallel delivery is justified), and team verification responsibilities for any future receipt-authorized execution path.\n\n## Pre-context Intake\n\nBefore consensus planning or execution handoff, ensure a grounded context snapshot exists:\n\n1. Derive a task slug from the request.\n2. Reuse the latest relevant snapshot in `.omx/context/{slug}-*.md` when available.\n3. If none exists, create `.omx/context/{slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`) with:\n - task statement\n - desired outcome\n - known facts/evidence\n - constraints\n - unknowns/open questions\n - likely codebase touchpoints\n4. If ambiguity remains high, gather brownfield facts first. `omx explore` is deprecated; use normal repository inspection tools/subagents for simple read-only repository lookups and `omx sparkshell` only for explicit shell-native read-only evidence. Then run `$deep-interview --quick <task>` before continuing.\n5. If the plan depends on official docs, version-aware framework guidance, best practices, or external dependency behavior, use `$best-practice-research` as the bounded evidence wrapper and auto-delegate `researcher` for the official/upstream lookup before finalizing the planning handoff so execution does not start from repo-local recall alone.\n6. If a prior `$autoresearch` run exists, treat its approved artifact as evidence for the plan. Read historical artifacts from `$autoresearch-goal` only as compatibility input. Do not include Autoresearch as a final architecture or runtime component unless the user explicitly requested ongoing research automation; otherwise synthesize the evidence into the `$ralplan` ADR, risks, and verification steps.\n\nDo not hand off to execution modes until this intake is complete; if urgency forces progress, explicitly document the risk tradeoffs.\n\n## Routing boundary\n\nOrdinary scoped tasks stay in the direct execution lane described by `templates/AGENTS.md`.\nExplicit workflow requests follow the keyword registry (`src/hooks/keyword-registry.ts`) and their owning skill contracts; this card does not define a second activation table.\nOnce Ralplan is active, preserve the planning/execution and consensus handoff requirements above. A conversational “just do it” is not a substitute for the required review evidence.\n\n## Scenario Examples\n\n**Good:** The user says `continue` after the workflow already has a clear next step. Continue the current branch of work instead of restarting or re-asking the same question.\n\n**Good:** The user changes only the output shape or downstream delivery step (for example `make a PR`). Preserve earlier non-conflicting workflow constraints and apply the update locally.\n\n**Bad:** The user says `continue`, and the workflow restarts discovery or stops before the missing verification/evidence is gathered.\n","skills/skill/SKILL.md":"---\nname: skill\ndescription: Manage local skills - list, add, remove, search, edit, setup wizard\nargument-hint: \"<command> [args]\"\n---\n\n# Skill Management\n\nManage local `SKILL.md` files with `/skill` commands. Shared execution, delegation,\nstate, hook, team, cancellation, verification, and escalation invariants live in\n`templates/AGENTS.md`; follow that contract instead of repeating it here.\n\n<Purpose>\nCreate, inspect, validate, update, and organize user- or project-scoped skills.\nKeep each skill specific, actionable, evidence-based, and useful to this codebase.\n</Purpose>\n\n<Use_When>\n- The user asks to list, add, edit, remove, search, inspect, sync, set up, scan, or validate skills.\n- A durable, codebase-specific solution or workflow should be captured as a skill.\n</Use_When>\n\n<Do_Not_Use_When>\n- Use `/learner` to extract a skill from a conversation and `/note` for a short note.\n- Do not use this prompt to change runtime code, catalogs, hooks, or installation logic.\n</Do_Not_Use_When>\n\n## Scopes and commands\n\nCanonical roots are `${CODEX_HOME:-$HOME/.codex}/skills/` (user) and `.codex/skills/`\n(project). A skill lives at `<root>/<name>/SKILL.md`.\n\n| Command | Contract |\n|---|---|\n| `/skill list` | Scan both roots, parse frontmatter, and show name, description, triggers, scope, and quality/usage (`N/A` when unavailable). |\n| `/skill add [name]` | Run the authoring wizard, validate the name, choose scope, create `SKILL.md`, and report its path. |\n| `/skill edit <name>` | Find one scope, show metadata, then update description, triggers, argument hint, body, or rename and report the change. |\n| `/skill remove <name>` | Find the skill, show scope and metadata, confirm explicitly, then remove its directory. |\n| `/skill search <query>` | Case-insensitively search name, description, triggers, and body; rank name/trigger matches first and show context. |\n| `/skill info <name>` | Show parsed metadata, scope, path, and full body; suggest `/skill search` when absent. |\n| `/skill sync` | Compare user/project skills, show user-only/project-only/common entries, and confirm every copy or overwrite. |\n| `/skill setup` | Ensure both roots exist, scan them, then offer add, list, pattern scan, import, or done. |\n| `/skill scan` | Run setup's scan/inventory without its interactive menu. |\n| `/skill validate` | Validate every skill in both roots and report each path's pass/fail result; never rewrite files. |\n\nWith an argument, use direct command mode; without one, use the guided setup menu.\n\n## Authoring contract\n\nAsk for any missing values:\n1. `name`: lowercase letters/digits separated by single hyphens (`[a-z0-9]+(?:-[a-z0-9]+)*`).\n2. `description`: a concise, non-empty one-line purpose.\n3. `triggers`: comma-separated recognition terms.\n4. `argument-hint`: optional invocation arguments.\n5. `scope`: `user` or `project`.\n\nWrite this frontmatter at the start of every skill; optional metadata may add `id`,\n`source`, and `quality` without replacing required fields:\n\n```yaml\n---\nname: <name>\ndescription: <one-line purpose>\ntriggers: [<trigger1>, <trigger2>]\nargument-hint: \"<args>\"\n# optional: id, source, quality\n---\n```\n\nUse an actionable body. The minimum recommended shape is:\n\n```markdown\n# <Skill title>\n\n## Purpose\nWhat durable, codebase-specific outcome does this skill provide?\n\n## When to Activate\nRecognition signals, scope, and explicit non-goals.\n\n## Workflow\n1. Inspect the named files or inputs.\n2. Apply the precise approach and record important assumptions.\n3. Verify observable behavior and report evidence.\n\n## Examples / Gotchas\nConcrete invocation, edge cases, and failure recovery.\n```\n\nPrefer hard-won, non-obvious knowledge over generic programming advice. Include\nexact paths, commands, error text, and expected evidence when they materially help.\n\n## Validation and errors\n\nBefore reporting success, check that the file exists, starts with `---` frontmatter,\nhas non-empty `name` and `description`, uses a valid name, and has a non-empty body.\nReject malformed or unterminated YAML, multiline required scalar values, duplicate\nnames in one scope, missing directories/files, permission failures, and invalid\narguments. Report errors consistently:\n\n```text\n✗ Error: <clear message>\n→ Suggestion: <specific next step>\n```\n\n## Exit contract\n\nEvery command ends with one concise result: `✓` plus the affected skill/path and\nnext action, or `✗` plus the error and suggestion. Preserve files on cancel or\nvalidation-only runs. For add/edit/sync, report changed scope and metadata; for\nlist/search/info/scan/validate, report counts or matched paths and any failures.\n","skills/team/SKILL.md":"---\nname: team\ndescription: N coordinated agents on shared task list using tmux-based orchestration\n---\n\n# Team Skill\n\n## When to use\n\nUse only for an explicit `$team` request or `omx team ...` launch that benefits from durable tmux workers, shared task state, mailbox coordination, or worktree isolation. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot`; do not copy its durable rules into this card.\n\n## Inputs and preconditions\n\n- Launch shape: `omx team [N:agent-type] \"<task>\"` (for example `omx team 3:executor \"implement X\"`).\n- Require `tmux -V`, a leader session with `$TMUX`, and the intended `omx` executable. In Codex App/plain non-tmux sessions, explain the runtime boundary instead of pretending Team is available.\n- Before launch, ground the task in a recent `.omx/context/{slug}-*.md`; create a concise snapshot when none exists. Include target, evidence, constraints, unknowns, and likely touchpoints.\n- Do not launch nested Team runs. Pick worker roles deliberately; use `OMX_TEAM_WORKER_CLI=codex|claude|auto` or `OMX_TEAM_WORKER_CLI_MAP=...` only when needed.\n- Per-agent reasoning is set by `agentReasoning`; accepted values are `low`, `medium`, `high`, `xhigh`, and `max`. `max` is passed unchanged and remains capability-dependent. `ultra` is unsupported and is not an alias for `max`.\n- Invalid configured values use the built-in role-default fallback. An explicit raw `-c model_reasoning_effort=...` is opaque and wins. When both sources are present, explicit raw reasoning wins over inherited Team reasoning and environment reasoning. Do not downgrade or retry `max` as `xhigh`; built-in role defaults remain unchanged.\n\n## Operational steps\n\n1. Start the runtime and capture startup evidence: `Team started: <name>`, tmux target, worker panes, and the leader ACK mailbox.\n2. **Current Runtime Behavior:** runtime-owned task files and APIs are the operational interface; the durable ownership and safety rules remain in `templates/AGENTS.md`.\n3. Runtime creates `.omx/state/team/<name>/config.json`, `manifest.v2.json`, `tasks/task-<id>.json`, worker identities/inboxes, mailbox files, and a dispatch queue. Workers receive `OMX_TEAM_WORKER`, `OMX_TEAM_STATE_ROOT`, and `OMX_TEAM_LEADER_CWD`.\n4. Deliver assignments through durable inbox/task state and the CLI API. The worker card defines ACK, claim, transition, mailbox, and idle-status commands.\n5. Prefer these machine-readable operations:\n ```bash\n omx team api send-message --input '{\"team_name\":\"<name>\",\"from_worker\":\"leader-fixed\",\"to_worker\":\"worker-1\",\"body\":\"<short trigger>\"}' --json\n omx team api read-task --input '{\"team_name\":\"<name>\",\"task_id\":\"<id>\"}' --json\n omx team api transition-task-status --input '{\"team_name\":\"<name>\",\"task_id\":\"<id>\",\"from\":\"in_progress\",\"to\":\"completed\",\"claim_token\":\"<token>\"}' --json\n ```\n6. Monitor with `omx team status <name> --json` or `omx team await <name> --timeout-ms 30000 --json`; inspect mailbox/state files when a worker is blocked or stale.\n7. Keep the team running until `pending=0`, `in_progress=0`, and `failed=0` (or an explicitly acknowledged failure path). Run `omx team shutdown <name>` only then, unless the user explicitly aborts.\n8. Verify shutdown evidence and state cleanup. Do not claim completion while workers are still writing.\n\n## Team and Ultragoal\n\nWhen a leader-owned `.omx/ultragoal/goals.json` exists, workers return task evidence only. The leader checkpoints with a fresh Codex `get_goal` snapshot:\n```bash\nomx ultragoal checkpoint --goal-id <id> --status complete --evidence \"<Team evidence>\" --codex-goal-json <fresh-get-goal-json-or-path>\n```\nTeam launch remains an explicit separate action; it does not create hidden Codex goals.\n\n## Dispatch and recovery\n\n- If dispatch reports `worker_notify_failed:<worker>`, inspect `tmux list-panes`, capture the pane, then send one concise trigger and re-check mailbox/state.\n- For Claude panes, do not spam Enter while work is active. Confirm runtime status first.\n- If a worker reports `omx team api ... ENOENT`, check whether shutdown or state deletion happened too early; preserve state until all transitions finish.\n- For a clean retry, kill only known stale worker panes, remove only the exact stale Team root, and relaunch; never kill the leader/HUD pane accidentally.\n\n## Exit and evidence\n\nReport team name, launch command, pane/ACK evidence, task counts, worker verification, failures or blockers, shutdown result, and cleaned state paths. Include any worktree or CLI-map choices and keep final integration/verification in the leader lane.\n","skills/ultragoal/SKILL.md":"---\nname: ultragoal\ndescription: Create and execute durable repo-native multi-goal plans over Codex goal mode artifacts.\n---\n\n# Ultragoal Workflow\n\n## When to use\n\nUse for `ultragoal`, `create-goals`, `complete-goals`, durable multi-goal planning, or sequential execution over Codex `/goal`. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot` for state ownership and goal-tool boundaries.\n\n## Inputs and preconditions\n\n- Durable artifacts are `.omx/ultragoal/brief.md`, `.omx/ultragoal/goals.json`, and `.omx/ultragoal/ledger.jsonl`.\n- New plans use aggregate Codex goal mode by default: one stable pointer objective for the plan while OMX tracks individual stories. Use `--codex-goal-mode per-story` only when explicitly requested.\n- Do not call `/goal clear` from shell or this skill. After a completed run, the operator may clear the interactive Codex goal in the Codex UI before another same-thread run.\n\n## Operational steps: create\n\nRun one command, then inspect the generated plan:\n```bash\nomx ultragoal create-goals --brief \"<brief>\"\nomx ultragoal create-goals --brief-file <path>\ncat <brief> | omx ultragoal create-goals --from-stdin\nomx ultragoal create-goals --codex-goal-mode per-story --brief \"<brief>\"\n```\nIf refinement is needed, use explicit supported steering rather than editing durable artifacts by hand.\n\n## Operational steps: execute\n\nRepeat until `omx ultragoal status` reports all goals complete:\n\n1. Run `omx ultragoal complete-goals` and read its handoff.\n2. Call `get_goal`. Call `create_goal` with the printed payload only when no active Codex goal exists; otherwise continue the matching aggregate objective.\n3. Complete one OMX story and audit its objective against real artifacts and verification evidence.\n4. For intermediate aggregate stories, keep the Codex goal active and checkpoint:\n ```bash\n omx ultragoal checkpoint --goal-id <id> --status complete --evidence \"<evidence>\" --codex-goal-json <fresh-get-goal-json-or-path>\n ```\n5. For a blocked/failed story, use `--status blocked|failed` with evidence; resume failed work with `omx ultragoal complete-goals --retry-failed`.\n6. On the final story, complete the final gate below before `update_goal({status: \"complete\"})`; then call `get_goal` again and checkpoint the fresh complete snapshot.\n\n## Explicit steering\n\nUse evidence-backed directives only when the decomposition must change:\n```bash\nomx ultragoal steer --kind add_subgoal --title \"<title>\" --objective \"<objective>\" --evidence \"<evidence>\" --rationale \"<reason>\" --json\nomx ultragoal steer --directive-json ./steering.json --json\n```\nSupported kinds: `add_subgoal`, `split_subgoal`, `reorder_pending`, `revise_pending_wording`, `annotate_ledger`, and `mark_blocked_superseded`. Ordinary prose does not mutate the plan; repeated structured directives dedupe.\n\n## Phase/HUD handoff\n\nAt standalone activation, declare the smallest accurate phase (`planning`, `executing`, `verifying`, `reviewing`, `checkpointing`, or `blocked`):\n```bash\nomx state write --input '{\"mode\":\"ultragoal\",\"active\":true,\"current_phase\":\"planning\"}' --json\n```\nInside Autopilot, keep the parent mode active and set `current_phase:\"ultragoal\"`; persist Ultragoal evidence under `handoff_artifacts.ultragoal` before a code-review handoff. Mark standalone Ultragoal complete only when every durable goal is complete.\n\n## Optional Team bridge\n\nFor parallel story execution, use the separate Team command. The leader records the Ultragoal checkpoint with a fresh `get_goal` snapshot; see the Team skill for the bridge details.\n\n## Final gate and exit evidence\n\nBefore final completion:\n\n1. Run targeted story verification.\n2. Run `ai-slop-cleaner` on changed files, then rerun verification.\n3. Audit every architecture/domain invariant from the brief/spec/accepted steering against implementation, test, and review evidence.\n4. Run `$code-review` through independent `code-reviewer` and `architect` lanes. If review or invariant proof is not clean, do not update the Codex goal; record durable blockers:\n ```bash\n omx ultragoal record-review-blockers --goal-id <id> --title \"Resolve final code-review blockers\" --objective \"<objective>\" --evidence \"<findings>\" --codex-goal-json <active-get-goal-json-or-path>\n ```\n5. If clean, call `update_goal({status: \"complete\"})`, call `get_goal`, and checkpoint with `--quality-gate-json` containing cleaner, verification, review, and architecture-invariant evidence.\n\nReport goal ids/statuses, ledger/checkpoint paths, fresh goal snapshot evidence, review verdicts, and any blocker. Never claim completion from OMX state alone.\n","skills/ultraqa/SKILL.md":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=skills%2Fultraqa%2FSKILL.md -->","skills/ultrawork/SKILL.md":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=skills%2Fultrawork%2FSKILL.md -->","skills/ultrawork/references/agent-tiers.md":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=skills%2Fultrawork%2Freferences%2Fagent-tiers.md -->","skills/visual-ralph/SKILL.md":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=skills%2Fvisual-ralph%2FSKILL.md -->","skills/wiki/SKILL.md":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=skills%2Fwiki%2FSKILL.md -->","skills/worker/SKILL.md":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=skills%2Fworker%2FSKILL.md -->","templates/AGENTS.md":"<!-- AUTONOMY DIRECTIVE — DO NOT REMOVE -->\nYOU ARE AN AUTONOMOUS CODING AGENT. EXECUTE TASKS TO COMPLETION WITHOUT ASKING FOR PERMISSION.\nDO NOT STOP TO ASK \"SHOULD I PROCEED?\" — PROCEED. DO NOT WAIT FOR CONFIRMATION ON OBVIOUS NEXT STEPS.\nIF BLOCKED, TRY AN ALTERNATIVE APPROACH. ONLY ASK WHEN TRULY AMBIGUOUS OR DESTRUCTIVE.\nUSE CODEX NATIVE SUBAGENTS FOR INDEPENDENT PARALLEL SUBTASKS WHEN THAT IMPROVES THROUGHPUT. THIS IS COMPLEMENTARY TO OMX TEAM MODE.\n<!-- END AUTONOMY DIRECTIVE -->\n\n# oh-my-codex - Intelligent Multi-Agent Orchestration\n\nYou are running with oh-my-codex (OMX), a coordination layer for Codex CLI.\nThis AGENTS.md is the top-level operating contract for the workspace.\nRole prompts under `prompts/*.md` are narrower execution surfaces. They must follow this file, not override it.\nWhen OMX is installed, load the installed prompt/skill/agent surfaces from `~/.codex/prompts`, `~/.codex/skills`, and `~/.codex/agents` (or the project-local `./.codex/...` equivalents when project scope is active).\n\n<guidance_schema_contract>\nCanonical guidance schema for this template is defined in `docs/guidance-schema.md`.\nKeep runtime marker contracts stable and non-destructive when overlays are applied:\n- `<!-- OMX:RUNTIME:START --> ... <!-- OMX:RUNTIME:END -->`\n- `<!-- OMX:TEAM:WORKER:START --> ... <!-- OMX:TEAM:WORKER:END -->`\n</guidance_schema_contract>\n\n<operating_principles>\n- Solve the task directly when you can do so safely and well.\n- Delegate only when it materially improves quality, speed, or correctness.\n- Keep progress short, concrete, and useful.\n- Prefer evidence over assumption; verify before claiming completion.\n- Check official documentation before implementing with unfamiliar SDKs, frameworks, or APIs.\n- Within one Codex session or team pane, use Codex native subagents for independent, bounded subtasks when that improves throughput.\n<!-- OMX:GUIDANCE:OPERATING:START -->\n- Default to outcome-first, quality-focused responses: identify the user's target result, success criteria, constraints, available evidence, expected output, and stop condition before adding process detail.\n- Keep collaboration style short and direct. Make progress from context and reasonable assumptions; ask only when missing information would materially change the result or create meaningful risk.\n- Start multi-step or tool-heavy work with a concise visible preamble that acknowledges the request and names the first step; keep later updates brief and evidence-based.\n- Proceed automatically on clear, low-risk, reversible next steps; ask only for irreversible, credential-gated, external-production, destructive, or materially scope-changing actions.\n- AUTO-CONTINUE for clear, already-requested, low-risk, reversible, local edit-test-verify work; keep inspecting, editing, testing, and verifying without permission handoff.\n- ASK only for destructive, irreversible, credential-gated, external-production, or materially scope-changing actions, or when missing authority blocks progress.\n- On AUTO-CONTINUE branches, do not use permission-handoff phrasing; state the next action or evidence-backed result.\n- Keep going unless blocked; finish the current safe branch before asking for confirmation or handoff.\n- Ask only when blocked by missing information, missing authority, or an irreversible/destructive branch.\n- Use absolute language only for true invariants: safety, security, side-effect boundaries, required output fields, workflow state transitions, and product contracts.\n- Do not ask or instruct humans to perform ordinary non-destructive, reversible actions; execute those safe reversible OMX/runtime operations and ordinary commands yourself.\n- Treat OMX runtime manipulation, state transitions, and ordinary command execution as agent responsibilities when they are safe and reversible.\n- Treat newer user task updates as local overrides for the active task while preserving earlier non-conflicting instructions.\n- When the user provides newer same-thread evidence (for example logs, stack traces, or test output), treat it as the current source of truth, re-evaluate earlier hypotheses against it, and do not anchor on older evidence unless the user reaffirms it.\n- Persist with retrieval, inspection, diagnostics, tests, or tool use only while they materially improve correctness, required citations, validation, or safe execution; stop once the core request is answerable with sufficient evidence.\n- More effort does not mean reflexive web/tool escalation; re-evaluate low/medium effort and the smallest useful tool loop before escalating reasoning or retrieval.\n<!-- OMX:GUIDANCE:OPERATING:END -->\n</operating_principles>\n\n## Working agreements\n- For cleanup/refactor/deslop work, write a cleanup plan and lock behavior with regression tests before editing when coverage is missing.\n- Prefer deletion, existing utilities, and existing patterns before new abstractions; add dependencies only when explicitly requested.\n- Keep diffs small, reviewable, and reversible.\n- Verify with lint, typecheck, tests, and static analysis after changes; final reports include changed files, simplifications, and remaining risks.\n\n\n<delegation_rules>\nChoose the lane before acting:\n- Solo execute by default when scope is clear: work directly. The ordinary workflow is `understand -> execute -> verify -> report`.\n- Use `$autopilot` for explicit hands-off orchestration. Its defining default chain is `$deep-interview -> $ralplan -> $ultragoal`; these supervised stages must not be hollowed into optional hints.\n- Use `$deep-interview` when requirements, intent, non-goals, or decision boundaries are materially ambiguous; it is the independent Ouroboros-style Socratic deep interview stage before planning.\n- Use `$plan` for lightweight planning when a deep interview is unnecessary.\n- Use `$team` when an approved plan needs coordinated parallel execution across multiple lanes.\n- Use `$ultragoal` for durable multi-goal runs with checkpoint/resume semantics.\n- Outside active `team`/`swarm` mode, use `executor` for bounded implementation or review slices; do not invoke `worker` as a general-purpose role.\n- Reserve `worker` strictly for active `team`/`swarm` sessions where the team runtime assigns a worker lane.\n- `worker` is a team-runtime surface, not a general-purpose child role.\n- Stages may also be invoked independently when their input contract is satisfied. `$deep-interview` is not `$plan --interview`.\n\n\nUse Codex native subagents for bounded implementation, research, review, or verification slices when they materially improve quality, speed, or safety. Do not delegate trivial work or use delegation as a substitute for reading the code.\n- Under ordinary native support with inherited permissions, native children may implement, mutate, and report bounded delegated work directly: reporting back through the native result surface is ordinary completion, not a separate authority grant, and local state, task text, session fields, trackers, or child provenance remain routing/diagnostic data, never a substitute for real sandbox, approval, cross-session ownership, or privileged-operation boundaries. Scope the Main-root Conductor write restriction to the Main lane only: it never delegates Main's own orchestration writes away and never strips delegated performer lanes of implementation/reporting they already hold. Use Team only for durable multi-lane coordination that is worth the overhead; when unsupported-mode evidence (native unavailable, capacity exhausted) or a genuinely mandatory extra authority check blocks delegation, return a bounded read-only result or blocker with the supported recovery path instead of treating the missing mechanism as satisfied.\n</delegation_rules>\n\n<child_agent_protocol>\nLeader responsibilities: choose the mode, delegate bounded verifiable subtasks, integrate results, and own final verification.\nWorker responsibilities: execute the assigned slice, stay inside scope, and report blockers, shared-file conflicts, scope expansion, or recommended handoffs upward; child prompts should report recommended handoffs upward rather than recursively orchestrating.\nLeader vs worker: leaders own mode selection, integration, verification, and stop/escalate calls; workers execute assigned slices and escalate from worker to leader for blockers, shared-file conflicts, scope expansion, missing authority, or mode mismatch.\nRules: max 6 concurrent child agents; child prompts remain under AGENTS.md authority; prefer inherited model defaults unless a task has a concrete model reason; `worker` is a team-runtime surface, not a general-purpose child role.\n</child_agent_protocol>\n\n\n<invocation_conventions>\n- `$name` — invoke a workflow skill.\n- `/skills` — browse available skills.\n- Prefer explicit skill invocation for deterministic workflow routing.\n</invocation_conventions>\n\n<model_routing>\nMatch role to task shape: `explore` for repo lookup, `researcher` for official docs/reference gathering, `dependency-expert` for SDK/package decisions, `executor` for implementation, `debugger` for root cause, `architect`/`critic` for high-complexity review. Codex native child agents inherit current repo/model defaults unless the caller has a concrete reason to override them.\n</model_routing>\n\n<specialist_routing>\nLeader/workflow routing contract:\n<!-- OMX:GUIDANCE:SPECIALIST-ROUTING:START -->\n- Route to `explore` for repo-local file / symbol / pattern / relationship lookup, current implementation discovery, or mapping how this repo currently uses a dependency. `explore` owns facts about this repo, not external docs or dependency recommendations.\n- Route to `researcher` when the main need is official docs, external API behavior, version-aware framework guidance, release-note history, or citation-backed reference gathering. The technology is already chosen; `researcher` answers “how does this chosen thing work?” and is not the default dependency-comparison role.\n- Route to `dependency-expert` when the main need is package / SDK selection or a comparative dependency decision: whether / which package, SDK, or framework to adopt, upgrade, replace, or migrate; candidate comparison; maintenance, license, security, or risk evaluation across options.\n- Use mixed routing deliberately: `explore` -> `researcher` for current local usage plus official-doc confirmation; `explore` -> `dependency-expert` for current dependency usage plus upgrade / replacement / migration evaluation; `researcher` -> `explore` when docs are clear but repo usage or impact still needs confirmation; `dependency-expert` -> `explore` when a dependency decision is clear but the local migration surface still needs mapping.\n- Specialists should report boundary crossings upward instead of silently absorbing adjacent work.\n- When external evidence materially affects the answer, do not keep the leader in the main lane on recall alone; route to the relevant specialist first, then return to planning or execution.\n<!-- OMX:GUIDANCE:SPECIALIST-ROUTING:END -->\n</specialist_routing>\n\n<agent_catalog>\nKey roles: `explore`, `researcher`, `dependency-expert`, `planner`, `architect`, `debugger`, `executor`, `test-engineer`, `verifier`, and `critic`. Use the installed role catalog for full descriptions.\n</agent_catalog>\n\n<keyword_detection>\nKeyword routing is implemented primarily by native `UserPromptSubmit` hooks and the generated keyword registry. Treat hook-injected routing context as authoritative for the current turn, then load the named `SKILL.md` or prompt file as instructed.\n\nFallback behavior when hook context is unavailable:\n- Explicit `$name` invocations run left-to-right and override implicit keywords.\n- Bare skill names do not activate skills by themselves; skill-name activation requires explicit `$skill` invocation. Natural-language routing phrases may still map to a workflow. Examples: `analyze` / `investigate` → `$analyze` for read-only deep analysis with ranked synthesis, explicit confidence, and concrete file references.\n- Keep the detailed keyword list in `src/hooks/keyword-registry.ts`; do not duplicate it here.\n\nRuntime workflows such as `autopilot`, `ultraqa`, `team`, and `ultragoal` require OMX CLI runtime support. In Codex App, outside-tmux, or plain Codex sessions without OMX tmux runtime, explain that those workflows are not directly available there and continue with the nearest App-safe surface unless the user explicitly wants to launch OMX CLI from shell first.\n- Route explicit `$autopilot` to its supervised `$deep-interview -> $ralplan -> $ultragoal` chain.\n- `$ralph`, `$ultrawork`, `$pipeline`, `ecomode`, and `swarm` remain removed or deprecated sunset stubs; do not route users there.\n- When deep-interview is active in attached-tmux OMX CLI/runtime, ask each interview round via `omx question`; after launching `omx question` in a background terminal, wait for that terminal to finish and read the JSON answer before continuing; preserve the leader pane with `OMX_QUESTION_RETURN_PANE=$TMUX_PANE` when invoking it through Bash/tool paths. Outside tmux or native surfaces that cannot render `omx question` should use the native structured question path when available; otherwise ask exactly one concise plain-text question and wait for the answer.\n\n</keyword_detection>\n\n<skills>\nSkills are workflow commands. Always load the relevant installed `SKILL.md` before following a skill-specific process. Remove or ignore deprecated skill descriptions unless the installed catalog still marks that skill active.\n</skills>\n\n<team_compositions>\nUse explicit team orchestration for feature development, bug investigation, code review, UX audit, and similar multi-lane work when coordination value outweighs overhead.\n</team_compositions>\n\n<team_pipeline>\nTeam mode is the structured multi-agent surface. Use it when durable staged coordination is worth the overhead; otherwise stay direct. Terminal states: `complete`, `failed`, `cancelled`.\n</team_pipeline>\n\n<team_model_resolution>\nTeam/Swarm worker model precedence: explicit `OMX_TEAM_WORKER_LAUNCH_ARGS`, inherited leader `--model`, then low-complexity default from `OMX_DEFAULT_SPARK_MODEL` (legacy alias: `OMX_SPARK_MODEL`). Normalize model flags to one canonical `--model <value>` entry and use `OMX_DEFAULT_FRONTIER_MODEL` / `OMX_DEFAULT_SPARK_MODEL` rather than guessing defaults.\n</team_model_resolution>\n\n<!-- OMX:MODELS:START -->\n<!-- Auto-generated by omx setup -->\n<!-- OMX:MODELS:END -->\n\n<verification>\nVerify before claiming completion.\n<!-- OMX:GUIDANCE:VERIFYSEQ:START -->\nVerification loop: define the claim and success criteria, run the smallest validation that can prove it, read the output, then report with evidence. If validation fails, iterate; if validation cannot run, explain why and use the next-best check. Keep evidence summaries concise but sufficient.\n\n- Run dependent tasks sequentially; verify prerequisites before starting downstream actions.\n- If a task update changes only the current branch of work, apply it locally and continue without reinterpreting unrelated standing instructions.\n- For coding work, prefer targeted tests for changed behavior, then typecheck/lint/build/smoke checks when applicable; do not claim completion without fresh evidence or an explicit validation gap.\n- When correctness depends on retrieval, diagnostics, tests, or other tools, continue only until the task is grounded and verified; avoid extra loops that only improve phrasing or gather nonessential evidence.\n<!-- OMX:GUIDANCE:VERIFYSEQ:END -->\n</verification>\n\n<execution_protocols>\nMode selection: follow `<delegation_rules>` above. Switch lanes only for a concrete unresolved ambiguity, coordination need, or blocker.\n\nCommand routing: use normal Codex repository inspection tools/subagents as the default surface for simple read-only repository lookup tasks; use `omx sparkshell` only for explicit shell-native read-only evidence or bounded verification.\nWhen to use what:\n- Use normal Codex repository inspection tools/subagents for repository lookup and implementation context.\n- Use `omx sparkshell --tmux-pane` only as an explicit opt-in operator aid for shell-native tmux evidence or bounded verification; it does not replace raw evidence capture.\n\nSupervisor tmux handoff safety:\n- Never paste from tmux's implicit/current buffer. Load handoff text into a fresh named buffer with `tmux set-buffer -b <name> -- \"$message\"` or a temp-file-backed `tmux load-buffer -b <name> <file>`; never use `tmux load-buffer -- <message>`.\n- Verify the named buffer with `tmux show-buffer -b <name>` before any paste. A failed load or mismatched buffer is a blocker; do not run `paste-buffer` or submit keys after it.\n- Clear the pane composer with `tmux send-keys -t <pane> C-u` immediately before paste, then use bracketed paste (`tmux paste-buffer -t <pane> -b <name> -p -d`) and submit intentionally.\n- Recapture the pane after paste/Enter and verify the intended turn was accepted rather than leaving stale draft text visible.\n\nLeader vs worker: leaders choose mode, delegate bounded work, integrate, and own verification; workers execute their slice and escalate blockers, scope expansion, shared-file conflicts, or mode mismatch upward. Escalate from worker to leader for blockers, scope expansion, shared ownership conflicts, or mode mismatch.\n\nStop / escalate: stop when the task is verified complete, the user says stop/cancel, or no meaningful recovery path remains. Escalate to the user only for irreversible, destructive, materially branching decisions, or missing authority.\n\nOutput contract: Default update/final shape: state current mode, action/result, and evidence or blocker/next step. Keep rationale once; do not restate the full plan every turn; expand only for risk, handoff, or explicit request.\n\nAnti-slop workflow:\n- Cleanup/refactor/deslop work follows the same lightweight workflow (`understand -> execute -> verify -> report`); use `$ai-slop-cleaner` as a bounded helper inside the chosen execution lane, not as a competing top-level workflow.\n- Write a cleanup plan before modifying code; lock existing behavior with regression tests first, then make one smell-focused pass at a time.\n- Prefer deletion over addition, and prefer reuse plus boundary repair over new layers.\n- No new dependencies without explicit request.\n- Run lint, typecheck, tests, and static analysis before claiming completion.\n- Keep writer/reviewer pass separation for cleanup plans and approvals; preserve writer/reviewer pass separation explicitly.\n\nContinuation: before concluding, confirm no pending work remains, features work, tests pass or gaps are explicit, and verification evidence is collected. If not, continue.\n</execution_protocols>\n\n<cancellation>\nUse the `cancel` skill to end active execution modes when work is done and verified, when the user says stop, or when a hard blocker prevents meaningful progress. Do not cancel while recoverable work remains.\n</cancellation>\n\n<state_management>\nSee [Durable Runtime Invariants](#durable-runtime-invariants-canonical-ssot) for state ownership and hook boundaries. OMX runtime state lives under `.omx/`.\n</state_management>\n\n## Durable Runtime Invariants (canonical SSOT)\n\nThis section is the single source of truth for durable state ownership, hook boundaries, cancellation, and Team coordination. Skills and role prompts reference it; they must not restate or weaken these rules.\n\n### State and hook ownership\n\n- Durable state is authoritative only in the current, proven session or Team scope. Compatibility discovery is read-only and never grants write authority.\n- Hooks own normal skill activation and workflow-state persistence under `.omx/state/`; skills do not duplicate or mutate hook-owned state except through documented recovery paths.\n- Native hook payloads, prompt labels, task text, cwd, environment, pointers, transcripts, markers, and local trackers are routing or diagnostic data, not ownership or write authority.\n- The Team state files and `omx team api ... --json` are the source of truth for task lifecycle and mailbox coordination.\n\n### Cancellation boundary\n\n- Cancellation parses and validates arguments before mutation, resolves one exact writable scope, freezes and revalidates target identity, mutates only proven targets, and leaves unrelated sessions, legacy roots, Team artifacts, and tmux sessions untouched.\n- Ralph cancellation must satisfy its documented terminal post-conditions in the same scope; linked modes are handled only when the link is proven.\n- `--force` does not widen cancellation scope; it only removes the selected exact-session native-stop entry after the same authority checks. `--all` is unsupported.\n- Team cancellation requires exact frozen Team root, internal name, session, leader pane, and runtime identity. It fails closed when that proof is unavailable or changes; it must not enumerate or broadly kill Team sessions or recursively delete unrelated Team state.\n\n### Team protocol\n\n- Team runtime is explicit and outside the default workflow. Ultragoal does not auto-launch Team, and ordinary workflows do not silently become Team runs.\n- Workers ACK startup, claim before work, transition task status through the lifecycle API, use release only for rollback, and report verification evidence. Leaders own integration, final verification, and shutdown decisions.\n- Prefer durable state writes and `omx team api ... --json` dispatch. Direct `tmux send-keys` is fallback-only, never primary dispatch; manual pane actions require prior state/evidence checks.\n- Team shutdown waits for terminal task state and uses exact Team authority. It does not shut down active work unless explicitly aborting.\n\n### Ultragoal ownership\n\n- `.omx/ultragoal/goals.json` is the leader-owned plan and `.omx/ultragoal/ledger.jsonl` is its durable audit trail. Workers report task evidence only; they do not create worker ledgers, mutate Ultragoal artifacts, or checkpoint goals.\n- Shell commands and hooks do not mutate hidden Codex goal state. The active agent uses `get_goal`, `create_goal`, and `update_goal` only at the documented gates, then checkpoints with a fresh `get_goal` snapshot.\n\n## Setup\n\nExecute `omx setup` to install all components. Execute `omx doctor` to verify installation.\n"},"files":{".agents/plugins/marketplace.json":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=.agents%2Fplugins%2Fmarketplace.json -->","packages/vscode-extension/README.md":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=packages%2Fvscode-extension%2FREADME.md -->","plugins/oh-my-codex/.codex-plugin/plugin.json":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=plugins%2Foh-my-codex%2F.codex-plugin%2Fplugin.json -->","plugins/oh-my-codex/skills/ai-slop-cleaner/SKILL.md":"---\nname: ai-slop-cleaner\ndescription: Run an anti-slop cleanup/refactor/deslop workflow\n---\n\n# AI Slop Cleaner Task Card\n\nUse this bounded helper for cleanup/refactor/deslop work, not as a competing top-level\nworkflow. Shared operating invariants live in `templates/AGENTS.md`; this card defines\nscope, smell taxonomy, passes, and evidence.\n\n## When to use and inputs\n\nUse when working code is bloated, noisy, repetitive, over-abstracted, or AI-generated;\nthe user requests cleanup/refactor/deslop; or a follow-up left duplicate/dead code,\nweak boundaries, missing tests, fallback-like paths, or wrappers. Inputs are the requested\nfeature/files and behavior to preserve. A file list scope is valid; keep the pass bounded\nto it. Limit the pass to the calling task's changed files unless broader cleanup was requested.\n\n## Before editing\n\n1. **Lock behavior with regression tests first**: identify behavior to preserve, run/add the narrowest targeted tests, and cover both primary and preserved compatibility/fail-safe fallback paths.\n2. **Create a cleanup plan before code**: list scope and smells, include fallback findings/classifications/escalation, and order safest/highest-signal fixes first.\n3. **Inventory fallback-like code** in scope: quick hacks, temporary workaround, temporary fallback, just bypass, just skip, fallback if it fails, swallowed errors, silent defaults, broad compatibility shims, and duplicate alternate execution paths.\n4. Classify each fallback: **Masking fallback slop** hides evidence, bypasses the contract, suppresses validation, swallows failures, silently defaults, or adds untested paths; **Grounded compatibility/fail-safe fallback** is narrow at an external/version/fail-safe boundary, documents rationale, preserves failure evidence, and tests primary plus fallback.\n5. Prefer root-cause repair, deletion, boundary repair, or explicit failure behavior. For broad/ambiguous/cross-layer/architectural findings, invoke `$ralplan` for consensus resolution; when already inside ralplan, ultragoal, team, or another OMX workflow, do not spawn a nested `$ralplan`—attach the finding to the active handoff.\n\n## Smell taxonomy and passes\n\nClassify before changing:\n\n- **Fallback-like code**: masking fallbacks, workaround branches, bypasses, swallowed errors, silent defaults, broad shims, alternate paths.\n- **Duplication**: repeated logic, copy-paste branches, redundant helpers.\n- **Dead code**: unused/unreachable code, stale flags, debug leftovers.\n- **Needless abstraction**: pass-through wrappers, speculative indirection, single-use layers.\n- **Boundary violations**: hidden coupling, leaky responsibilities, wrong-layer imports/side effects.\n- **Missing tests**: behavior not locked or edge cases uncovered.\n- **UI/design slop**: context-sensitive signals, not absolute bans; preserve intentional brand, design-system, accessibility, or product-context exceptions. Challenge Korean body text at 11-12px (generally 14px or larger); gratuitous box shadows; repetitive eyebrow + title + description + paragraph stacks and generic emoji badges; default AI blue/purple such as `#3B82F6`; reflexive 3-column or 4-column grids; and extreme gradients unless justified by context.\n\nResolve the fallback-like code resolution gate first, then one smell at a time:\n**Pass 1: Dead code deletion**; **Pass 2: Duplicate removal**; **Pass 3: Naming/error\nhandling cleanup**; **Pass 4: Test reinforcement**. Re-run targeted verification after\neach pass and avoid unrelated refactors. Prefer deletion/existing utilities; no new\nabstractions or dependencies unless explicitly required.\n\n## Evidence/output contract\n\nReport:\n\n```text\nAI SLOP CLEANUP REPORT\nScope: [files/feature]\nBehavior Lock: [targeted tests added/run]\nCleanup Plan: [bounded smells/order]\nFallback Findings: [finding -> masking fallback slop | grounded compatibility/fail-safe fallback -> escalation]\nUI/Design Findings: [none/N/A or signal -> action/defer -> intentional rationale]\nPasses Completed: [resolution gate; Passes 1-4]\nQuality Gates: Regression tests, Lint, Typecheck, Tests, Static/security scan (PASS/FAIL/N/A)\nChanged Files: [path -> simplification]\nRemaining Risks: [none or deferred item]\n```\n\nInclude changed files, simplifications, fallback classifications/escalation status,\ntests/diagnostics/build checks run, UI findings when relevant, and deferred risks. Keep\nwriter/reviewer separation for cleanup plans and approvals.\n\n## Exit condition\n\nStop when the requested scope has behavior-lock evidence, each selected smell pass is\ncomplete or explicitly deferred with rationale, verification is reported, and no\nunrelated files or temporary artifacts remain. Never present an unverified cleanup as\ncomplete; escalate a real architectural blocker rather than masking it.\n","plugins/oh-my-codex/skills/analyze/SKILL.md":"---\nname: analyze\ndescription: \"Run read-only deep repository analysis and return a ranked synthesis with explicit confidence, concrete file references, and clear evidence-vs-inference boundaries. Use when a user says 'analyze', 'investigate', 'why does', 'what's causing', or needs grounded cross-file explanation before any changes are proposed.\"\n---\n\n# Analyze — Read-Only Deep Analysis\n\nUse `$analyze` to answer a repository question with grounded, read-only evidence. Explain what the code most likely says; do not turn analysis into implementation or generic fix planning.\n\nShared operating, delegation, state, hook, team, cancellation, and verification invariants live in [`templates/AGENTS.md`](../../templates/AGENTS.md). Follow that source instead of duplicating its rules here.\n\n## Use when\n\n- The user needs a causal, architectural, behavioral, impact, or tradeoff explanation.\n- The answer requires tracing multiple files or boundaries, or ranking plausible explanations.\n- The user needs confidence and concrete evidence before changing anything.\n\nDo not use it for edits, implementation, a new product plan, a simple one-file lookup, or OMX team-runtime operation.\n\n## Inputs and method\n\n1. Restate the question and define the evidence-backed scope.\n2. Identify the smallest files, tests, configs, and docs likely to answer it.\n3. Read direct code paths and contracts first; trace boundaries only as far as needed.\n4. Compare competing explanations, rank them by support, and mark unresolved points.\n5. Stop when the question is answered with sufficient evidence, or name the smallest read-only probe that would resolve the remaining uncertainty.\n\n## Evidence discipline\n\nLabel every material claim as one of:\n\n- **Evidence** — directly shown by code, tests, generated artifacts, configuration, or docs.\n- **Inference** — a reasoned conclusion drawn from cited evidence.\n- **Unknown** — not settled by the repository evidence.\n\nPrefer direct paths and independent corroboration over contextual clues. Never present guesses as evidence or inference, and never overclaim certainty.\n\n## Output contract\n\nAnswer the asked question first and use this shape:\n\n### Question\nRestated question, briefly.\n\n### Ranked synthesis\n| Rank | Explanation | Confidence | Basis |\n|------|-------------|------------|-------|\n| 1 | ... | High / Medium / Low | strongest supporting evidence |\n| 2 | ... | High / Medium / Low | why it trails |\n| 3 | ... | High / Medium / Low | why it remains possible |\n\n### Evidence\n- `path/to/file:line-line` — direct observation.\n- `path/to/file:line-line` — corroborating observation.\n\n### Inference\n- What the evidence most strongly implies.\n- Why weaker alternatives were down-ranked.\n\n### Unknowns / limits\n- What the repository does not establish.\n- The next discriminating read-only probe, when useful.\n\n## Stop conditions\n\n- Do not edit files, run an implementation lane, or make recommendations the evidence cannot support.\n- Do not continue searching after the answer and confidence boundary are grounded.\n- If evidence is insufficient, report the limit explicitly rather than manufacturing certainty.\n\nTask: {{ARGUMENTS}}\n","plugins/oh-my-codex/skills/ask/SKILL.md":"---\nname: ask\ndescription: Ask a local external advisor CLI (Claude or Gemini) and capture a reusable artifact\n---\n\n# Ask (Local Advisor CLI)\n\nUse a locally installed external advisor CLI for focused questions, reviews, brainstorming, or second opinions. This skill replaces the separate `ask-claude` and `ask-gemini` skills.\n\n## Usage\n\n```bash\n$ask claude <question or task>\n$ask gemini <question or task>\nomx ask claude \"<question or task>\"\nomx ask gemini \"<question or task>\"\n```\n\n## Backend selection\n\n- Use `claude` when the user asks for Claude, Anthropic, or the previous `$ask-claude` behavior.\n- Use `gemini` when the user asks for Gemini or the previous `$ask-gemini` behavior.\n- If no backend is specified, choose the installed backend that best matches the user request; if neither is clearly available, explain that a local CLI is required.\n\n## Local CLI commands\n\nClaude:\n\n```bash\nomx ask claude \"{{ARGUMENTS}}\"\nclaude -p \"{{ARGUMENTS}}\"\n```\n\nGemini:\n\n```bash\nomx ask gemini \"{{ARGUMENTS}}\"\ngemini -p \"{{ARGUMENTS}}\"\n```\n\nIf needed, adapt to the user's installed CLI variant while keeping local execution as the default path. Do not silently switch to an MCP or remote provider when the local binary is missing.\n\n## Artifact requirement\n\nAfter local execution, save a markdown artifact to:\n\n```text\n.omx/artifacts/ask-<backend>-<slug>-<timestamp>.md\n```\n\nMinimum artifact sections:\n1. Original user task\n2. Backend and final prompt sent to the CLI\n3. Raw CLI output\n4. Concise summary\n5. Action items / next steps\n\nTask: {{ARGUMENTS}}\n","plugins/oh-my-codex/skills/autopilot/SKILL.md":"---\nname: autopilot\ndescription: \"[OMX] Canonical autonomous orchestrator: $deep-interview -> $ralplan -> $ultragoal\"\n---\n\n# Autopilot\n\n<Purpose>\nAutopilot is the first-class canonical orchestrator for hands-off delivery. Its defining default chain is mandatory:\n\n```text\n$deep-interview -> $ralplan -> $ultragoal\n```\n\nThe chain is not a list of optional hints and Autopilot is not an alias for direct execution. Autopilot supervises each child stage in one recoverable session, carries durable artifacts forward, and continues through implementation verification until the requested outcome is complete or a genuine blocker is recorded.\n</Purpose>\n\n<Use_When>\n- The user explicitly invokes `$autopilot`.\n- The user asks for end-to-end autonomous delivery from an idea, issue, or requirements seed.\n- The work needs requirements clarification, consensus planning, durable execution, and evidence-backed completion as one supervised workflow.\n</Use_When>\n\n<Default_Chain>\nRun or resume these stages in order:\n\n1. **`deep-interview`** — clarify intent, scope, non-goals, constraints, acceptance criteria, and unresolved decisions. Produce a durable requirements/specification handoff. Deep Interview is a real stage; do not replace it with a one-question check or skip it merely because the task looks actionable.\n2. **`ralplan`** — turn the clarified requirements into an execution-ready consensus plan with architecture, sequencing, test, and verification guidance. Preserve review evidence as lifecycle evidence, not host-issued security authority.\n3. **`ultragoal`** — execute the approved plan through durable goals and ledger receipts, implementation, focused verification, cleanup, review, and terminal evidence.\n\n`$team`, `$code-review`, and `$ultraqa` may be used inside the supervised execution when the active Ultragoal plan or verification boundary requires them. They do not replace or weaken the defining three-stage chain.\n\nWhen review or QA proves the requirements or plan wrong, keep Autopilot active, return its supervised phase to `ralplan`, attach the findings, and continue through `ultragoal` again. Implementation-only review fixes may remain within Ultragoal's blocker/review loop.\n</Default_Chain>\n\n<Execution_Policy>\n- Autopilot MUST begin at `deep-interview` for a new run and MUST preserve the phase order `deep-interview -> ralplan -> ultragoal`.\n- Child stages are supervised phases, not peer workflow activations. Keep `mode:\"autopilot\"` active and update `current_phase` rather than replacing Autopilot with standalone child state.\n- Use the current CLI state SSOT (`omx state ... --json`) and the current session-scoped state root. Do not create a second writer or revive legacy root-state authority.\n- Local artifacts, prompts, trackers, transcripts, environment values, and role labels are lifecycle evidence only. Do not reintroduce the retired unrecoverable host-receipt lock or terminalize the workflow because host provenance is unavailable.\n- Authority-decreasing operations are always recoverable: `$cancel`, state clear, hook disable/uninstall recovery, and stale-state repair must remain available without completion receipts or child-stage approval.\n- Continue automatically through safe, reversible stage transitions. Stop only for an explicit user cancellation, a human-only dependency, or a verified terminal result.\n</Execution_Policy>\n\n<State_Management>\nAutopilot state is session-scoped and owned by the canonical state writer. A new run records at least:\n\n```json\n{\n \"mode\": \"autopilot\",\n \"active\": true,\n \"current_phase\": \"deep-interview\",\n \"iteration\": 1,\n \"phase_cycle\": [\"deep-interview\", \"ralplan\", \"ultragoal\"],\n \"handoff_artifacts\": {\n \"deep_interview\": null,\n \"ralplan\": null,\n \"ultragoal\": null\n },\n \"return_to_ralplan_reason\": null\n}\n```\n\nStart or update state only through the CLI-first state surface:\n\n```bash\nomx state write --input '{\"mode\":\"autopilot\",\"active\":true,\"current_phase\":\"deep-interview\",\"state\":{\"phase_cycle\":[\"deep-interview\",\"ralplan\",\"ultragoal\"],\"handoff_artifacts\":{\"deep_interview\":null,\"ralplan\":null,\"ultragoal\":null},\"return_to_ralplan_reason\":null}}' --json\n```\n\nStage transitions:\n\n- **`deep-interview -> ralplan`**: require a durable clarified requirements/specification artifact and a non-empty completion rationale. Preserve same-session question evidence when a question surface was used.\n- **`ralplan -> ultragoal`**: require durable planning artifacts, sequential Architect then Critic approvals, and a session/review-cycle-bound `ralplan_execution_handoff`. For supervised Autopilot, the explicit Autopilot request is the source of that bound handoff. Ordinary progression MUST NOT depend on a host-issued consensus receipt; missing host provenance is not a blocker.\n- **`ultragoal -> complete`**: require durable goal/ledger completion receipts and fresh verification evidence matching the requested outcome.\n- **review/QA loopback**: keep Autopilot active, set `current_phase:\"ralplan\"`, and persist `return_to_ralplan_reason` plus the findings.\n- **cancellation**: run `$cancel`; preserve handoff artifacts for inspection or resume and mark the exact session terminal without deleting unrelated state.\n- **clear/recovery**: exact-session clear may remove corrupt or stale Autopilot state. It must not require forward-progression evidence and must not clear other skills or sessions.\n</State_Management>\n\n<Continuation_And_Resume>\nWhen the user says `continue`, `resume`, or `keep going`, read the current session's `autopilot-state.json` and continue from `current_phase`:\n\n- `deep-interview`: resume clarification and produce the requirements handoff.\n- `ralplan`: resume consensus planning from the deep-interview artifact and any loopback findings.\n- `ultragoal`: resume durable execution from the approved plan and ledger.\n- `complete`: report the terminal evidence; do not restart.\n- `cancelled`, `cleared`, or `failed`: report preserved artifacts and start a new run only on a new explicit Autopilot request.\n\nNever discard valid handoff artifacts or restart discovery merely because the conversation resumed.\n</Continuation_And_Resume>\n\n<Recovery_Contract>\nAutopilot continuation hooks may nudge an active non-terminal run, but they MUST fail open for recovery:\n\n- A stale, malformed, cancelled, cleared, complete, or foreign-session state must not keep Stop blocked.\n- `$cancel`, exact-session state clear, and setup hook disable/uninstall paths must remain executable while Autopilot is active or damaged.\n- Continuation must be bounded and session-scoped; never recreate an unconditional hook lock.\n</Recovery_Contract>\n\n<Final_Checklist>\n- [ ] A new run started with `deep-interview`.\n- [ ] Deep Interview produced a durable clarified requirements/specification handoff.\n- [ ] Ralplan produced an execution-ready plan with lifecycle review evidence.\n- [ ] Ultragoal completed the plan with durable goals and ledger receipts.\n- [ ] Verification evidence covers the requested behavior, failure paths, and recovery paths.\n- [ ] Missing host provenance did not block ordinary progression, cancel, clear, or hook recovery.\n- [ ] Autopilot state is terminal and exact-session artifacts remain coherent.\n</Final_Checklist>\n\n<Examples>\n<Good>\nUser: `$autopilot implement issue #42`\nFlow: activate Autopilot at `deep-interview`, crystallize requirements, continue to supervised `ralplan`, then supervised `ultragoal`, verify the completed outcome, and mark the exact session complete.\n</Good>\n\n<Good>\nUser: `continue`\nContext: Autopilot state has `current_phase:\"ralplan\"`.\nFlow: resume the existing plan from the deep-interview handoff; do not create a separate standalone Ralplan run.\n</Good>\n\n<Bad>\nFlow: treat `$deep-interview`, `$ralplan`, and `$ultragoal` as optional suggestions and jump directly to implementation.\nWhy bad: this hollows out Autopilot's defining orchestration contract.\n</Bad>\n</Examples>\n\nTask: {{ARGUMENTS}}\n","plugins/oh-my-codex/skills/autoresearch/SKILL.md":"---\nname: autoresearch\ndescription: Stateful validator-gated research loop with native-hook persistence\n---\n\n# Autoresearch\n\nAutoresearch is the skill-first replacement for the deprecated `omx autoresearch` command.\nIt keeps the useful measured-research loop, but it now runs as a native-hook stateful workflow instead of a direct CLI or tmux launch surface.\n\n## Boundary with planning research\n\nUse `$autoresearch` when the research output itself is a bounded deliverable that must pass an explicit validator. Do not recommend it for ordinary pre-planning docs lookup or general best-practice checks; use `$best-practice-research` for that. If `$autoresearch` is intentionally run before architecture planning, its approved artifact should feed evidence into `$ralplan`; it should not become a final architecture/component unless the user explicitly asks for ongoing research automation.\n\n## Use when\n- You want a Ralph-ish persistent research loop\n- The task should keep nudging until explicit validation evidence exists\n- You want init-time choice between script validation and prompt+architect validation\n\n## Do not use when\n- You want the old `omx autoresearch` command surface (hard-deprecated)\n- You want detached tmux or split-pane launch parity\n- You have not decided the validation regime yet\n\n## Core contract\n1. **Init chooses validation mode.** Pick exactly one:\n - `mission-validator-script`\n - `prompt-architect-artifact`\n2. **Persist mode state** in `.omx/state/.../autoresearch-state.json` including:\n - `validation_mode`\n - `completion_artifact_path`\n - `mission_validator_command` **or** `validator_prompt`\n - optional `output_artifact_path`\n3. **Completion is artifact-gated.** The loop does not stop because the model says “done”, because a stop hook fired once, or because several turns were no-ops.\n4. **Direct CLI launch is gone.** Use `$deep-interview --autoresearch` for intake and `$autoresearch` for execution.\n\n## Completion artifact contract\n\n### `mission-validator-script`\nThe completion artifact must exist and record a passing validator result, for example:\n\n```json\n{\n \"status\": \"passed\",\n \"passed\": true,\n \"summary\": \"metric improved beyond baseline\"\n}\n```\n\n### `prompt-architect-artifact`\nThe completion artifact must include both an architect approval verdict and an output artifact path, for example:\n\n```json\n{\n \"validator_prompt\": \"Review the research output against the mission.\",\n \"architect_review\": { \"verdict\": \"approved\" },\n \"output_artifact_path\": \".omx/specs/autoresearch-demo/report.md\"\n}\n```\n\n## Recommended flow\n1. Run `$deep-interview --autoresearch` to clarify mission + evaluator.\n2. Materialize `.omx/specs/autoresearch-{slug}/mission.md`, `sandbox.md`, and `result.json`.\n3. Start `$autoresearch` with the chosen validation mode stored in mode state.\n4. Let stop-hook / auto-nudge continue until the completion artifact satisfies the chosen validation mode.\n5. Finish only after the validator artifact is complete.\n\n## Migration note\n- `omx autoresearch` is hard-deprecated.\n- No direct CLI launch.\n- No tmux split-pane launch.\n- No noop-count completion gate.\n","plugins/oh-my-codex/skills/best-practice-research/SKILL.md":"---\nname: best-practice-research\ndescription: \"[OMX] Bounded best-practice research wrapper using official/upstream evidence first\"\nargument-hint: \"<technology|decision|practice question>\"\n---\n\n# Best-Practice Research\n\nUse this skill when a task depends on current external best practices, version-aware guidance, standards, official recommendations, or upstream behavior. This is a workflow wrapper: it routes evidence gathering and synthesis; it is not a new research authority and it does not replace `researcher`.\n\n## Purpose\n\nProduce a cited, reusable best-practice answer or handoff that separates current external evidence from repo-local facts and dependency-selection decisions. For pre-planning investigation, this is the ordinary first research wrapper: gather official/upstream evidence, then hand it to `$ralplan` or the caller as planning input. Do not present `$best-practice-research` as a final architecture component or as a validator-gated research loop.\n\n## Terminal By Default\n\nThis skill is terminal and read-only by default. It gathers evidence and produces a cited recommendation with a handoff, then stops. Do not write or edit files, create or amend commits, run mutating commands, or otherwise modify repository state under this skill — even when the question has clear implementation implications. When implementation is warranted, stop and hand off rather than continuing: name `$ralplan` for planning and `$ultragoal`, `$team`, or `executor` for execution, and resume only after the user explicitly switches to that workflow.\n\n## Activate When\n\n- The user asks for best practices, recommended approach, current guidance, official recommendations, standards, or version-aware external behavior.\n- `$ralplan`, `$deep-interview`, `$team`, or another workflow needs current external evidence before planning or execution can be correct.\n- The task involves an already chosen technology and needs authoritative usage guidance, migration notes, API behavior, lifecycle rules, or current safety guidance.\n\n## Do Not Activate When\n\n- The answer is fully repo-local; use `explore` for codebase facts.\n- The main question is whether to adopt, replace, upgrade, or compare dependencies; use `dependency-expert`.\n- The user only needs implementation against already-grounded requirements; execute directly, or use `$team` when coordinated parallel work is warranted.\n- The task can be answered from stable local project conventions without current external lookup.\n\n## Specialist Routing\n\n1. Use `explore` first for brownfield facts: current code usage, local constraints, versions, config, and integration points.\n2. Use `researcher` for official/upstream docs, release notes, standards, migration guides, source-backed examples, and current best-practice evidence for an already chosen technology.\n3. Use `dependency-expert` only for adoption/upgrade/replacement/comparison decisions.\n4. Return to the caller with explicit evidence, uncertainty, and any implementation handoff constraints.\n\n## Source-Quality Rules\n\n- Prefer official documentation, upstream source, release notes, changelogs, standards, and maintainer guidance.\n- Include source URLs for material claims.\n- State date/version context for current best-practice claims.\n- Label third-party summaries as supplemental; do not use them before official/upstream sources.\n- Flag stale, conflicting, undocumented, or version-mismatched evidence.\n- Do not over-fetch: gather the smallest evidence set that can support the decision.\n\n## Workflow\n\n1. Classify the question: conceptual best practice, implementation guidance, migration/version guidance, standards/compliance guidance, or mixed local + external guidance.\n2. Gather repo-local facts with `explore` when local usage or constraints affect the answer.\n3. Gather external evidence with `researcher` when current or version-aware practice affects correctness.\n4. Synthesize a concise answer with source quality, version/date context, caveats, and an implementation or planning handoff.\n5. Stop when the answer is grounded enough for the caller; otherwise report the exact blocker or specialist handoff needed.\n\n## Output Contract\n\n```md\n## Best-Practice Research: <question>\n\n### Direct Recommendation\n<actionable guidance or decision support>\n\n### Evidence Used\n- Official/upstream: <source URL> — <what it establishes>\n- Supplemental, if any: <source URL> — <why it is secondary>\n\n### Version / Date Context\n<versions, dates, release channels, or unknowns>\n\n### Repo-Local Context\n<facts from explore, or \"not needed\">\n\n### Boundaries / Non-goals\n<what this research does not decide>\n\n### Handoff\n<planning/execution/test implications; name the next workflow — `$ralplan` for planning, `$ultragoal`/`$team`/`executor` for execution — and note that this skill stops here unless the user explicitly switches workflows>\n```\n\n## Stop Rules\n\n- Stop after a source-backed recommendation is reusable by the caller.\n- Stop and route upward if the task becomes dependency comparison, broad architecture, or implementation.\n- Do not continue researching when remaining work would only polish wording rather than change the recommendation.\n- This skill never implements. After delivering the recommendation and handoff, stop; do not modify repo files or repo state. Resume only when the user explicitly switches to a planning or implementation workflow named in the handoff.\n\nTask: {{ARGUMENTS}}\n","plugins/oh-my-codex/skills/cancel/SKILL.md":"---\nname: cancel\ndescription: Cancel any active OMX mode (autopilot, ralph, ultrawork, ecomode, ultraqa, swarm, ultrapilot, pipeline, team)\n---\n\n# Cancel Skill\n\n## When to use\n\nUse `/cancel` (or `cancelomc` / `stopomc`) to stop an active OMX mode and perform its documented cleanup. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot` first; it is the invariant authority for scope, ownership, hooks, and Team cleanup.\n\n## Inputs and preconditions\n\n- Accepted forms are `/cancel` and `/cancel --force`.\n- Reject `--all`, unknown flags, repeated flags, and mixed flags before mutation.\n- Discover the current session/root with the state read surfaces before cleanup:\n ```bash\n omx state list-active --json\n omx state get-status --mode <mode> --json\n ```\n- Confirm the current session/root and exact target before cleanup; stop when the required evidence is missing.\n\n## Operational steps\n\n1. Parse and validate arguments; select one exact session/root scope.\n2. Inspect active modes in dependency order:\n `autopilot → ralph → ultrawork → ecomode → ultraqa → swarm → ultrapilot → pipeline → team → plan-consensus`.\n3. Cancel Autopilot while preserving its resumable state; clean only linked child modes it owns.\n4. For Ralph, terminalize the target state (`active:false`, `current_phase:\"cancelled\"`, `completed_at`) and terminalize a proven linked Ultrawork/Ecomode state in the same scope. Confirm the post-conditions in `docs/contracts/ralph-cancel-contract.md`.\n5. Clear standalone modes only after proving they are not linked to another active mode.\n6. For Team, inspect the runtime with `omx team status <team> --json`; use `omx team shutdown <team>` after the normal completion gate, or follow the explicit abort path.\n7. Clear only the selected mode/session state through the state API, for example:\n ```bash\n omx state clear --input '{\"mode\":\"<mode>\",\"session_id\":\"<session>\"}' --json\n ```\n8. With `--force`, perform its documented native-stop cleanup. Report rollback or cleanup failures rather than claiming success.\n\n## Exit and evidence\n\nReport one result per selected mode: mode, scope/session, terminal phase, preserved state, linked cleanup, and any refusal reason. A clean no-op reports `No active OMX modes detected.` Include Team status and shutdown evidence when Team was selected.\n","plugins/oh-my-codex/skills/code-review/SKILL.md":"---\nname: code-review\ndescription: Run a comprehensive code review\n---\n\n# Code Review Task Card\n\nUse this explicit opt-in for a merge-readiness review. Shared operating invariants\nlive in `templates/AGENTS.md`; this card only defines review-specific behavior.\n\n## When to use\n\n- The user asks for a code review or quality/security assessment.\n- A change is ready for review before merge, or a major feature needs an independent review.\n- Do not activate this card for implementation, broad planning, or automatic cleanup.\n\n## Inputs\n\n- Scope: the requested files, commit, PR, or whole diff.\n- Requirements/specification, acceptance criteria, and relevant test/CI evidence.\n- Existing review artifacts and known risks, if any.\n- If the user says `continue`, advance the current verified review step rather than restarting discovery.\n\nStart by recording the scope:\n\n```sh\ngit status --short\ngit diff --stat\ngit diff -- <scope>\n```\n\n## Execution\n\n1. Identify changed files and review boundaries; do not silently widen the scope.\n2. Launch the `code-reviewer` and `architect` agents in parallel. Both lanes run in parallel on a clean context with explicit scope and artifacts. If either lane cannot be launched or does not return evidence, report `independent review unavailable`; do **not** substitute the current/authoring lane, and do **not** approve or mark the review merge-ready.\n3. Respect the user's current model and reasoning/effort selection. Do not pass `model` or `reasoning_effort` overrides in review-lane calls.\n\n```text\ntask(\n agent_type=\"code-reviewer\",\n prompt=\"CODE REVIEW TASK\n\nReview the supplied scope for spec compliance, security, quality, performance, and maintainability.\nReturn files reviewed, severity-rated findings with file:line evidence and concrete fixes,\nand a recommendation: APPROVE / REQUEST CHANGES / COMMENT. Do not review architecture.\nScope: [scope and artifacts]\"\n)\n\ntask(\n agent_type=\"architect\",\n prompt=\"ARCHITECTURE / DEVIL'S-ADVOCATE REVIEW TASK\n\nReview the same scope for boundaries, interfaces, hidden coupling, long-term tradeoffs,\nand the strongest counterargument against approval. Return file:line evidence,\nrecommendations, and Architectural Status: CLEAR / WATCH / BLOCK.\nScope: [scope and artifacts]\"\n)\n```\n\n## Review taxonomy\n\n- `code-reviewer` checks **Security**, **Code Quality**, **Performance**, **Best Practices**, and **Maintainability**.\n- Rate each finding: **CRITICAL** (security or data-loss blocker), **HIGH** (bug/major smell), **MEDIUM** (important improvement), or **LOW** (style/suggestion).\n- `architect` checks explicit boundaries/interfaces, hidden coupling, long-horizon tradeoffs, and devil's-advocate concerns. Status is **CLEAR**, **WATCH** (non-blocking concern), or **BLOCK** (merge blocker).\n- Every finding names `file:line`, issue, risk, and a concrete fix; distinguish facts from suggestions.\n\n## State/HUD Phase Contract\n\n- Standalone `$code-review` relies on hook-owned `skill-active-state.json` (`skill:\"code-review\"`, `phase:\"planning\"`); do not create `code-review-state.json`.\n- Inside Autopilot, keep `mode:\"autopilot\"` active with `current_phase:\"code-review\"` / skill-active `phase:\"code-review\"`; do not activate a peer workflow.\n- On clean review, persist the artifact under Autopilot `handoff_artifacts.code_review` before moving to `ultraqa`. On non-clean review, persist findings and use `rework` or `ralplan` as appropriate.\n\n```sh\nomx state write --input '{\"mode\":\"autopilot\",\"active\":true,\"current_phase\":\"code-review\"}' --json\n```\n\n## Final Synthesis and gate\n\n### Architectural Status Contract\n\nCombine the `code-reviewer` recommendation and architect status. Approval requires explicit evidence from both independent lanes; missing or failed delegation is a blocking unavailable-review state, not an approval fallback. The final report must make architect blockers impossible to miss.\n\n- If architect status is **BLOCK**, final recommendation is **REQUEST CHANGES**.\n- Else if `code-reviewer` recommendation is **REQUEST CHANGES**, final recommendation is **REQUEST CHANGES**.\n- Else if architect status is **WATCH**, final recommendation is **COMMENT**.\n- Else final recommendation follows the `code-reviewer` lane.\n\nApproval criteria: **APPROVE** only when `code-reviewer` returns APPROVE, architect status is `CLEAR`, and both independent lanes returned evidence. **REQUEST CHANGES** for a blocker, unresolved high/critical finding, or unavailable lane. **COMMENT** may record non-blocking findings.\n\nDo not self-review as a fallback. If the `code-reviewer` or `architect` path is missing, unavailable, skipped, or fails, block approval until independent lane evidence exists. On the supported `omx ralph` CLI compatibility path, findings may trigger automatic fix follow-up without another permission prompt; plain `code-review` itself remains read-only and does **not** promise auto-fix.\n\n## Evidence/output contract\n\nReturn a concise report containing:\n\n```text\nCODE REVIEW REPORT\nFiles Reviewed: <count>\nTotal Issues: 0\nArchitectural Status: CLEAR | WATCH | BLOCK\nCRITICAL (0) | HIGH (0) | MEDIUM (0) | LOW (0)\nFindings: file:line -> issue, risk, concrete fix (or none)\nARCHITECTURE WATCHLIST: concern, status, recommendation (or none)\n- code-reviewer recommendation: COMMENT\n- architect status: WATCH\n- final recommendation: COMMENT\nRECOMMENDATION: COMMENT\n```\n\nReplace the illustrative counts and verdict with observed values. Include scope,\nlane evidence/artifact references, unresolved risks, and validation gaps.\n\n## Exit condition\n\nStop when the scoped diff has two independent lane results and a deterministic final\nrecommendation. Report `APPROVE` only under the approval criteria; otherwise leave a\nbounded `REQUEST CHANGES`, `COMMENT`, or unavailable-review result. Never claim\nmerge-ready without the required evidence.\n","plugins/oh-my-codex/skills/configure-notifications/SKILL.md":"---\nname: configure-notifications\ndescription: Configure OMX notifications - unified entry point for all platforms\ntriggers:\n - \"configure notifications\"\n - \"setup notifications\"\n - \"notification settings\"\n - \"configure discord\"\n - \"configure telegram\"\n - \"configure slack\"\n - \"configure openclaw\"\n - \"setup discord\"\n - \"setup telegram\"\n - \"setup slack\"\n - \"setup openclaw\"\n - \"discord notifications\"\n - \"telegram notifications\"\n - \"slack notifications\"\n - \"openclaw notifications\"\n - \"discord webhook\"\n - \"telegram bot\"\n - \"slack webhook\"\n---\n\n# Configure OMX Notifications\n\nUse this card for Discord, Telegram, Slack, generic command aliases, or OpenClaw. Shared safety, lifecycle, hook, team, autonomy, and cancellation rules live in `templates/AGENTS.md`.\n\n## 1. Inspect and choose a path\n\n```bash\nCONFIG_FILE=\"$HOME/.codex/.omx-config.json\"\nif [ -f \"$CONFIG_FILE\" ]; then\n jq -r '{notifications_enabled:(.notifications.enabled // false), discord:(.notifications.discord.enabled // false), discord_bot:(.notifications[\"discord-bot\"].enabled // false), telegram:(.notifications.telegram.enabled // false), slack:(.notifications.slack.enabled // false), openclaw:(.notifications.openclaw.enabled // false), custom_webhook_command:(.notifications.custom_webhook_command.enabled // false), custom_cli_command:(.notifications.custom_cli_command.enabled // false), verbosity:(.notifications.verbosity // \"session\"), idleCooldownSeconds:(.notifications.idleCooldownSeconds // 60), reply_enabled:(.notifications.reply.enabled // false)}' \"$CONFIG_FILE\"\nelse\n echo \"NO_CONFIG_FILE\"\nfi\n```\n\nUse AskUserQuestion to choose: Discord native (webhook or bot), Telegram native (bot token + chat id), Slack native (incoming webhook), `custom_webhook_command`, `custom_cli_command`, cross-cutting settings, or disable all notifications.\n\n## 2. Native providers\n\nCollect and validate provider values, then write only these native keys: `notifications.discord`, `notifications[\"discord-bot\"]`, `notifications.telegram`, or `notifications.slack`. Do not represent native providers with generic aliases.\n\n## 3. Generic aliases\n\nFor `custom_webhook_command`, collect URL, optional headers, method (`POST` default or `PUT`), events (`session-end`, `ask-user-question`, `session-start`, `session-idle`, `stop`), and an instruction template:\n\n```bash\njq --arg url \"$URL\" --arg method \"${METHOD:-POST}\" --arg instruction \"${INSTRUCTION:-OMX event {{event}} for {{projectPath}}}\" --argjson headers \"${HEADERS_JSON:-{}}\" '.notifications=(.notifications//{enabled:true})|.notifications.enabled=true|.notifications.custom_webhook_command={enabled:true,url:$url,headers:$headers,method:$method,instruction:$instruction,events:[\"session-end\",\"ask-user-question\"]}' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\nFor `custom_cli_command`, collect a command template (`{{event}}`, `{{instruction}}`, `{{sessionId}}`, `{{projectPath}}`), optional events, and an instruction template:\n\n```bash\njq --arg command \"$COMMAND_TEMPLATE\" --arg instruction \"${INSTRUCTION:-OMX event {{event}} for {{projectPath}}}\" '.notifications=(.notifications//{enabled:true})|.notifications.enabled=true|.notifications.custom_cli_command={enabled:true,command:$command,instruction:$instruction,events:[\"session-end\",\"ask-user-question\"]}' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\nOpenClaw dispatch requires `OMX_OPENCLAW=1`; command gateways additionally require `OMX_OPENCLAW_COMMAND=1`; timeout precedence is `gateways.<name>.timeout` > `OMX_OPENCLAW_COMMAND_TIMEOUT_MS` > `5000` ms.\n\n## 4. OpenClaw + Clawdbot agent mode\n\nUse this only when the requested route is a `clawdbot agent` turn delivered to Discord. The `session-stop` notification intentionally maps to the OpenClaw `stop` hook. OMX shell-escapes substitutions; keep instructions short, avoid untrusted shell metacharacters, append `|| true`, and append JSONL logs with `>>`.\n\n```bash\njq --arg command \"(clawdbot agent --session-id omx-hooks --message {{instruction}} --thinking minimal --deliver --reply-channel discord --reply-to 'channel:CHANNEL_ID' --timeout 120 --json >>/tmp/omx-openclaw-agent.jsonl 2>&1 || true)\" '.notifications=(.notifications//{enabled:true})|.notifications.enabled=true|.notifications.verbosity=\"verbose\"|.notifications.openclaw={enabled:true,gateways:{local:{type:\"command\",command:$command,timeout:120000}},hooks:{\"session-start\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-start project={{projectName}} session={{sessionId}} tmux={{tmuxSession}}. 한국어로 상태를 #omc-dev에 공유하고 SOUL.md를 참고하세요.\"},\"session-idle\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-idle session={{sessionId}} tmux={{tmuxSession}}. 한국어로 팔로업을 #omc-dev에 안내하세요.\"},\"ask-user-question\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=ask-user-question session={{sessionId}} tmux={{tmuxSession}} question={{question}}. 한국어로 응답 필요를 #omc-dev에 알리세요.\"},\"stop\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-stop session={{sessionId}} tmux={{tmuxSession}}. 한국어로 중단 상태를 전달하세요.\"},\"session-end\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-end session={{sessionId}} tmux={{tmuxSession}} reason={{reason}}. 한국어로 완료 요약을 #omc-dev에 남기세요.\"}}}' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\n### Compatibility + precedence contract\n\nExplicit `notifications.openclaw` wins when valid; generic aliases are ignored with a warning.\n\nVerify this mode and inspect evidence without hiding output:\n\n```bash\nclawdbot agent --session-id omx-hooks --message \"OMX hook test via clawdbot agent path\" --thinking minimal --deliver --reply-channel discord --reply-to 'channel:CHANNEL_ID' --timeout 120 --json\ntmux list-sessions -F '#{session_name}' | rg '^omx-' || true\njq '.notifications.openclaw.hooks' \"$CONFIG_FILE\"\ntail -n 120 /tmp/omx-openclaw-agent.jsonl | jq -s '.[] | {timestamp:(.timestamp // .time),status:(.status // .error // \"ok\")}'\nrg '\"error\"|\"failed\"|\"timeout\"' /tmp/omx-openclaw-agent.jsonl | tail -20\n```\n\nFor HTTP integrations, run both a `/hooks/wake` smoke test and `/hooks/agent` delivery verification.\n\n## 5. Cross-cutting settings and disable\n\n- Verbosity: `minimal`, `session` (recommended), `agent`, or `verbose`.\n- Idle cooldown: `notifications.idleCooldownSeconds` (environment override: `OMX_IDLE_COOLDOWN_SECONDS`).\n- Profiles: `notifications.profiles` and `notifications.defaultProfile`.\n- Reply listener: `notifications.reply.enabled`; gates are `OMX_REPLY_ENABLED=true` and, for Discord, `OMX_REPLY_DISCORD_USER_IDS=...`. An authorized Discord bot operator may exact-match `status` on a tracked notification for a bounded read-only session summary.\n\nDisable all notifications:\n\n```bash\njq '.notifications.enabled=false' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\n## Exit evidence\n\nRun `jq empty \"$CONFIG_FILE\"` after edits. Report the config path, enabled native providers, enabled aliases, whether valid `notifications.openclaw` overrides aliases, verbosity, idle cooldown, reply-listener state, and smoke-test results. Stop when the JSON parses and the selected path has its required evidence; do not claim delivery from configuration alone.\n","plugins/oh-my-codex/skills/deep-interview/SKILL.md":"---\nname: deep-interview\ndescription: Socratic deep interview with mathematical ambiguity gating before execution\nargument-hint: \"[--quick|--standard|--deep] [--autoresearch] <idea or vague description>\"\n---\n\n<Purpose>\nDeep Interview is an intent-first Socratic clarification loop before planning or implementation. It turns vague ideas into execution-ready specifications by asking targeted questions about why the user wants a change, how far it should go, what should stay out of scope, and what OMX may decide without confirmation.\n</Purpose>\n\n<Use_When>\n- The request is broad, ambiguous, or missing concrete acceptance criteria\n- The user says \"deep interview\", \"interview me\", \"ask me everything\", \"don't assume\", or \"ouroboros\"\n- The user wants to avoid misaligned implementation from underspecified requirements\n- You need a requirements artifact before handing off to `ralplan`, `autopilot`, `ultragoal`, or `team`\n</Use_When>\n\n<Do_Not_Use_When>\n- The request already has concrete file/symbol targets and clear acceptance criteria\n- The user explicitly asks to skip planning/interview and execute immediately\n- The user asks for lightweight brainstorming only (use `plan` instead)\n- A complete PRD/plan already exists and execution should start\n</Do_Not_Use_When>\n\n<Why_This_Exists>\nExecution quality is usually bottlenecked by intent clarity, not just missing implementation detail. A single expansion pass often misses why the user wants a change, where the scope should stop, which tradeoffs are unacceptable, and which decisions still require user approval. This workflow applies Socratic pressure + quantitative ambiguity scoring so orchestration modes begin with an explicit, testable, intent-aligned spec.\n</Why_This_Exists>\n\n<Depth_Profiles>\n- **Quick (`--quick`)**: fast pre-PRD pass; target threshold `<= 0.30`; max rounds 5\n- **Standard (`--standard`, default)**: full requirement interview; target threshold `<= 0.20`; max rounds 12\n- **Deep (`--deep`)**: high-rigor exploration; target threshold `<= 0.15`; max rounds 20\n- **Autoresearch (`--autoresearch`)**: same interview rigor as Standard, but specialized for `$autoresearch` mission readiness and `.omx/specs/` artifact handoff\n\nProfile `max rounds` is a hard cap, not a target. Do not continue only to reach a numbered round count. Extra Socratic rigor does not override the active threshold unless the profile/config changes.\n\nIf no flag is provided, use **Standard**.\n\n<Mode_Flags>\n- **`--autoresearch`**: switch the interview into autoresearch-intake mode for `$autoresearch` handoff. In this mode, the interview should converge on a validator-ready research mission, write canonical artifacts under `.omx/specs/`, and preserve the explicit `refine further` vs `launch` boundary for downstream skill intake.\n</Mode_Flags>\n</Depth_Profiles>\n\n<Execution_Policy>\n- Ask ONE question per round (never batch multiple interview rounds into one `questions[]` form)\n- Ask about intent and boundaries before implementation detail\n- Target the weakest clarity dimension each round after applying the stage-priority rules below\n- Treat every answer as a claim to pressure-test before moving on: the next question should usually demand evidence or examples, expose a hidden assumption, force a tradeoff or boundary, or reframe root cause vs symptom\n- Do not rotate to a new clarity dimension just for coverage when the current answer is still vague; stay on the same thread until one layer deeper, one assumption clearer, or one boundary tighter\n- Before crystallizing, complete at least one explicit pressure pass that revisits an earlier answer with a deeper, assumption-focused, or tradeoff-focused follow-up\n- Gather codebase facts via `explore` before asking user about internals\n- `omx explore` is deprecated. Use normal repository inspection tools/subagents for simple read-only brownfield fact gathering; use `omx sparkshell` only for explicit shell-native read-only evidence, and keep ambiguous or non-shell-only investigation on the richer normal path.\n- Always run a preflight context intake before the first interview question\n- For brownfield work, preflight must include doc/context grounding before user-facing questions: inspect applicable `AGENTS.md` files, README/getting-started docs, relevant `docs/` contracts/plans/ADRs, existing `.omx/context/` snapshots, and any project-local glossary/context files such as `CONTEXT.md` or `CONTEXT-MAP.md` when present.\n- Treat existing repo language as evidence, not authority: if the user uses a fuzzy, overloaded, or conflicting term, surface the specific doc/code wording and ask which meaning should govern before implementation.\n- Cross-check user claims about current behavior against code or documented contracts when discoverable. If docs and code disagree, ask a confirmation question that names both sources instead of silently choosing one.\n- Use scenario-based edge-case grilling when relationships, boundaries, or handoff behavior are unclear: invent one concrete scenario that stresses the ambiguous boundary, then ask one focused question about the expected outcome.\n- Durable docs, glossary, ADR, or memory updates are opt-in and public-safe only. Deep-interview may recommend such updates in the handoff summary, but must not automatically create or dump public docs from interview transcripts unless the user explicitly chooses that as in-scope.\n- If initial context is oversized or would exceed the prompt budget, do not paste or forward the raw payload into interview prompts; request and record a prompt-safe initial-context summary first\n- The oversized initial-context summary gate is blocking: wait for the concise summary before ambiguity scoring, crystallizing artifacts, or any downstream execution handoff\n- The summary must preserve goals, constraints, success criteria, non-goals, decision boundaries, and references to any full source documents so downstream consumers receive a prompt-safe but faithful context\n- Keep total prompt payloads within a safe budget by summarizing or trimming retained history; preserve newest/highest-signal answers and never let raw oversized context crowd out the current question\n- Reduce user effort: ask only the highest-leverage unresolved question, and never ask the user for codebase facts that can be discovered directly\n- For brownfield work, prefer evidence-backed confirmation questions such as \"I found X in Y. Should this change follow that pattern?\"\n- Route facts before judgment in the Ouroboros style: before presenting a user-facing interview round, classify whether the needed information is a discoverable fact, a fact needing confirmation, or a human decision. The interview is with the human for judgment, not for facts the agent can inspect.\n- When unresolved ambiguity depends on current external best practices, official/upstream guidance, standards, or version-aware behavior, use `$best-practice-research` as the bounded evidence wrapper before crystallizing requirements or handing off to planning/execution.\n- Use these transcript/spec labels only; never use them as `omx question` `source` values, and never replace the runtime `source: \"deep-interview\"` contract for user-facing deep-interview questions:\n - `[from-code][auto-confirmed]` — exact, high-confidence codebase facts from manifests/configs or direct source evidence, with no prescription attached.\n - `[from-code]` — codebase findings that are useful but inferred, pattern-based, or low/medium confidence and therefore need a confirmation-style user-facing round before being treated as settled.\n - `[from-research]` — externally sourced facts such as API limits, compatibility, or public documentation; facts only, not decisions.\n - `[from-user]` — goals, preferences, business logic, scope, non-goals, acceptance criteria, tradeoffs, and any decision-bearing interpretation.\n- Treat `[from-code][auto-confirmed]` and other non-user fact discoveries as context/transcript updates, not interview rounds: do not call `omx question`, do not create a pending deep-interview question obligation, and do not increment the user-facing round number for facts the agent can safely establish.\n- Auto-confirm only descriptive facts. If a finding implies what the new feature should do, which pattern it should follow, which tradeoff to accept, or what should stay in/out of scope, route the entire decision-bearing question to the user as `[from-user]` even when code or research facts are available.\n- In attached-tmux Codex CLI, deep-interview uses `omx question` as the required OMX-owned structured questioning path for every interview round\n- When invoking `omx question` through attached-tmux Bash/tool paths, preserve the leader-pane return target by prefixing the command with `OMX_QUESTION_RETURN_PANE=$TMUX_PANE` (or a concrete `%pane` value)\n- If you launch `omx question` in a background terminal, immediately wait for that background terminal to finish and read its JSON answer before scoring ambiguity, asking another round, or handing off\n- Treat `answers[]` as the primary `omx question` success contract. For a single interview round, read `answers[0].answer`; use legacy top-level `answer` only as a compatibility fallback when needed.\n- If the current runtime is outside tmux and cannot render `omx question`, use the native structured question tool when available; otherwise ask exactly one concise plain-text question and wait for the answer\n- Re-score ambiguity after each answer and show progress transparently\n- Once ambiguity is at or below the active profile threshold, stop ordinary questioning. Run the practical closure audit: crystallize/handoff when readiness gates pass; otherwise ask only the final closure question needed to satisfy a named gate.\n- Treat `max_rounds` as a stop cap, not evidence that more rounds are needed.\n- Do not hand off to execution while ambiguity remains above threshold unless user explicitly opts to proceed with warning\n- Do not crystallize or hand off while `Non-goals` or `Decision Boundaries` remain unresolved, even if the weighted ambiguity threshold is met\n- Treat early exit as a safety valve, not the default success path\n- Persist mode state for resume safety only through the CLI/programmatic single-writer authority (`omx state write/read --input '<json>' --json`, backed by `src/state/operations.ts`). The MCP state server is a read-only projection and must never become a second writer.\n</Execution_Policy>\n\n<Steps>\n\n## Phase 0: Preflight Context Intake\n\n1. Parse `{{ARGUMENTS}}` and derive a short task slug.\n2. Attempt to load the latest relevant context snapshot from `.omx/context/{slug}-*.md`.\n3. Check whether the provided initial context or loaded snapshot is too large for safe prompt use. If it is oversized, the first interview round must ask for a concise prompt-safe summary instead of scoring ambiguity or continuing to downstream handoff.\n4. If no snapshot exists, create a minimum context snapshot with:\n - Task statement\n - Desired outcome\n - Stated solution (what the user asked for)\n - Probable intent hypothesis (why they likely want it)\n - Known facts/evidence\n - Constraints\n - Unknowns/open questions\n - Decision-boundary unknowns\n - Likely codebase touchpoints\n - Relevant repo docs/rules/context inspected\n - Terminology or doc/code conflicts found\n - Prompt-safe initial-context summary status (`not_needed`, `needed`, or `recorded`)\n5. For brownfield tasks, inspect the applicable documentation/rule surface before the first user-facing round. Prefer exact, nearby sources over broad scans:\n - governing `AGENTS.md` files and template/runtime instruction surfaces that apply to the touched paths\n - README/getting-started docs and relevant docs under `docs/`, especially contracts, plans, ADR-like records, and workflow docs\n - existing `.omx/context/` snapshots, `.omx/specs/`, and planning artifacts relevant to the slug\n - project-local glossary/context files such as `CONTEXT.md`, `CONTEXT-MAP.md`, or context-specific docs when they exist\n6. Save snapshot to `.omx/context/{slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`) and reference it in mode state.\n\n## Phase 1: Initialize\n\n1. Parse `{{ARGUMENTS}}` and depth profile (`--quick|--standard|--deep`).\n2. Detect project context:\n - Run `explore` to classify **brownfield** (existing codebase target) vs **greenfield**.\n - For brownfield, collect relevant codebase context before questioning.\n3. Initialize state via `omx state write --input '{\"mode\":\"deep-interview\",\"active\":true}' --json`:\n\n```json\n{\n \"active\": true,\n \"current_phase\": \"deep-interview\",\n \"state\": {\n \"interview_id\": \"<uuid>\",\n \"profile\": \"quick|standard|deep\",\n \"type\": \"greenfield|brownfield\",\n \"initial_idea\": \"<user input>\",\n \"rounds\": [],\n \"current_ambiguity\": 1.0,\n \"threshold\": 0.3,\n \"max_rounds\": 5,\n \"challenge_modes_used\": [],\n \"codebase_context\": null,\n \"current_stage\": \"intent-first\",\n \"current_focus\": \"intent\",\n \"context_snapshot_path\": \".omx/context/<slug>-<timestamp>.md\"\n }\n}\n```\n\n4. Announce kickoff with profile, threshold, and current ambiguity.\n\n## Phase 2: Socratic Interview Loop\n\nRepeat until ambiguity `<= threshold`, the pressure pass is complete, the readiness gates are explicit, the user exits with warning, or max rounds are reached. This is a stop condition: below threshold, do not open a new ordinary interview branch.\n\n### 2a) Generate next question\nIf the initial context is oversized and no prompt-safe summary has been recorded yet, the next question must be only a summary request. Do not score ambiguity, do not run readiness gates, and do not hand off to `$ultragoal`, `$ralplan`, `$autopilot`, or `$team` until that summary answer is captured.\n\nUse:\n- Original idea\n- Prior Q&A rounds\n- Current dimension scores\n- Brownfield context (if any)\n- Doc/context grounding notes, including existing terminology, governing rules, and any doc/code mismatch\n- Activated challenge mode injection (Phase 3)\n\nTarget the lowest-scoring dimension, but respect stage priority:\n- **Stage 1 — Intent-first:** Intent, Outcome, Scope, Non-goals, Decision Boundaries\n- **Stage 2 — Feasibility:** Constraints, Success Criteria\n- **Stage 3 — Brownfield grounding:** Context Clarity (brownfield only)\n\nFollow-up pressure ladder after each answer:\n1. Ask for a concrete example, counterexample, or evidence signal behind the latest claim\n2. Probe the hidden assumption, dependency, or belief that makes the claim true\n3. Force a boundary or tradeoff: what would you explicitly not do, defer, or reject?\n4. Challenge fuzzy or conflicting terms against the repo's documented language and current code behavior\n5. Stress-test the boundary with one concrete scenario or edge case when a relationship or handoff remains ambiguous\n6. If the answer still describes symptoms, reframe toward essence / root cause before moving on\n\nPrefer staying on the same thread for multiple rounds when it has the highest leverage. Breadth without pressure is not progress.\n\nMaintain a **Breadth Ledger** across independent ambiguity tracks: scope, constraints, outputs, verification, brownfield integration, and any user-mentioned deliverable tracks. The ledger is a guard, not a mandatory rotation rule: stay deep on the current thread until it has been pressure-tested, then zoom out only when another material track remains unresolved and would change execution.\n\nMaintain a **Docs/Terminology Ledger** for brownfield interviews:\n- repo docs/rules/context sources inspected, with path references\n- canonical terms already used by the repo and terms to avoid or disambiguate\n- user terms that conflict with docs or current code behavior\n- doc/code mismatches that require a human decision before implementation\n- optional durable-doc follow-ups that are safe to propose but not auto-apply\n\nDetailed dimensions:\n- Intent Clarity — why the user wants this\n- Outcome Clarity — what end state they want\n- Scope Clarity — how far the change should go\n- Constraint Clarity — technical or business limits that must hold\n- Success Criteria Clarity — how completion will be judged\n- Context Clarity — existing codebase understanding (brownfield only)\n\n`Non-goals` and `Decision Boundaries` are mandatory readiness gates. Ask about them early and keep revisiting them until they are explicit.\n\n### 2b) Ask the question\nUse the surface-appropriate structured questioning path for every interview round. In attached-tmux sessions, use OMX-owned structured questioning via `omx question` (this is the required structured-question equivalent and required `AskUserQuestion` equivalent for deep-interview). Outside tmux, use native structured input when available; otherwise ask exactly one concise plain-text question and wait for the answer. Present:\n\n```\nRound {n} | Target: {weakest_dimension} | Ambiguity: {score}%\n\n{question}\n```\n\n`omx question` payload guidance for interview rounds:\n- Deep-interview is Socratic: ask one focused round at a time. Do not use batch `questions[]` to combine multiple interview rounds, even though `omx question` supports batch forms for other workflows.\n- Use canonical `type` values instead of authoring raw `multi_select` flags by hand. `type: \"single-answerable\"` is the default for one-path decisions; `type: \"multi-answerable\"` is the canonical shape for bounded multi-select rounds. The runtime will keep `multi_select` aligned with `type`.\n- Use `single-answerable` when exactly one answer should drive the next branch, the options are mutually exclusive, or selecting more than one answer would blur the decision boundary. Typical cases: handoff lane selection, choosing the primary failure mode, or confirming which of several competing interpretations is correct.\n- Use `multi-answerable` when multiple options may all be true at once and you need to capture a bounded set of coexisting constraints, non-goals, risks, or acceptance checks in one round. Typical cases: selecting all out-of-scope items, all success metrics that must hold, or all deployment constraints that apply together.\n- If one selected option would immediately require a follow-up question to disambiguate the others, prefer a `single-answerable` round now and ask the follow-up next. Do not hide a branching interview tree inside one overloaded multi-select prompt.\n- Keep interview options bounded and concrete. If the valid answers are already known, set `allow_other: false`; only leave `allow_other: true` when the interview genuinely needs one user-supplied option that cannot be enumerated in advance.\n- Read answers structurally from the primary `answers[]` array. For a normal single-round interview response, use `answers[0].answer` as the source of truth; the top-level `answer` field is a legacy single-question projection/fallback only.\n- For `single-answerable`, expect one decisive selection in the `value` field of `answers[0].answer` plus its selected-values metadata. For `multi-answerable`, treat the selected-values field inside `answers[0].answer` as the source of truth for all chosen constraints/non-goals and preserve the full set in the transcript/spec. In legacy single-question projections, this is equivalent to: For `multi-answerable`, treat `answer.selected_values` as the source of truth.\n\nCanonical bounded single-choice payload:\n\n```json\n{\n \"question\": \"Which execution lane should own this once the interview is complete?\",\n \"type\": \"single-answerable\",\n \"options\": [\n {\n \"label\": \"Plan first\",\n \"value\": \"ralplan\",\n \"description\": \"Need architecture and test-shape review before execution\"\n },\n {\n \"label\": \"Execute directly\",\n \"value\": \"autopilot\",\n \"description\": \"Requirements are already explicit enough for planning plus execution\"\n },\n {\n \"label\": \"Refine further\",\n \"value\": \"refine\",\n \"description\": \"Clarification is still needed before any handoff\"\n }\n ],\n \"allow_other\": false,\n \"other_label\": \"Other\",\n \"source\": \"deep-interview\"\n}\n```\n\nCanonical bounded multi-select payload:\n\n```json\n{\n \"question\": \"Which non-goals must stay out of scope for the first pass?\",\n \"type\": \"multi-answerable\",\n \"options\": [\n {\n \"label\": \"No UI redesign\",\n \"value\": \"no-ui-redesign\",\n \"description\": \"Keep layout and styling unchanged\"\n },\n {\n \"label\": \"No new dependencies\",\n \"value\": \"no-new-dependencies\",\n \"description\": \"Work within the existing toolchain\"\n },\n {\n \"label\": \"No API contract changes\",\n \"value\": \"no-api-contract-changes\",\n \"description\": \"Preserve external request and response shapes\"\n }\n ],\n \"allow_other\": false,\n \"other_label\": \"Other\",\n \"source\": \"deep-interview\"\n}\n```\n\nCanonical answer-shape reminders:\n\n```json\n{\n \"answer\": {\n \"kind\": \"option\",\n \"value\": \"ralplan\",\n \"selected_labels\": [\"Plan first\"],\n \"selected_values\": [\"ralplan\"]\n }\n}\n```\n\n```json\n{\n \"answer\": {\n \"kind\": \"multi\",\n \"value\": [\"no-new-dependencies\", \"no-api-contract-changes\"],\n \"selected_labels\": [\"No new dependencies\", \"No API contract changes\"],\n \"selected_values\": [\"no-new-dependencies\", \"no-api-contract-changes\"]\n }\n}\n```\n\n### 2c) Score ambiguity\nScore each weighted dimension in `[0.0, 1.0]` with justification + gap.\n\nGreenfield: `ambiguity = 1 - (intent × 0.30 + outcome × 0.25 + scope × 0.20 + constraints × 0.15 + success × 0.10)`\n\nBrownfield: `ambiguity = 1 - (intent × 0.25 + outcome × 0.20 + scope × 0.20 + constraints × 0.15 + success × 0.10 + context × 0.10)`\n\nReadiness gate:\n- `Non-goals` must be explicit\n- `Decision Boundaries` must be explicit\n- A pressure pass must be complete: at least one earlier answer has been revisited with an evidence, assumption, or tradeoff follow-up\n- A practical closure audit must pass: another question would change execution materially, not merely polish wording or chase a narrow edge case\n- If either gate is unresolved, or the pressure pass is incomplete, continue below threshold only with a final closure question that names the unresolved gate and would materially change execution.\n- Treat a low ambiguity score as permission to audit closure, not permission to keep drilling indefinitely. If remaining uncertainty would not change implementation, crystallize the spec instead of opening a new branch.\n- If ambiguity is `<= 0.10`, another user-facing question is allowed only as that final closure question; otherwise crystallize immediately.\n\n### 2d) Report progress\nShow weighted breakdown table, readiness-gate status (`Non-goals`, `Decision Boundaries`), and the next focus dimension.\n\n### 2e) Persist state\nAppend round result and updated scores via `omx state write --input '<json>' --json`. Do not write `{mode}-state.json` directly and do not use the read-only MCP state projection as a writer.\n\n### 2f) Round controls\n- Do not offer early exit before the first explicit assumption probe and one persistent follow-up have happened\n- Apply a **Dialectic Rhythm Guard**: track consecutive non-user fact discoveries and confirmation-style answers (`[from-code][auto-confirmed]`, `[from-code]`, or `[from-research]`). After 3 consecutive non-user or confirmation answers, the next material user-facing round must solicit direct human judgment (`[from-user]`) unless the closure audit says the interview is ready to crystallize.\n- Round 4+: allow explicit early exit with risk warning\n- Soft warning at profile midpoint (e.g., round 3/6/10 depending on profile)\n- Hard cap at profile `max_rounds`; never treat this cap as a desired interview length or quota\n\n## Phase 3: Challenge Modes (assumption stress tests)\n\nUse each mode once when applicable. These are normal escalation tools, not rare rescue moves:\n\n- **Contrarian** (round 2+ or immediately when an answer rests on an untested assumption): challenge core assumptions\n- **Terminologist** (brownfield, whenever a key term is fuzzy, overloaded, or conflicts with repo docs/code): force a canonical meaning against existing project language before implementation\n- **Simplifier** (round 4+ or when scope expands faster than outcome clarity): probe minimal viable scope\n- **Ontologist** (round 5+ and ambiguity > 0.25, or when the user keeps describing symptoms): ask for essence-level reframing\n\nTrack used modes in state to prevent repetition.\n\n## Phase 4: Crystallize Artifacts\n\nWhen threshold is met (or user exits with warning / hard cap):\n\n1. Write interview transcript summary to:\n - `.omx/interviews/{slug}-{timestamp}.md`\n (kept for ralph PRD compatibility)\n2. Write execution-ready spec to:\n - `.omx/specs/deep-interview-{slug}.md`\n\nSpec should include:\n- Metadata (profile, rounds, final ambiguity, threshold, context type)\n- Context snapshot reference/path (for ralplan/team reuse)\n- Prompt-safe initial-context summary when oversized context was provided, plus references to any full source documents\n- Clarity breakdown table\n- Intent (why the user wants this)\n- Desired Outcome\n- In-Scope\n- Out-of-Scope / Non-goals\n- Decision Boundaries (what OMX may decide without confirmation)\n- Constraints\n- Testable acceptance criteria\n- Assumptions exposed + resolutions\n- Pressure-pass findings (which answer was revisited, and what changed)\n- Brownfield evidence vs inference notes for any repository-grounded confirmation questions\n- Docs/Terminology Ledger with inspected repo docs/rules/context, term conflicts, and any doc/code mismatch decisions\n- Scenario/edge-case pressure findings that materially shaped scope or acceptance criteria\n- Optional durable documentation recommendations, explicitly marked opt-in and public-safe; do not include raw private transcript dumps\n- Technical context findings\n- Full or condensed transcript\n\n### Autoresearch specialization\n\nWhen the clarified task is specifically about `$autoresearch`, or the skill is invoked with `--autoresearch`, keep the interview domain-specific and emit skill-consumable artifacts without skipping clarification.\n\n- **Accepted seed inputs:** `topic`, `evaluator`, `keep-policy`, `slug`, existing mission draft text, and prior evaluator examples/templates\n- **Required interview focus:** mission clarity, evaluator readiness, keep policy, slug/session naming, and whether the draft is ready to launch now or should refine further\n- **Canonical artifact path:** `.omx/specs/deep-interview-autoresearch-{slug}.md`\n- **Launch artifact bundle:** `.omx/specs/autoresearch-{slug}/mission.md`, `.omx/specs/autoresearch-{slug}/sandbox.md`, and `.omx/specs/autoresearch-{slug}/result.json`\n- **Launch artifact directory:** `.omx/specs/autoresearch-{slug}/`\n- **Required artifact sections:**\n - `Mission Draft`\n - `Evaluator Draft`\n - `Launch Readiness`\n - `Seed Inputs`\n - `Confirmation Bridge`\n- **Required launch artifacts under `.omx/specs/autoresearch-{slug}/`:**\n - `mission.md`\n - `sandbox.md`\n - `result.json`\n- **Launch-readiness rule:** mark the draft as **not launch-ready** while the evaluator command still contains placeholder markers such as `<...>`, `TODO`, `TBD`, `REPLACE_ME`, `CHANGEME`, or `your-command-here`\n- **Structured result contract:** `result.json` should point to the draft + mission/sandbox artifacts and carry the finalized `topic`, `evaluatorCommand`, `keepPolicy`, `slug`, `launchReady`, and `blockedReasons` fields so `$autoresearch` can consume it directly\n- **Confirmation bridge:** after artifact generation, offer at least `refine further` and `launch`; do not run direct CLI launch or detached/split tmux launch, and only hand off to `$autoresearch` after explicit confirmation\n- **Handoff rule:** downstream execution must preserve the clarified mission intent, evaluator expectations, decision boundaries, and launch-readiness status from this artifact rather than bypassing the draft review step\n\n## Phase 5: Execution Bridge\n\nPresent execution options after artifact generation using explicit handoff contracts. Treat the deep-interview spec as the current requirements source of truth and preserve intent, non-goals, decision boundaries, acceptance criteria, docs/terminology grounding, and any residual-risk warnings across the handoff.\n\n### Optional execution contract foundation\n\nWhen an Autopilot/deep-interview handoff explicitly requires a stride contract, emit it as structured data rather than prose. This is a validation foundation, not a broadness-inference feature: do not infer stride from task length, phase labels, snapshots, or freeform wording.\n\nCanonical location under Autopilot state:\n\n```json\n{\n \"handoff_artifacts\": {\n \"deep_interview\": {\n \"execution_contract_required\": true,\n \"execution_contract\": {\n \"version\": 1,\n \"execution_stride\": \"task\",\n \"source\": \"deep-interview\",\n \"selected_by\": \"user\",\n \"allow_task_shrink\": true,\n \"completion_unit\": \"One focused task\",\n \"stop_condition\": \"Stop after that task is implemented and verified\",\n \"acceptance_coverage_scope\": \"task\",\n \"shrink_policy\": \"allowed\"\n }\n }\n }\n}\n```\n\nStride meanings:\n- `task`: conservative, small-step execution; `allow_task_shrink:true`, `acceptance_coverage_scope:\"task\"`, `shrink_policy:\"allowed\"`.\n- `deliverable`: finish the named deliverable before stopping; `allow_task_shrink:false`, `acceptance_coverage_scope:\"deliverable\"`, `shrink_policy:\"ask_before_shrink\"`.\n- `milestone`: finish the larger approved milestone unless blocked; `allow_task_shrink:false`, `acceptance_coverage_scope:\"milestone\"`, `shrink_policy:\"deny_unless_blocked\"`.\n\nOnly set `execution_contract_required:true` when the selected downstream workflow needs this explicit stride/stop-condition guard. New artifacts must write the canonical snake_case schema shown above under `handoff_artifacts.deep_interview`; runtime readers may accept legacy camelCase field/marker aliases and direct/nested `execution_contract` locations only as compatibility input. If `execution_contract_required` is absent or false, downstream Autopilot compatibility behavior is unchanged.\n\n### Goal-mode follow-ups\n\nInclude these product-facing suggestions when they fit the clarified spec, without removing the existing `$ultragoal`, `$ralplan`, `$autopilot`, and `$team` handoff options:\n\n- **`$ultragoal`** — default goal-mode follow-up for implementation or general goal-oriented follow-up specs that should be converted into durable Codex/OMX goals with sequential completion tracking.\n- **`$autoresearch`** — use when the clarified context is a research project: a research question, reference/literature gathering, evaluator-backed analysis, or professor/critic-style deliverable.\n- **`$performance-goal`** — use when the clarified context is an optimization or performance project with measurable speed, latency, throughput, memory, benchmark, or evaluator criteria.\n\nRecommend `$ultragoal` as the default durable goal-mode follow-up because it supersedes Ralph for goal tracking. Preserve `$team` for coordinated parallel implementation.\n\n### 1. **`$ultragoal` (Default durable execution follow-up)**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md` (optionally accompanied by the transcript/context snapshot for traceability)\n- **Invocation:** `$ultragoal create-goals --brief-file <spec-path>` followed by `$ultragoal complete-goals` in the active execution lane\n- **Consumer Behavior:** Convert the clarified spec into durable goal-mode work. Preserve intent, non-goals, decision boundaries, acceptance criteria, docs/terminology grounding, scenario-pressure findings, and residual-risk warnings as binding story constraints.\n- **Skipped / Already-Satisfied Stages:** Requirement interview, ambiguity clarification, doc/context preflight, and early intent-boundary elicitation\n- **Expected Output:** `.omx/ultragoal/brief.md`, `.omx/ultragoal/goals.json`, `.omx/ultragoal/ledger.jsonl`, implementation evidence, verification evidence, and final cleanup/review-gate evidence\n- **Best When:** The clarified spec is execution-ready or the user explicitly wants durable goal tracking as the next step\n- **Next Recommended Step:** Run the Ultragoal completion loop; launch `$team` only inside an active Ultragoal story when parallel lanes are warranted\n\n### 2. **`$ralplan` (Recommended when architecture/test-shape review is still needed)**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md` (optionally accompanied by the transcript/context snapshot for traceability)\n- **Invocation:** `$ralplan <spec-path>`\n- **Consumer Behavior:** Treat the deep-interview spec as the requirements source of truth. Do not repeat the interview by default; refine architecture/feasibility around the clarified intent and boundaries instead.\n- **Skipped / Already-Satisfied Stages:** Requirements discovery, ambiguity clarification, and early intent-boundary elicitation\n- **Expected Output:** Canonical planning artifacts under `.omx/plans/`, especially `prd-*.md` and `test-spec-*.md`\n- **Best When:** Requirements are clear enough to stop interviewing, but architectural validation / consensus planning is still desirable\n- **Next Recommended Step:** Use the approved planning artifacts with `$ultragoal` as the default durable goal-mode follow-up (optionally with `$team` for parallel lanes); choose `$autoresearch` for research validation or `$performance-goal` for measurable optimization\n\n### 3. **`$autopilot`**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md`\n- **Invocation:** `$autopilot <spec-path>`\n- **Consumer Behavior:** Use the deep-interview spec as the clarified execution brief. Preserve intent, non-goals, decision boundaries, and acceptance criteria as binding context for planning/execution.\n- **Skipped / Already-Satisfied Stages:** Initial requirement discovery and ambiguity reduction\n- **Expected Output:** Planning/execution progress, QA evidence, and validation artifacts produced by autopilot\n- **Best When:** The clarified spec is already strong enough for direct planning + execution without an additional consensus gate\n- **Next Recommended Step:** Continue through autopilot's execution/QA/validation flow; if coordination-heavy execution emerges, prefer `$team` under a leader-owned `$ultragoal` ledger\n\n### 4. **`$team`**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md`\n- **Invocation:** `$team <spec-path>`\n- **Consumer Behavior:** Treat the spec as shared execution context for coordinated parallel work. Preserve the clarified intent, non-goals, decision boundaries, and acceptance criteria as common lane constraints.\n- **Skipped / Already-Satisfied Stages:** Requirement clarification and early ambiguity reduction\n- **Expected Output:** Coordinated multi-agent execution against the shared spec, with final verification evidence and checkpoints in an already-active Ultragoal ledger when applicable\n- **Best When:** The task is large, multi-lane, or blocker-sensitive enough to justify coordinated parallel execution instead of a single persistent loop\n- **Next Recommended Step:** Follow the team verification path when the coordinated execution phase finishes; checkpoint an already-active `$ultragoal` ledger when applicable. Do not start another execution loop solely to verify.\n\n### 5. **Refine further**\n- **Input Artifact:** Existing transcript, context snapshot, and current spec draft\n- **Invocation:** Continue the interview loop\n- **Consumer Behavior:** Re-enter questioning to resolve the highest-leverage remaining uncertainty\n- **Skipped / Already-Satisfied Stages:** None beyond already-captured context\n- **Expected Output:** A lower-ambiguity spec with tighter boundaries and fewer unresolved assumptions\n- **Best When:** Residual ambiguity is still too high, the user wants stronger clarity, or the above-threshold / early-exit warning indicates too much risk to proceed cleanly\n- **Next Recommended Step:** Return to one of the execution handoff contracts above once the spec is sufficiently clarified\n\n**Residual-Risk Rule:** If the interview ended via early exit, hard-cap completion, or above-threshold proceed-with-warning, explicitly preserve that residual-risk state in the handoff so the downstream skill knows it inherited a partially clarified brief.\n\n**IMPORTANT:** Deep-interview is a requirements mode. On handoff, invoke the selected skill using the contract above. **Do NOT implement directly** inside deep-interview.\n\n</Steps>\n\n<Tool_Usage>\n- Use `explore` for codebase fact gathering\n- Use `omx question` as the OMX-native structured user-input tool for each interview round when an attached tmux renderer is available\n- From attached-tmux Bash/tool paths, call it as `OMX_QUESTION_RETURN_PANE=$TMUX_PANE omx question ...` unless an explicit `%pane` return target is already known\n- If the current runtime is outside tmux and cannot render `omx question`, use native structured input when available; otherwise ask exactly one concise plain-text question and wait for the answer\n- After `omx question` returns JSON, prefer `answers[0].answer` / `answers[]`; use legacy `answer` only as a fallback for older records\n- Use `omx state write/read --input '<json>' --json` for resumable mode state through the sole-writer state operations path; the MCP state server is read-only and is not a fallback writer\n- If the interview cannot ask a required `omx question` round, persist the blocker as terminal state with `active: false` and `current_phase: \"blocked\"`; do not write a terminal blocked phase with `active: true`\n- Read/write context snapshots under `.omx/context/`\n- Read applicable repo docs/rules/context during preflight; write durable docs, glossary, ADR, or memory updates only when the user explicitly opts in and the content is public-safe\n- Record whether the oversized-context summary gate is not needed, pending, or satisfied before any scoring or handoff step\n- Save transcript/spec artifacts under `.omx/interviews/` and `.omx/specs/`\n</Tool_Usage>\n\n<Escalation_And_Stop_Conditions>\n- User says stop/cancel/abort -> persist state and stop\n- Ambiguity stalls for 3 rounds (+/- 0.05) -> force Ontologist mode once\n- Max rounds reached -> proceed with explicit residual-risk warning\n- All dimensions >= 0.9 -> allow early crystallization even before max rounds\n</Escalation_And_Stop_Conditions>\n\n<Final_Checklist>\n- [ ] Preflight context snapshot exists under `.omx/context/{slug}-{timestamp}.md`\n- [ ] Oversized initial context, if present, has a prompt-safe summary recorded before ambiguity scoring or downstream handoff\n- [ ] Ambiguity score shown each round\n- [ ] Intent-first stage priority used before implementation detail\n- [ ] Weakest-dimension targeting used within the active stage\n- [ ] At least one explicit assumption probe happened before crystallization\n- [ ] At least one persistent follow-up / pressure pass deepened a prior answer\n- [ ] Challenge modes triggered at thresholds (when applicable)\n- [ ] Transcript written to `.omx/interviews/{slug}-{timestamp}.md`\n- [ ] Spec written to `.omx/specs/deep-interview-{slug}.md`\n- [ ] Brownfield questions use evidence-backed confirmation when applicable\n- [ ] Brownfield preflight inspected applicable repo docs/rules/context before user-facing questions\n- [ ] Fuzzy or conflicting terminology was challenged against repo language/current code behavior when applicable\n- [ ] Scenario-based edge-case grilling was used when boundary ambiguity would materially affect implementation\n- [ ] Durable docs/ADR/memory updates, if any, were explicitly opted into and public-safe\n- [ ] Handoff options provided (`$ultragoal`, `$ralplan`, `$autopilot`, `$team`) plus context-sensitive goal-mode suggestions (`$autoresearch`, `$performance-goal`) when applicable\n- [ ] No direct implementation performed in this mode\n</Final_Checklist>\n\n<Advanced>\n## Suggested Config (optional)\n\nDeep-interview reads runtime defaults from the first existing config source in this order:\n\n1. Repository-local `.omx/config.toml`\n2. Repository-root `omx.toml`\n3. User-global `~/.omx/config.toml`\n\nThis section is currently a deep-interview-specific runtime override surface, not a general replacement for Codex `config.toml` or `.omx-config.json` model/env routing.\nMalformed config files are ignored fail-soft so `$deep-interview` activation can continue with built-in defaults.\nExplicit `--quick`, `--standard`, or `--deep` invocation flags override `defaultProfile`.\n\n```toml\n[omx.deepInterview]\ndefaultProfile = \"standard\"\nquickThreshold = 0.30\nstandardThreshold = 0.20\ndeepThreshold = 0.15\nquickMaxRounds = 5\nstandardMaxRounds = 12\ndeepMaxRounds = 20\nenableChallengeModes = true\n```\n\n## Resume\n\nIf interrupted, rerun `$deep-interview`. Resume from persisted mode state via `omx state read --input '{\"mode\":\"deep-interview\"}' --json`.\n\n## Canonical Autopilot Entry Pipeline\n\n```\nautopilot -> deep-interview -> ralplan -> ultragoal\n```\n\n- Autopilot begins with this independent deep-interview clarity gate; it must not substitute `$plan --interview`.\n- Stage 1 (deep-interview): ambiguity clearance and execution-ready requirements artifact\n- Stage 2 (ralplan): feasibility, architecture, and consensus gate\n- Stage 3 (ultragoal): durable execution, verification, and completion receipts\n</Advanced>\n","plugins/oh-my-codex/skills/design/SKILL.md":"---\nname: design\ndescription: Canonical repo-local DESIGN.md workflow for product, UI/UX, and frontend decision source of truth\n---\n\n# Design Skill\n\nUse `$design` to discover product and UI evidence, close only design-critical context gaps, and create or refresh the repository’s durable `DESIGN.md` contract. It is a maintained design brief, not a pixel-matching loop or one-off critique.\n\nShared operating, delegation, state, hook, team, cancellation, and verification invariants live in [`templates/AGENTS.md`](../../templates/AGENTS.md). Follow that source instead of duplicating its rules here.\n\n## Use when\n\n- Product, UX, frontend, or design-system decisions need a repo-local source of truth.\n- A feature needs a design brief before a designer lane or implementation.\n- Existing UI, assets, screenshots, or constraints need an actionable design summary.\n\nDo not use it for visual-reference implementation matching (use `$visual-ralph`), screenshot comparison alone, or backend/infrastructure work without user-facing design impact.\n\n## Relationship to `$visual-ralph`\n\n`$design` owns product goals, users, information architecture, visual language, components, accessibility, constraints, and open questions in `DESIGN.md`. `$visual-ralph` owns implementation against an approved visual reference or live-URL baseline, measured verdicts, and pixel-diff evidence. Run `$design` first when both are needed; `DESIGN.md` supports but does not replace the visual verdict target.\n\n## Workflow\n\n### 1. Discover local evidence\n\nInspect and cite existing `DESIGN.md`, design/UX/frontend docs, README/specs/issues, routes/pages/layouts/components/stories, theme and token files, assets, screenshots/mockups, Storybook or Playwright baselines, and accessibility/responsive/i18n/platform constraints. Separate observations from inferences; note absent evidence.\n\n### 2. Interview only missing context\n\nAsk concise questions only for gaps the repository cannot resolve: users/jobs, goals/non-goals, brand personality and forbidden aesthetics, primary flows, accessibility/device/browser targets, or unavailable assets/references. If answers are unavailable, record explicit assumptions and open questions rather than blocking.\n\n### 3. Create or refresh `DESIGN.md`\n\nPreserve useful content, remove contradictions, mark unknowns, and keep decisions actionable. The root file must contain these sections:\n\n# Design\n## Source of truth\nStatus (Draft | Active | Needs refresh), date, product surfaces, evidence reviewed.\n## Brand\nPersonality, trust signals, avoid.\n## Product goals\nGoals, non-goals, success signals.\n## Personas and jobs\nPrimary personas, user jobs, contexts of use.\n## Information architecture\nNavigation, routes/screens, content hierarchy.\n## Design principles\nPrinciples and tradeoffs.\n## Visual language\nColor, typography, spacing, shape/elevation, motion, imagery/iconography.\n## Components\nExisting/new components, variants/states, token ownership.\n## Accessibility\nTarget standard, keyboard/focus, contrast, semantics, reduced motion/sensory concerns.\n## Responsive behavior\nBreakpoints/devices, layout adaptations, touch/hover differences.\n## Interaction states\nLoading, empty, error, success, disabled, offline/slow network where applicable.\n## Content voice\nTone, terminology, microcopy rules.\n## Implementation constraints\nFramework/styling, tokens, performance, compatibility, test/screenshot expectations.\n## Open questions\n`[ ]` question, owner, and impact.\n\n### 4. Apply the contract\n\nBefore UI decisions, cite relevant `DESIGN.md` sections, reuse documented components/tokens, and update the file or add an open question when implementation exposes a contradiction. Do not invent a parallel design-system layer.\n\n### 5. Handoff\n\nFor normal frontend work, provide the relevant sections, repo evidence, and acceptance criteria. For visual-reference, image, or live-URL matching, hand off to `$visual-ralph` with the approved baseline and identify `DESIGN.md` as supporting context only.\n\n## Evidence and completion\n\nComplete only when design docs/assets/components/screenshots were inspected or noted absent; missing context is answered, assumed, or listed; root `DESIGN.md` contains every required section; recommendations cite it; and any Visual Ralph handoff is clearly separated from design governance.\n\nTask: {{ARGUMENTS}}\n","plugins/oh-my-codex/skills/doctor/SKILL.md":"---\nname: doctor\ndescription: Diagnose and fix oh-my-codex installation issues\n---\n\n# OMX Doctor\n\nUse this task card to diagnose installation/discovery problems. Shared safety, lifecycle, hook, team, autonomy, and cancellation rules live in `templates/AGENTS.md`. `~/.codex` means `${CODEX_HOME:-~/.codex}` when `CODEX_HOME` is set.\n\n## Run diagnostics\n\n```bash\nomx doctor\nomx doctor --team # include Team runtime checks\nomx doctor --verbose # include detailed check evidence\nomx doctor --force # repair eligible repo artifact ownership issues\nomx doctor --dry-run --force # preview eligible ownership repairs\n```\n\nFor a local source checkout, build first and invoke `node dist/cli/omx.js doctor`. Keep command output and exact paths for the report.\n\n### Plugin cache and version\n\n```bash\nPLUGIN_CACHE_ROOT=\"${CODEX_HOME:-$HOME/.codex}/plugins/cache\"\nCACHE_ENTRIES=$(find \"$PLUGIN_CACHE_ROOT\" -path \"*/oh-my-codex/*\" -mindepth 3 -maxdepth 3 -type d 2>/dev/null)\nif [[ -z \"$CACHE_ENTRIES\" ]]; then\n echo \"Installed plugin cache: none\"\nelse\n while IFS= read -r d; do\n m=$(basename \"$(dirname \"$(dirname \"$d\")\")\"); v=$(basename \"$d\")\n printf 'Installed plugin cache: marketplace=%s version=%s path=%s\\n' \"$m\" \"$v\" \"$d\"\n done <<<\"$CACHE_ENTRIES\"\nfi\nLATEST=$(npm view oh-my-codex version 2>/dev/null)\necho \"Latest npm: $LATEST\"\n```\n\nNo cache is INFO (normal for npm/setup-only installs). A non-`local` cache version differing from `LATEST`, or multiple versions for one marketplace, is WARN. Plugin discovery does not replace npm installation plus `omx setup`; native/runtime wiring remains setup-owned.\n\n### Hooks, AGENTS, and skill roots\n\n```bash\nCODEX_DIR=\"${CODEX_HOME:-$HOME/.codex}\"\nls -la \"$CODEX_DIR/config.toml\" \"$CODEX_DIR/settings.json\" 2>/dev/null\nrg 'keyword-detector|persistent-mode|session-start|stop-continuation' \"$CODEX_DIR/config.toml\" \"$CODEX_DIR/settings.json\" 2>/dev/null || true\nls -la \"$CODEX_DIR/hooks\"/*.sh 2>/dev/null\nls -la \"$CODEX_DIR/AGENTS.md\" 2>/dev/null\ngrep -q \"oh-my-codex Multi-Agent System\" \"$CODEX_DIR/AGENTS.md\" 2>/dev/null && echo \"Has OMX config\" || echo \"Missing OMX config\"\nls -la \"$CODEX_DIR/agents\" \"$CODEX_DIR/commands\" \"$CODEX_DIR/skills\" \"$HOME/.agents/skills\" 2>/dev/null\n```\n\nClassify legacy hook references as **CRITICAL** (duplicate hooks). The scripts `keyword-detector.sh`, `persistent-mode.sh`, `session-start.sh`, and `stop-continuation.sh` are **WARN**. Missing AGENTS.md is **CRITICAL**; missing the OMX marker is **WARN**. `${CODEX_HOME:-~/.codex}/skills` is the canonical user root. `~/.agents/skills` is historical and overlapping trees can duplicate skill entries. OMX files under legacy `agents/` or `commands/` are **WARN**.\n\nWith `--team`, retain any `resume_blocker`, `slow_shutdown`, `delayed_status_lag`, `stale_leader`, or `orphan_tmux_session` diagnostics; failed checks set a non-zero exit status.\n\n## Report contract\n\n```text\n## OMX Doctor Report\n### Summary\n[HEALTHY / ISSUES FOUND]\n### Checks\n| Check | Status | Details |\n| Plugin Version | OK/WARN/INFO | ... |\n| Hook Config (config.toml / legacy settings.json) | OK/CRITICAL | ... |\n| Legacy Scripts (~/.codex/hooks/) | OK/WARN | ... |\n| AGENTS.md | OK/WARN/CRITICAL | ... |\n| Plugin Cache | OK/WARN | ... |\n| Legacy Agents / Commands | OK/WARN | ... |\n| Skills (canonical / historical root) | OK/WARN | ... |\n### Issues Found\n1. ...\n### Recommended Fixes\n...\n```\n\n## Remediation (after user confirmation and confirming each target is OMX-owned)\n\nRemove only confirmed OMX legacy content; preserve unrelated user files:\n\n```bash\n# If settings.json exists, remove only its legacy \"hooks\" section.\nrm -f \"$CODEX_DIR/hooks/keyword-detector.sh\" \"$CODEX_DIR/hooks/persistent-mode.sh\" \"$CODEX_DIR/hooks/session-start.sh\" \"$CODEX_DIR/hooks/stop-continuation.sh\"\nPLUGIN_CACHE_ROOT=\"${CODEX_HOME:-$HOME/.codex}/plugins/cache\"\nfind \"$PLUGIN_CACHE_ROOT\" -path \"*/oh-my-codex\" -type d -prune -exec rm -rf {} +\n```\n\nFor older curl installs, inspect first and remove only directories containing OMX-managed files:\n\n```bash\nls -la \"$CODEX_DIR/agents\" \"$CODEX_DIR/commands\" \"$CODEX_DIR/skills\" \"$HOME/.agents/skills\" 2>/dev/null\n# Optional backups:\n# mv \"$CODEX_DIR/agents\" \"$CODEX_DIR/agents.bak\"\n# mv \"$CODEX_DIR/commands\" \"$CODEX_DIR/commands.bak\"\n# mv \"$HOME/.agents/skills\" \"$HOME/.agents/skills.bak\"\nrm -rf \"$CODEX_DIR/agents\" \"$CODEX_DIR/commands\" \"$HOME/.agents/skills\"\n```\n\nIf AGENTS.md is missing/outdated, fetch the current raw file and write it to `$CODEX_DIR/AGENTS.md`:\n\n```text\nWebFetch(url: \"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/main/docs/AGENTS.md\", prompt: \"Return the complete raw markdown content exactly as-is\")\n```\n\nTo keep only the newest cache version for a selected marketplace:\n\n```bash\nPLUGIN_CACHE_DIR=\"$PLUGIN_CACHE_ROOT/$MARKETPLACE_NAME/oh-my-codex\"\nKEEP_VERSION=$(for d in \"$PLUGIN_CACHE_DIR\"/*; do [[ -d \"$d\" ]] && basename \"$d\"; done | sort -V | tail -1)\n[[ -n \"$KEEP_VERSION\" ]] && find \"$PLUGIN_CACHE_DIR\" -mindepth 1 -maxdepth 1 -type d ! -name \"$KEEP_VERSION\" -exec rm -rf {} +\n```\n\nIf AGENTS.md is missing or stale, refresh it from the current release source, then rerun `omx doctor`. If legacy `~/.agents/skills` overlaps the canonical root, archive/remove that tree only after checking for custom skills. Restart Codex after fixes and report before/after evidence.\n\n## Exit conditions\n\nStop with **HEALTHY** only when required paths, hook/config checks, AGENTS marker, plugin cache status, and (when requested) Team checks pass. Otherwise report **ISSUES FOUND**, exact failed evidence, and the smallest confirmed remediation; do not claim a fix from a recommendation alone.\n","plugins/oh-my-codex/skills/hud/SKILL.md":"---\nname: \"hud\"\ndescription: \"Show or configure the OMX HUD (two-layer statusline)\"\nrole: \"display\"\nscope: \".omx/**\"\n---\n\n# HUD Skill\n\nThe OMX HUD uses a two-layer architecture:\n\n1. **Layer 1 - Codex built-in statusLine**: Real-time TUI footer showing model, git branch, and context usage. Configured via `[tui] status_line` in `~/.codex/config.toml`. Zero code required.\n\n2. **Layer 2 - `omx hud` CLI command**: Shows OMX-specific orchestration state (ralph, ultrawork, autopilot, team, pipeline, ecomode, turns). Reads `.omx/state/` files.\n\n## Quick Commands\n\n| Command | Description |\n|---------|-------------|\n| `omx hud` | Show current HUD (modes, turns, activity) |\n| `omx hud --watch` | Live-updating display (polls every 1s) |\n| `omx hud --json` | Raw state output for scripting |\n| `omx hud --preset=minimal` | Minimal display |\n| `omx hud --preset=focused` | Default display |\n| `omx hud --preset=full` | All elements |\n\n## Presets\n\n### minimal\n```\n[OMX] ralph:3/10 | turns:42\n```\n\n### focused (default)\n```\n[OMX] ralph:3/10 | ultrawork | team:3 workers | turns:42 | last:5s ago\n```\n\n### full\n```\n[OMX] ralph:3/10 | ultrawork | autopilot:execution | team:3 workers | pipeline:exec | turns:42 | last:5s ago | total-turns:156\n```\n\n## Setup\n\n`omx setup` automatically configures both layers:\n- Adds `[tui] status_line` to `~/.codex/config.toml` (Layer 1)\n- Writes `.omx/hud-config.json` with default preset (Layer 2)\n- Default preset is `focused`; if HUD/statusline changes do not appear, restart Codex CLI once.\n\n## Layer 1: Codex Built-in StatusLine\n\nConfigured in `~/.codex/config.toml`:\n```toml\n[tui]\nstatus_line = [\"model-with-reasoning\", \"git-branch\", \"context-remaining\"]\n```\n\nAvailable built-in items (Codex CLI v0.101.0+):\n`model-name`, `model-with-reasoning`, `current-dir`, `project-root`, `git-branch`, `context-remaining`, `context-used`, `five-hour-limit`, `weekly-limit`, `codex-version`, `context-window-size`, `used-tokens`, `total-input-tokens`, `total-output-tokens`, `session-id`\n\n## Layer 2: OMX Orchestration HUD\n\nThe `omx hud` command reads these state files:\n- `.omx/state/ralph-state.json` - Ralph loop iteration\n- `.omx/state/ultrawork-state.json` - Ultrawork mode\n- `.omx/state/autopilot-state.json` - Autopilot phase\n- `.omx/state/team-state.json` - Team workers\n- `.omx/state/pipeline-state.json` - Pipeline stage\n- `.omx/state/ecomode-state.json` - Ecomode active\n- `.omx/state/hud-state.json` - Last activity (from notify hook)\n- `.omx/metrics.json` - Turn counts\n\n## Configuration\n\nHUD config stored at `.omx/hud-config.json`:\n```json\n{\n \"preset\": \"focused\"\n}\n```\n\n## Color Coding\n\n- **Green**: Normal/healthy\n- **Yellow**: Warning (ralph >70% of max)\n- **Red**: Critical (ralph >90% of max)\n\n## Troubleshooting\n\nIf the TUI statusline is not showing:\n1. Ensure Codex CLI v0.101.0+ is installed\n2. Run `omx setup` to configure `[tui]` section\n3. Restart Codex CLI\n\nIf `omx hud` shows \"No active modes\":\n- This is expected when no workflows are running\n- Start an explicitly requested supported workflow (`$autopilot` or `$ultragoal`) and check again\n","plugins/oh-my-codex/skills/omx-setup/SKILL.md":"---\nname: omx-setup\ndescription: Setup and configure oh-my-codex using current CLI behavior\n---\n\n# OMX Setup\n\nUse this task card to install or refresh OMX for the current project and/or user scope. Shared safety, lifecycle, hook, team, autonomy, and cancellation rules live in `templates/AGENTS.md`. Do not infer new CLI behavior from this card; the implementation is authoritative.\n\n## Command and alternatives\n\n```bash\nomx setup [--force] [--merge-agents|--no-merge-agents|--clear-merge-agents-policy] [--dry-run] [--verbose] [--scope <user|project>] [--plugin|--legacy|--install-mode <legacy|plugin>] [--mcp <none|compat>] [--no-mcp|--with-mcp] [--disable-team|--enable-team|--team-mode <enabled|disabled>]\nomx agents-init [path] [--dry-run] [--force] [--verbose]\n```\n\nUse `agents-init` for lightweight AGENTS.md scaffolding only, not a full install.\n\nSupported setup options:\n- `--force`: overwrite/reinstall managed artifacts; transient, not persisted or replayed.\n- `--merge-agents`, `--no-merge-agents`, `--clear-merge-agents-policy`: exact bare selectors (no values/equals). Repeated identical selectors are idempotent; conflicting selectors fail before mutations. Set persists an explicit policy per invoking project root; clear removes it and cannot combine with a set. Merge refreshes managed sections; no-merge only suppresses that branch and is not a preserve mode.\n- `--dry-run`, `--verbose`: preview actions or show per-file/per-step detail.\n- `--scope user|project`: choose user (`~/.codex`, `~/.omx/agents`) or project (`./.codex`, `./.omx/agents`) targets.\n- `--plugin` / `--legacy`: select delivery mode; `--install-mode legacy|plugin` is the canonical scripted spelling. Conflicting mode flags fail.\n- `--mcp none|compat` (plus `--no-mcp` / `--with-mcp`): omit or enable first-party MCP compatibility and shared registry sync.\n- `--disable-team`, `--enable-team`, `--team-mode enabled|disabled`: select Team skill/context generation; conflicting selectors fail.\n\n## Resolve setup\n\n1. Scope: explicit flag, valid persisted `./.omx/setup-scope.json`, TTY choice (default `user`), or non-interactive `user`. Legacy `project-local` migrates to `project`.\n2. Mode: explicit flag, persisted mode when retained, discovered `${CODEX_HOME:-~/.codex}/plugins/cache/**/.codex-plugin/plugin.json` with `name: oh-my-codex` (plugin default), otherwise legacy. TTY reruns summarize saved choices and offer keep/review/reset; non-interactive runs do not block.\n3. Create required directories and atomically persist preferences only after successful setup.\n\n## What setup changes\n\n- Legacy mode installs prompts/native agents/skills and merges full config.toml.\n- Plugin mode archives/removes legacy OMX-managed prompts/skills, refreshes installable native agent TOMLs and stale generated non-installable agents, and keeps setup-owned runtime hooks.\n- Both modes verify Team CLI interop markers in built `dist/cli/team.js`, generate AGENTS defaults only when selected/allowed, and write `./.omx/hud-config.json`; notification hook references are setup-owned outside plugin skill delivery.\n- `AGENTS.md` is `./AGENTS.md`. Without `--force` or `--merge-agents`, interactive runs ask before overwrite and non-interactive runs preserve it. Active-session safeguards may skip writes. Plugin mode may separately prompt for AGENTS and `developer_instructions` defaults; non-interactive runs preserve existing files.\n- Plugin mode enables setup-owned runtime flags (`plugin_hooks`, `goals`, or legacy `hooks`/`codex_hooks` fallback). Project scope uses `CODEX_HOME=./.codex` unless explicitly overridden.\n\n## Verify\n\n```bash\nomx setup --force --verbose\nomx doctor\n```\n\nExpect doctor evidence for prompts and skills in the selected scope, project-root AGENTS.md, `.omx/state`, and CLI-first config in the scope target `config.toml`. First-party MCP and shared registry sync are omitted unless setup used `--mcp compat` (if supported by the installed CLI).\n\nIf using local source, run `npm run build` before `node dist/cli/omx.js setup --force --verbose` and `node dist/cli/omx.js doctor`. If AGENTS was not overwritten or merged, stop the active OMX session and rerun with `--force` or `--merge-agents`; do not edit lifecycle state manually.\n\n## Discovery troubleshooting\n\nIf `$omx-setup` is absent/stale: run `omx setup --verbose`, then `omx doctor`; verify `./.codex/skills/omx-setup/SKILL.md` for project scope or `${CODEX_HOME:-~/.codex}/skills/omx-setup/SKILL.md` for legacy user scope. In plugin mode verify the oh-my-codex plugin is installed/discovered. For duplicates, inspect historical `~/.agents/skills` overlap and follow doctor/setup cleanup guidance.\n\n## Exit contract\n\nReport selected scope/mode, dry-run versus mutation, AGENTS policy, affected roots, and doctor indicators. Stop only after setup completes successfully and verification identifies the expected files/config; on failure preserve the exact command output and rerun the smallest corrective command. Do not claim installation from a dry-run alone.\n","plugins/oh-my-codex/skills/performance-goal/SKILL.md":"---\nname: performance-goal\ndescription: \"Run an evaluator-gated performance optimization workflow over Codex goal mode with durable OMX artifacts and safe goal handoffs.\"\n---\n\n# Performance Goal Workflow\n\nUse this skill when a user asks OMX to optimize performance and wants a goal-oriented loop rather than a one-off review.\n\n## Contract\n\n- OMX owns durable workflow state under `.omx/goals/performance/<slug>/`.\n- Codex goal mode owns only the active-thread focus/accounting primitive.\n- Shell commands do **not** mutate hidden Codex goal state. They write artifacts and emit model-facing handoff text.\n- No optimization work may start until an evaluator command and pass/fail contract exist.\n- Do not call `update_goal({status: \"complete\"})` until the evaluator has a passing checkpoint and a completion audit proves the objective is done; then call `get_goal` again and pass that fresh snapshot to `omx performance-goal complete --codex-goal-json`.\n\n## CLI\n\nCreate the workflow and evaluator contract:\n\n```sh\nomx performance-goal create \\\n --objective \"Reduce CLI startup latency by 20%\" \\\n --evaluator-command \"npm run perf:startup\" \\\n --evaluator-contract \"PASS when p95 latency improves by 20% and regression tests pass\" \\\n --slug startup-latency\n```\n\nEmit the Codex goal handoff:\n\n```sh\nomx performance-goal start --slug startup-latency\n```\n\nRecord evaluator evidence:\n\n```sh\nomx performance-goal checkpoint --slug startup-latency --status pass --evidence \"benchmark + tests passed\"\nomx performance-goal checkpoint --slug startup-latency --status fail --evidence \"benchmark regressed\"\nomx performance-goal checkpoint --slug startup-latency --status blocked --evidence \"missing fixture\"\n```\n\nComplete only after a passing checkpoint:\n\n```sh\nomx performance-goal complete --slug startup-latency --evidence \"final evaluator evidence\" --codex-goal-json <get_goal-json-or-path>\n```\n\n## Agent Loop\n\n1. Run `omx performance-goal create` if no workflow exists.\n2. Run `omx performance-goal start` and follow the handoff:\n - call `get_goal`;\n - call `create_goal` only when no active goal exists and the objective is explicit;\n - work only against the evaluator contract;\n - after evaluator pass and completion audit, call `update_goal({status: \"complete\"})`, call `get_goal` again, and pass that snapshot to `omx performance-goal complete --codex-goal-json`;\n - after `omx performance-goal complete` succeeds, run `/goal clear` in the Codex UI before starting another goal in this same thread/session; OMX prints this terminal cleanup step but does not invoke hidden clear routes;\n3. Optimize in small reversible patches.\n4. Run the evaluator and related regression tests.\n5. Record each pass/fail/blocker with `checkpoint`.\n6. Complete only when the pass artifact exists and no required work remains.\n\n## Completion Gate\n\nA performance goal is incomplete unless `.omx/goals/performance/<slug>/state.json` contains a `lastValidation.status` of `pass` and `omx performance-goal complete` receives a matching complete Codex `get_goal` snapshot via `--codex-goal-json`. Passing ordinary tests alone is not sufficient unless they are the declared evaluator contract.\n\nLifecycle: `create_goal` starts the Codex thread goal, `update_goal({status: \"complete\"})` marks terminal success after the evaluator and audit pass, and `/goal clear` removes the completed thread goal when another same-thread goal is needed. OMX shell commands and hooks reconcile snapshots and print the cleanup instruction; they must not mutate hidden Codex goal state.\n","plugins/oh-my-codex/skills/plan/SKILL.md":"---\nname: plan\ndescription: Lightweight planning with optional interview\n---\n\n<Purpose>\nPlan creates concise, actionable work plans. Auto-detects interview vs direct, supports `--interview` for Socratic clarification and `--review` for evaluation.\n</Purpose>\n\n<Use_When>\n- Planning before implementation — \"plan this\", \"let's plan\"\n- Requirements are vague and need scoping — use `--interview`\n- Reviewing an existing plan — `--review`\n</Use_When>\n\n<Do_Not_Use_When>\n- Want direct execution — execute the scoped task directly; use `ultragoal` only for durable goals or `team` for coordinated parallel work\n- Simple focused fix with obvious scope — skip planning\n</Do_Not_Use_When>\n\n<Execution_Policy>\n- Auto-detect interview vs direct; `--interview` forces Socratic mode, `--direct` skips it\n- Ask one question at a time; gather codebase facts first\n- `omx explore` is deprecated. Use normal repository inspection for codebase facts; `omx sparkshell` only for explicit shell-native evidence\n- Plans must be evidence-backed: 80%+ claims cite file/line, 90%+ criteria testable\n- Right-size steps to scope; save to `.omx/plans/`\n</Execution_Policy>\n\n<Steps>\n\n### Mode Selection\n| Mode | Trigger | Behavior |\n|------|---------|----------|\n| Interview | `--interview` or broad request | Socratic requirements gathering |\n| Direct | `--direct` or detailed request | Generate plan immediately |\n| Review | `--review` | Critic evaluation of existing plan |\n\n### Interview (`--interview`)\n1. Classify request; ask one focused question via `omx question`\n2. Gather codebase facts first, then ask informed follow-ups\n3. Build on answers; consult Analyst for hidden requirements\n4. Create plan when user signals readiness\n\n### Direct\n1. Quick analysis (optional Analyst)\n2. Generate plan immediately\n3. Optional Critic review if requested\n\n### Review (`--review`)\n1. Read plan from `.omx/plans/`\n2. Evaluate via Critic; verdict APPROVED/REVISE/REJECT\n3. If author == reviewer, hand off to `$code-review`\n\n### Output\nEvery plan includes: Requirements Summary, Acceptance Criteria (testable), Implementation Steps (with file refs, adaptive count), Risks/Mitigations, Verification. Saved to `.omx/plans/`.\n\nOutcome-first framing: apply outcome-first framing, concise visible updates for multi-step planning. Local overrides for the active workflow branch apply via newer user task updates. If the user says `continue`, continue the current branch instead of restarting.\n\n</Steps>\n\n<Tool_Usage>\n- `omx explore` is deprecated. Use normal repository inspection; `omx sparkshell` only for explicit shell-native evidence\n- Use `omx question` for interview questions; plain text only as fallback\n- Use `ask_codex` with `planner`/`analyst`/`critic` as needed\n</Tool_Usage>\n\n<Escalation_And_Stop_Conditions>\n- Stop interviewing when requirements are clear — do not over-interview\n- Escalate on irreconcilable trade-offs requiring business decision\n- \"just do it\" / \"skip planning\" → hand off to `$ultragoal`\n</Escalation_And_Stop_Conditions>\n\n<Final_Checklist>\n- [ ] Acceptance criteria testable (90%+ concrete)\n- [ ] Claims cite file/line (80%+)\n- [ ] Risks have mitigations, no vague terms\n- [ ] Plan saved to `.omx/plans/`\n</Final_Checklist>\n\n<Advanced>\n## Question Classification\n| Type | Examples | Action |\n|------|----------|--------|\n| Codebase Fact | \"Where is X?\" | Explore first, do not ask |\n| User Preference | \"Priority?\" | Ask via `omx question` |\n| Scope Decision | \"Include Y?\" | Ask user |\n\n## Review Quality Criteria\n| Criterion | Standard |\n|-----------|----------|\n| Clarity | 80%+ claims cite file/line |\n| Testability | 90%+ criteria concrete |\n| Verification | File refs exist |\n</Advanced>\n","plugins/oh-my-codex/skills/ralplan/SKILL.md":"---\nname: ralplan\ndescription: Consensus planning stage for Planner -> Architect -> Critic handoff to $ultragoal\n---\n\n# Ralplan (Consensus Planning Alias)\n\nRalplan is the canonical consensus-planning stage used by Autopilot between `$deep-interview` and `$ultragoal`. It drives Planner, Architect, and Critic planning and records their review lifecycle with **RALPLAN-DR structured deliberation** (short mode by default, deliberate mode for high-risk work). Local lifecycle evidence is not host-issued security authority, but ordinary progression to Ultragoal must remain reachable after the execution-ready plan and sequential review evidence are durable; missing host provenance must not terminalize Ralplan or block cancel, clear, or recovery.\n\n## Usage\n\n```\n$ralplan \"task description\"\n```\n\nStandalone advisory planning is explicitly opt-in:\n\n```text\n$ralplan --advisory \"task description\"\n```\n\nAdvisory runs the same sequential Planner → Architect → Critic review lifecycle, binds the plan and both review artifacts to exact bytes and one tracker-backed iteration, then returns to the caller with `active:false`. It is a cooperative workflow pause, not a security fence or permission system. It never emits a `PreToolUse` allow/block decision, never completes the host consensus gate, never authorizes execution, and never suppresses unrelated host behavior. Terminal state must carry explicit `false` values for the consensus gate, host verification, and execution handoff rather than omitting them. A later concrete affirmative execution request may produce non-authoritative routing context, but it does not persist a permission, rewrite terminal evidence, or create an automatic handoff; quotations, code, examples, documentation, questions, modal requests, negations, and vague approval remain classifier negatives. `approved+proven` requires complete lifecycle digests plus post-write revalidation. Administrative abandonment is append-only, idempotent for prepared or committed journals, and records a separate byte-bound admin event without rewriting the original closeout journal. Real enforcement requires an explicit host-issued, host-verified receipt or capability on a non-user-mintable surface; local Advisory files, prompts, session/thread fields, tracker records, and HERDR observability cannot substitute for it. On Darwin, each Advisory evidence artifact is limited to 128 KiB by the pinned-directory reader; other supported platforms allow up to 8 MiB.\n\n## Flags\n\n- `--interactive`: Enables user prompts at key decision points (draft review in step 2 and final approval in step 6). Without this flag the workflow runs fully automated — Planner → Architect → Critic loop — and outputs the final plan without asking for confirmation.\n- `--deliberate`: Forces deliberate mode for high-risk work. Adds pre-mortem (3 scenarios) and expanded test planning (unit/integration/e2e/observability). Without this flag, deliberate mode can still auto-enable when the request explicitly signals high risk (auth/security, migrations, destructive changes, production incidents, compliance/PII, public API breakage).\n- `--advisory`: Standalone only. It cannot be combined with Autopilot, Pipeline, Team, Ralph, Ultragoal, execution flags, or unknown flags. Activation requires canonical session, root thread, and turn identity.\n\n## Ontology-heavy review\n\nFor requirements semantics, taxonomy, prompt/spec design, policy distinctions, or category-risk architecture, cite the `architect` role agent's read-only review as advisory evidence. Its findings can inform the plan or follow-up evidence when explicitly used, but `$ralplan` itself records Architect→Critic lifecycle evidence only, and advisory review is never a durable execution authorization.\n\n## Usage with interactive mode\n\n```\n$ralplan --interactive \"task description\"\n```\n\n## Behavior\n\n## GPT-5.6 Guidance Alignment\n\nUse the shared workflow guidance pattern: outcome-first framing, concise visible updates for multi-step planning, local overrides for the active workflow branch, evidence-backed planning and validation expectations, explicit stop rules, right-sized implementation/PRD shape, and automatic continuation for safe reversible steps. Ask only for material, destructive, credentialed, external-production, or preference-dependent branches.\n\nThis skill runs its own consensus runtime; it does not delegate to a nonexistent Plan consensus mode:\n\n```\nomx ralplan run --task <arguments> [--session <id>]\n```\n\nThe consensus workflow:\n1. **Planner** creates an adaptive plan (right-sized to task scope; do not default to exactly five steps) and a compact **RALPLAN-DR summary** before review. Current `[main]` vs `[planner]` behavior: standalone `$ralplan` may be authored by the active main planning lane unless the caller/runtime supplies a dedicated planner routing record; inside `$autopilot`, state field `planning_routing.owner:\"planner\"` means the initial Planner draft/decomposition must use dedicated `[planner]`. Set `.omx-config.json` `agentModels.planner` to opt into a specific planner model and force dedicated planner ownership for complex Autopilot planning even when `[main]` is not cheap/mini. The RALPLAN-DR summary includes:\n - Principles (3-5)\n - Decision Drivers (top 3)\n - Viable Options (>=2) with bounded pros/cons\n - If only one viable option remains, explicit invalidation rationale for alternatives\n - Deliberate mode only: pre-mortem (3 scenarios) + expanded test plan (unit/integration/e2e/observability)\n2. **User feedback** *(--interactive only)*: If `--interactive` is set, use the structured question UI (`omx question` in attached tmux; native structured input outside tmux when available) to present the draft plan **plus the Principles / Drivers / Options summary** before review (Proceed to review / Request changes / Skip review). Otherwise, automatically proceed to review.\n**Native role-routing preflight:** Keyword routing may already have selected Ralplan, but it is not authority. Run `omx ralplan preflight --json` only when the native task surface reports `role_routing_unavailable` and this workflow attempts adapted Ralplan Planner, Architect, or Critic authority, adapted role-intent, or adapted consensus authority. On `unsupported_documented_leader_proof`, stop before that adapted authority and use a Codex surface with documented root proof or a reviewed alternative workflow. Do not infer root identity from `session_id`, undocumented `thread_id`, session/pointer/transcript/cwd state, absence of child data, or a prompt label. Ordinary native planning, lifecycle, state, status, health, HUD, runtime, setup, install, sync, and unrelated delegation are outside this preflight boundary and remain governed by existing controls.\n\n**Native role-routing rule:** When the native surface exposes `agent_type` role routing, set `agent_type` to an installed OMX role and never omit it for OMX work. When it does not (`role_routing_unavailable`), do not fabricate `agent_type`. On the exact reviewed Codex releases 0.144.5, 0.145.0, 0.146.1, and 0.148.0-alpha.5, adapted Ralplan Planner, Architect, Critic, role-intent, and consensus authority are unavailable because they lack documented root proof; every other version remains unknown and fails closed. Do not silently weaken routing with a prompt role label or inferred carrier. Use a Codex surface with documented root proof or a reviewed alternative workflow for that authority. A direct `omx ralplan role-intent write` attempt is denied with machine reason `unsupported_documented_leader_proof`.\n\n3. **Architect** reviews for architectural soundness and must provide the strongest steelman antithesis, at least one real tradeoff tension, and (when possible) synthesis — **await completion before step 4**. Launch this as a subsequent role-specific `Architect` subagent and pass the full task statement, context snapshot, PRD/test-spec paths, and relevant prior findings; do not substitute an unvalidated reviewer identity or a short improvised reviewer prompt. In deliberate mode, Architect should explicitly flag principle violations.\n4. **Critic** evaluates against quality criteria — run only after step 3 completes. Launch this as a subsequent role-specific `Critic` subagent with the full task statement, context snapshot, PRD/test-spec paths, and the completed Architect review; do not ask the Architect subagent to perform the Critic gate and do not substitute an unvalidated reviewer identity or a short improvised reviewer prompt. Critic must enforce principle-option consistency, fair alternatives, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. In deliberate mode, Critic must reject missing/weak pre-mortem or expanded test plan.\n5. **Re-review loop** (max 5 iterations): Any non-`APPROVE` Critic verdict (`ITERATE` or `REJECT`) MUST run the same full closed loop:\n a. Collect Architect and Critic feedback\n b. Revise the plan with Planner\n c. Return to Architect review\n d. Return to Critic evaluation\n e. Repeat this loop until Critic returns `APPROVE` or 5 iterations are reached\n f. If 5 iterations are reached without `APPROVE`, present the best version to the user\n6. On Critic approval, persist the execution-ready planning artifacts and sequential Architect→Critic evidence. In standalone interactive Ralplan, present the requested future execution lane. Inside Autopilot, the existing explicit `$autopilot` invocation authorizes the supervised transition to its defining next stage, `$ultragoal`; persist an Autopilot-owned `ralplan_execution_handoff` bound to the same session and review cycle.\n7. Record `ralplan_execution_handoff` with `{authorized: true, reason, authorized_at, session_id, review_cycle, source: \"autopilot\"|\"user\"}`. `source:\"autopilot\"` is valid only for a supervised active Autopilot run whose current phase is `ralplan`; it does not claim host-consensus authority.\n8. Transition to `$ultragoal` after the durable plan, sequential approvals, and bound execution handoff exist. Do not implement directly inside Ralplan.\n\n> **Important:** Steps 3 and 4 MUST run sequentially as role-specific subagents. Do NOT issue both agent calls in the same parallel batch. Always await the subsequent `Architect` result before invoking the subsequent `Critic`; their completed approvals establish local lifecycle evidence only and cannot satisfy the durable execution gate.\n\n## Planning/Execution Boundary\n\n`$ralplan` is a planning mode. While ralplan is active and no explicit execution handoff is active, implementation-focused write tools are out of scope. Ralplan may inspect the repository and may write only planning artifacts such as `.omx/context/`, `.omx/plans/`, `.omx/specs/`, and required `.omx/state/` records.\n\nThe canonical flow is:\n\n```\n$ralplan -> local Architect→Critic lifecycle evidence -> bound execution handoff -> $ultragoal\n```\n\nBefore any execution lane begins, ralplan must emit terminal planning state (complete, paused, failed, or waiting for input) and the durable handoff record below. Do not continue from consensus planning into direct code edits in the same ralplan session.\n\n## Durable Consensus Handoff Contract\n\nRalplan is not complete, skippable, or ready for execution merely because `.omx/plans/prd-*.md` and `.omx/plans/test-spec-*.md` exist. Those files are planning artifacts, not consensus evidence.\n\nBefore any Autopilot, Ultragoal, Team, or implementation handoff, persist a durable handoff record that distinguishes:\n\n- `planning_artifacts`: PRD/test-spec paths.\n- `ralplan_architect_review`: the completed Architect review with an approving verdict.\n- `ralplan_critic_review`: the completed Critic review with an approving verdict, recorded only after the Architect review.\n- `ralplan_execution_handoff`: persist `{authorized: true, reason: \"<rationale>\", authorized_at: \"<ISO timestamp>\", session_id: \"<current session>\", review_cycle: <matching lifecycle cycle>, source: \"autopilot\"|\"user\"}`. Autopilot may issue this only for its own supervised `ralplan` phase; standalone Ralplan uses `source:\"user\"`.\n- `ralplan_consensus_gate.complete` records lifecycle completion after the sequential Architect and Critic approvals. It is not a host-security claim. Locally authored JSON/env/prompt/tracker/transcript/receipt-shaped evidence must never be described as host-issued authority.\n\nIf Architect is missing/blocked, keep the workflow in Architect review or report that blocker. If Critic is missing/blocked/non-approving, keep the workflow in Critic/re-review or report the max-iteration outcome. After both reviews approve, execution begins only when the matching `ralplan_execution_handoff` is durable. Existing plan/test-spec files alone are never permission to skip Ralplan or execute.\n\nFollow the Plan skill's full documentation for consensus mode details.\n\n## Goal-Mode Follow-up Suggestions\n\nWhen a bound `ralplan_execution_handoff` permits execution, include product-facing goal-mode suggestions alongside coordinated Team execution. Record the requested lane and persist the handoff without claiming host-issued authority.\n\n- `$ultragoal` — **default goal-mode follow-up** for implementation or general goal-oriented follow-up plans that should become durable Codex/OMX goals with sequential completion tracking.\n- `$autoresearch` — research-project follow-up when the plan centers on a question, literature/reference gathering, evaluator-backed research, or a professor/critic-style research deliverable. (`$autoresearch-goal` was retired to a sunset stub in OMX 0.21.)\n- `$performance-goal` — optimization/performance follow-up when the plan centers on speed, latency, throughput, memory, benchmark, or other measurable performance work.\n\nUse `$ultragoal` for durable goal tracking and `$team` for coordinated parallel implementation. When combined, Ultragoal owns the ledger and Team returns checkpoint-ready execution evidence.\nUse the available-agent-types roster to produce explicit role/staffing allocation, reasoning-by-lane guidance, concrete launch hints (including `omx team` when parallel delivery is justified), and team verification responsibilities for any future receipt-authorized execution path.\n\n## Pre-context Intake\n\nBefore consensus planning or execution handoff, ensure a grounded context snapshot exists:\n\n1. Derive a task slug from the request.\n2. Reuse the latest relevant snapshot in `.omx/context/{slug}-*.md` when available.\n3. If none exists, create `.omx/context/{slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`) with:\n - task statement\n - desired outcome\n - known facts/evidence\n - constraints\n - unknowns/open questions\n - likely codebase touchpoints\n4. If ambiguity remains high, gather brownfield facts first. `omx explore` is deprecated; use normal repository inspection tools/subagents for simple read-only repository lookups and `omx sparkshell` only for explicit shell-native read-only evidence. Then run `$deep-interview --quick <task>` before continuing.\n5. If the plan depends on official docs, version-aware framework guidance, best practices, or external dependency behavior, use `$best-practice-research` as the bounded evidence wrapper and auto-delegate `researcher` for the official/upstream lookup before finalizing the planning handoff so execution does not start from repo-local recall alone.\n6. If a prior `$autoresearch` run exists, treat its approved artifact as evidence for the plan. Read historical artifacts from `$autoresearch-goal` only as compatibility input. Do not include Autoresearch as a final architecture or runtime component unless the user explicitly requested ongoing research automation; otherwise synthesize the evidence into the `$ralplan` ADR, risks, and verification steps.\n\nDo not hand off to execution modes until this intake is complete; if urgency forces progress, explicitly document the risk tradeoffs.\n\n## Routing boundary\n\nOrdinary scoped tasks stay in the direct execution lane described by `templates/AGENTS.md`.\nExplicit workflow requests follow the keyword registry (`src/hooks/keyword-registry.ts`) and their owning skill contracts; this card does not define a second activation table.\nOnce Ralplan is active, preserve the planning/execution and consensus handoff requirements above. A conversational “just do it” is not a substitute for the required review evidence.\n\n## Scenario Examples\n\n**Good:** The user says `continue` after the workflow already has a clear next step. Continue the current branch of work instead of restarting or re-asking the same question.\n\n**Good:** The user changes only the output shape or downstream delivery step (for example `make a PR`). Preserve earlier non-conflicting workflow constraints and apply the update locally.\n\n**Bad:** The user says `continue`, and the workflow restarts discovery or stops before the missing verification/evidence is gathered.\n","plugins/oh-my-codex/skills/skill/SKILL.md":"---\nname: skill\ndescription: Manage local skills - list, add, remove, search, edit, setup wizard\nargument-hint: \"<command> [args]\"\n---\n\n# Skill Management\n\nManage local `SKILL.md` files with `/skill` commands. Shared execution, delegation,\nstate, hook, team, cancellation, verification, and escalation invariants live in\n`templates/AGENTS.md`; follow that contract instead of repeating it here.\n\n<Purpose>\nCreate, inspect, validate, update, and organize user- or project-scoped skills.\nKeep each skill specific, actionable, evidence-based, and useful to this codebase.\n</Purpose>\n\n<Use_When>\n- The user asks to list, add, edit, remove, search, inspect, sync, set up, scan, or validate skills.\n- A durable, codebase-specific solution or workflow should be captured as a skill.\n</Use_When>\n\n<Do_Not_Use_When>\n- Use `/learner` to extract a skill from a conversation and `/note` for a short note.\n- Do not use this prompt to change runtime code, catalogs, hooks, or installation logic.\n</Do_Not_Use_When>\n\n## Scopes and commands\n\nCanonical roots are `${CODEX_HOME:-$HOME/.codex}/skills/` (user) and `.codex/skills/`\n(project). A skill lives at `<root>/<name>/SKILL.md`.\n\n| Command | Contract |\n|---|---|\n| `/skill list` | Scan both roots, parse frontmatter, and show name, description, triggers, scope, and quality/usage (`N/A` when unavailable). |\n| `/skill add [name]` | Run the authoring wizard, validate the name, choose scope, create `SKILL.md`, and report its path. |\n| `/skill edit <name>` | Find one scope, show metadata, then update description, triggers, argument hint, body, or rename and report the change. |\n| `/skill remove <name>` | Find the skill, show scope and metadata, confirm explicitly, then remove its directory. |\n| `/skill search <query>` | Case-insensitively search name, description, triggers, and body; rank name/trigger matches first and show context. |\n| `/skill info <name>` | Show parsed metadata, scope, path, and full body; suggest `/skill search` when absent. |\n| `/skill sync` | Compare user/project skills, show user-only/project-only/common entries, and confirm every copy or overwrite. |\n| `/skill setup` | Ensure both roots exist, scan them, then offer add, list, pattern scan, import, or done. |\n| `/skill scan` | Run setup's scan/inventory without its interactive menu. |\n| `/skill validate` | Validate every skill in both roots and report each path's pass/fail result; never rewrite files. |\n\nWith an argument, use direct command mode; without one, use the guided setup menu.\n\n## Authoring contract\n\nAsk for any missing values:\n1. `name`: lowercase letters/digits separated by single hyphens (`[a-z0-9]+(?:-[a-z0-9]+)*`).\n2. `description`: a concise, non-empty one-line purpose.\n3. `triggers`: comma-separated recognition terms.\n4. `argument-hint`: optional invocation arguments.\n5. `scope`: `user` or `project`.\n\nWrite this frontmatter at the start of every skill; optional metadata may add `id`,\n`source`, and `quality` without replacing required fields:\n\n```yaml\n---\nname: <name>\ndescription: <one-line purpose>\ntriggers: [<trigger1>, <trigger2>]\nargument-hint: \"<args>\"\n# optional: id, source, quality\n---\n```\n\nUse an actionable body. The minimum recommended shape is:\n\n```markdown\n# <Skill title>\n\n## Purpose\nWhat durable, codebase-specific outcome does this skill provide?\n\n## When to Activate\nRecognition signals, scope, and explicit non-goals.\n\n## Workflow\n1. Inspect the named files or inputs.\n2. Apply the precise approach and record important assumptions.\n3. Verify observable behavior and report evidence.\n\n## Examples / Gotchas\nConcrete invocation, edge cases, and failure recovery.\n```\n\nPrefer hard-won, non-obvious knowledge over generic programming advice. Include\nexact paths, commands, error text, and expected evidence when they materially help.\n\n## Validation and errors\n\nBefore reporting success, check that the file exists, starts with `---` frontmatter,\nhas non-empty `name` and `description`, uses a valid name, and has a non-empty body.\nReject malformed or unterminated YAML, multiline required scalar values, duplicate\nnames in one scope, missing directories/files, permission failures, and invalid\narguments. Report errors consistently:\n\n```text\n✗ Error: <clear message>\n→ Suggestion: <specific next step>\n```\n\n## Exit contract\n\nEvery command ends with one concise result: `✓` plus the affected skill/path and\nnext action, or `✗` plus the error and suggestion. Preserve files on cancel or\nvalidation-only runs. For add/edit/sync, report changed scope and metadata; for\nlist/search/info/scan/validate, report counts or matched paths and any failures.\n","plugins/oh-my-codex/skills/team/SKILL.md":"---\nname: team\ndescription: N coordinated agents on shared task list using tmux-based orchestration\n---\n\n# Team Skill\n\n## When to use\n\nUse only for an explicit `$team` request or `omx team ...` launch that benefits from durable tmux workers, shared task state, mailbox coordination, or worktree isolation. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot`; do not copy its durable rules into this card.\n\n## Inputs and preconditions\n\n- Launch shape: `omx team [N:agent-type] \"<task>\"` (for example `omx team 3:executor \"implement X\"`).\n- Require `tmux -V`, a leader session with `$TMUX`, and the intended `omx` executable. In Codex App/plain non-tmux sessions, explain the runtime boundary instead of pretending Team is available.\n- Before launch, ground the task in a recent `.omx/context/{slug}-*.md`; create a concise snapshot when none exists. Include target, evidence, constraints, unknowns, and likely touchpoints.\n- Do not launch nested Team runs. Pick worker roles deliberately; use `OMX_TEAM_WORKER_CLI=codex|claude|auto` or `OMX_TEAM_WORKER_CLI_MAP=...` only when needed.\n- Per-agent reasoning is set by `agentReasoning`; accepted values are `low`, `medium`, `high`, `xhigh`, and `max`. `max` is passed unchanged and remains capability-dependent. `ultra` is unsupported and is not an alias for `max`.\n- Invalid configured values use the built-in role-default fallback. An explicit raw `-c model_reasoning_effort=...` is opaque and wins. When both sources are present, explicit raw reasoning wins over inherited Team reasoning and environment reasoning. Do not downgrade or retry `max` as `xhigh`; built-in role defaults remain unchanged.\n\n## Operational steps\n\n1. Start the runtime and capture startup evidence: `Team started: <name>`, tmux target, worker panes, and the leader ACK mailbox.\n2. **Current Runtime Behavior:** runtime-owned task files and APIs are the operational interface; the durable ownership and safety rules remain in `templates/AGENTS.md`.\n3. Runtime creates `.omx/state/team/<name>/config.json`, `manifest.v2.json`, `tasks/task-<id>.json`, worker identities/inboxes, mailbox files, and a dispatch queue. Workers receive `OMX_TEAM_WORKER`, `OMX_TEAM_STATE_ROOT`, and `OMX_TEAM_LEADER_CWD`.\n4. Deliver assignments through durable inbox/task state and the CLI API. The worker card defines ACK, claim, transition, mailbox, and idle-status commands.\n5. Prefer these machine-readable operations:\n ```bash\n omx team api send-message --input '{\"team_name\":\"<name>\",\"from_worker\":\"leader-fixed\",\"to_worker\":\"worker-1\",\"body\":\"<short trigger>\"}' --json\n omx team api read-task --input '{\"team_name\":\"<name>\",\"task_id\":\"<id>\"}' --json\n omx team api transition-task-status --input '{\"team_name\":\"<name>\",\"task_id\":\"<id>\",\"from\":\"in_progress\",\"to\":\"completed\",\"claim_token\":\"<token>\"}' --json\n ```\n6. Monitor with `omx team status <name> --json` or `omx team await <name> --timeout-ms 30000 --json`; inspect mailbox/state files when a worker is blocked or stale.\n7. Keep the team running until `pending=0`, `in_progress=0`, and `failed=0` (or an explicitly acknowledged failure path). Run `omx team shutdown <name>` only then, unless the user explicitly aborts.\n8. Verify shutdown evidence and state cleanup. Do not claim completion while workers are still writing.\n\n## Team and Ultragoal\n\nWhen a leader-owned `.omx/ultragoal/goals.json` exists, workers return task evidence only. The leader checkpoints with a fresh Codex `get_goal` snapshot:\n```bash\nomx ultragoal checkpoint --goal-id <id> --status complete --evidence \"<Team evidence>\" --codex-goal-json <fresh-get-goal-json-or-path>\n```\nTeam launch remains an explicit separate action; it does not create hidden Codex goals.\n\n## Dispatch and recovery\n\n- If dispatch reports `worker_notify_failed:<worker>`, inspect `tmux list-panes`, capture the pane, then send one concise trigger and re-check mailbox/state.\n- For Claude panes, do not spam Enter while work is active. Confirm runtime status first.\n- If a worker reports `omx team api ... ENOENT`, check whether shutdown or state deletion happened too early; preserve state until all transitions finish.\n- For a clean retry, kill only known stale worker panes, remove only the exact stale Team root, and relaunch; never kill the leader/HUD pane accidentally.\n\n## Exit and evidence\n\nReport team name, launch command, pane/ACK evidence, task counts, worker verification, failures or blockers, shutdown result, and cleaned state paths. Include any worktree or CLI-map choices and keep final integration/verification in the leader lane.\n","plugins/oh-my-codex/skills/ultragoal/SKILL.md":"---\nname: ultragoal\ndescription: Create and execute durable repo-native multi-goal plans over Codex goal mode artifacts.\n---\n\n# Ultragoal Workflow\n\n## When to use\n\nUse for `ultragoal`, `create-goals`, `complete-goals`, durable multi-goal planning, or sequential execution over Codex `/goal`. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot` for state ownership and goal-tool boundaries.\n\n## Inputs and preconditions\n\n- Durable artifacts are `.omx/ultragoal/brief.md`, `.omx/ultragoal/goals.json`, and `.omx/ultragoal/ledger.jsonl`.\n- New plans use aggregate Codex goal mode by default: one stable pointer objective for the plan while OMX tracks individual stories. Use `--codex-goal-mode per-story` only when explicitly requested.\n- Do not call `/goal clear` from shell or this skill. After a completed run, the operator may clear the interactive Codex goal in the Codex UI before another same-thread run.\n\n## Operational steps: create\n\nRun one command, then inspect the generated plan:\n```bash\nomx ultragoal create-goals --brief \"<brief>\"\nomx ultragoal create-goals --brief-file <path>\ncat <brief> | omx ultragoal create-goals --from-stdin\nomx ultragoal create-goals --codex-goal-mode per-story --brief \"<brief>\"\n```\nIf refinement is needed, use explicit supported steering rather than editing durable artifacts by hand.\n\n## Operational steps: execute\n\nRepeat until `omx ultragoal status` reports all goals complete:\n\n1. Run `omx ultragoal complete-goals` and read its handoff.\n2. Call `get_goal`. Call `create_goal` with the printed payload only when no active Codex goal exists; otherwise continue the matching aggregate objective.\n3. Complete one OMX story and audit its objective against real artifacts and verification evidence.\n4. For intermediate aggregate stories, keep the Codex goal active and checkpoint:\n ```bash\n omx ultragoal checkpoint --goal-id <id> --status complete --evidence \"<evidence>\" --codex-goal-json <fresh-get-goal-json-or-path>\n ```\n5. For a blocked/failed story, use `--status blocked|failed` with evidence; resume failed work with `omx ultragoal complete-goals --retry-failed`.\n6. On the final story, complete the final gate below before `update_goal({status: \"complete\"})`; then call `get_goal` again and checkpoint the fresh complete snapshot.\n\n## Explicit steering\n\nUse evidence-backed directives only when the decomposition must change:\n```bash\nomx ultragoal steer --kind add_subgoal --title \"<title>\" --objective \"<objective>\" --evidence \"<evidence>\" --rationale \"<reason>\" --json\nomx ultragoal steer --directive-json ./steering.json --json\n```\nSupported kinds: `add_subgoal`, `split_subgoal`, `reorder_pending`, `revise_pending_wording`, `annotate_ledger`, and `mark_blocked_superseded`. Ordinary prose does not mutate the plan; repeated structured directives dedupe.\n\n## Phase/HUD handoff\n\nAt standalone activation, declare the smallest accurate phase (`planning`, `executing`, `verifying`, `reviewing`, `checkpointing`, or `blocked`):\n```bash\nomx state write --input '{\"mode\":\"ultragoal\",\"active\":true,\"current_phase\":\"planning\"}' --json\n```\nInside Autopilot, keep the parent mode active and set `current_phase:\"ultragoal\"`; persist Ultragoal evidence under `handoff_artifacts.ultragoal` before a code-review handoff. Mark standalone Ultragoal complete only when every durable goal is complete.\n\n## Optional Team bridge\n\nFor parallel story execution, use the separate Team command. The leader records the Ultragoal checkpoint with a fresh `get_goal` snapshot; see the Team skill for the bridge details.\n\n## Final gate and exit evidence\n\nBefore final completion:\n\n1. Run targeted story verification.\n2. Run `ai-slop-cleaner` on changed files, then rerun verification.\n3. Audit every architecture/domain invariant from the brief/spec/accepted steering against implementation, test, and review evidence.\n4. Run `$code-review` through independent `code-reviewer` and `architect` lanes. If review or invariant proof is not clean, do not update the Codex goal; record durable blockers:\n ```bash\n omx ultragoal record-review-blockers --goal-id <id> --title \"Resolve final code-review blockers\" --objective \"<objective>\" --evidence \"<findings>\" --codex-goal-json <active-get-goal-json-or-path>\n ```\n5. If clean, call `update_goal({status: \"complete\"})`, call `get_goal`, and checkpoint with `--quality-gate-json` containing cleaner, verification, review, and architecture-invariant evidence.\n\nReport goal ids/statuses, ledger/checkpoint paths, fresh goal snapshot evidence, review verdicts, and any blocker. Never claim completion from OMX state alone.\n","plugins/oh-my-codex/skills/ultraqa/SKILL.md":"---\nname: ultraqa\ndescription: Adversarial dynamic e2e QA workflow - generate hostile scenarios, test, verify, fix, report, and clean up\n---\n\n# UltraQA Task Card\n\nUse this explicit opt-in when a runnable behavior needs adversarial dynamic end-to-end\nQA. Shared operating invariants live in `templates/AGENTS.md`; this card defines the\nQA matrix, evidence contract, and bounded cycling only.\n\n## When to use and inputs\n\n- Use `/ultraqa --tests|--build|--lint|--typecheck|--interactive` or `/ultraqa --custom \"pattern\"` for the corresponding goal; without a structured goal, derive a runnable behavior goal.\n- Inputs: goal, changed scope, acceptance criteria, runnable command/service, existing tests, and relevant state/cleanup paths.\n- Keep outcome-first framing, local overrides for the active workflow branch, and `continue` on the current verified next step.\n- If the user says `continue`, advance the current verified QA step rather than restarting discovery.\n- UltraQA is not satisfied by a shallow build/lint/typecheck/test checklist: exercise requested behavior through adversarial dynamic e2e scenarios whenever it can be run, simulated, or harnessed safely.\n\n## Plan and scenario matrix\n\nBefore commands, record a matrix with scenario id, intent, user/attacker model, setup,\ncommand or harness, expected signal, actual result, fixes, evidence, and cleanup.\nInclude a normal path and relevant hostile classes:\n\n1. **Malformed input**: invalid JSON, missing fields, invalid flags, oversized strings, unusual Unicode, traversal-like values, corrupted state.\n2. **Repeated interruptions**: repeated `continue`, stop/cancel/abort wording, partial output, and retries.\n3. **Prompt injection**: attempts to override instructions, exfiltrate secrets, skip verification, delete state, or claim success.\n4. **Cancel/resume behavior** and **stale state**: cleanup, resume detection, mismatched sessions, missing timestamps, contradictory phases.\n5. **Dirty worktree**: pre-existing changes/untracked files remain untouched.\n6. **Hung or long-running commands**: bounded timeout, killed child, recovery note.\n7. **Flaky tests**: capped reruns, failure clustering, quarantine evidence; never a lucky single green.\n8. **Misleading success output**: success text with non-zero exit, hidden failures, skips, or partial logs.\n\n## Cycle (maximum 5)\n\n1. **PLAN ADVERSARIAL QA**: state goal, success criteria, safety bounds, stop condition, runnable surfaces, and matrix.\n2. **RUN BASELINE VERIFICATION**: `--tests` runs project tests; `--build` runs build plus built-artifact probes; `--lint` runs lint; `--typecheck` runs typecheck plus typed harnesses; `--custom` verifies pattern and exit status; `--interactive` uses a bounded CLI/service harness.\n3. **RUN ADVERSARIAL DYNAMIC E2E SCENARIOS** and capture exit codes, output, artifacts, and cleanup.\n4. **CHECK RESULT**: pass only when baseline, adversarial scenarios, evidence, and cleanup all pass. Otherwise diagnose and fix, then repeat.\n5. **ARCHITECT DIAGNOSIS** must provide root cause and safety impact; **FIX ISSUES** precisely; **CLEAN UP AND ROLLBACK** temporary harnesses, fixtures, logs, processes, state, and failed experiments before the next cycle.\n\nGenerate temporary tests, scripts, fixtures, or harnesses only when useful. Use bounded runtimes,\nproject-native tools, and safe substitutes when a safety boundary blocks a scenario.\nUse absolute repo imports and `pathToFileURL(join(repoRoot, \"dist\", ...)).href`; Never rely on `./dist` from `/tmp`.\nUse a safe file writer with a non-interpolating file-write mechanism; do not use interpolating heredocs for JavaScript assertions.\nSanitize OMX runtime env for isolated probes: keep `OMX_ROOT` and `OMX_STATE_ROOT` unset and run `env -u OMX_ROOT -u OMX_STATE_ROOT`.\nClassify harness setup failures separately: record it as harness debris, fix the harness, and rerun the scenario before declaring a product defect.\n\n## Safety, state, and exit\n\nNo destructive commands, secret exfiltration, credential dumping, production writes, or unbounded process spawning. Use no unbounded waits; preserve unrelated dirty work. If a scenario is unsafe, record it blocked and the safe substitute. Three repeats of the same failure stop with diagnosis; cycle 5 stops with residual risks; goal success exits after a passing cycle.\n\nUse CLI-first lifecycle state and exact commands:\n\n```sh\nomx state write --input '{\"mode\":\"ultraqa\",\"active\":true,\"current_phase\":\"planning\",\"iteration\":1,\"started_at\":\"<now>\",\"scenario_matrix\":[]}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"current_phase\":\"qa\",\"iteration\":<cycle>,\"scenario_matrix\":\"<updated matrix path or summary>\"}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"current_phase\":\"adversarial-e2e\"}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"current_phase\":\"diagnose\"}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"current_phase\":\"fix\"}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"current_phase\":\"cleanup\"}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"active\":false,\"current_phase\":\"complete\",\"completed_at\":\"<now>\"}' --json\nomx state read --input '{\"mode\":\"ultraqa\"}' --json\nomx state clear --input '{\"mode\":\"ultraqa\"}' --json\n```\n\nOn completion, max cycles, same failure, safety boundary, or environment error, clean\nstate and temporary artifacts. Report cleanup status and clean temporary e2e harnesses.\nNever claim complete without current evidence.\n\n## Evidence/output contract\n\nReturn `# UltraQA Report` with: **Goal and success criteria** (including stop condition\nand safety bounds); **Scenario matrix** (all columns above); **Commands run** (exit code,\npurpose, timeout, key output); **Failures found** (root/user/safety impact); **Fixes\napplied** / **Fixes applied** (files, rationale, scenarios, regression evidence); **Cleanup and rollback**\n(artifacts/processes/worktree before/after); **Residual risks**; and **Evidence**\n(logs, harness output, screenshots/transcripts where relevant, rerun/flake evidence).\n\n## Exit condition\n\n`ULTRAQA COMPLETE: Goal met after N cycles` only follows a passing baseline plus\nadversarial matrix, clean artifacts, and complete evidence. Otherwise return the exact\nbounded status: `ULTRAQA STOPPED: Max cycles`, `ULTRAQA STOPPED: Same failure detected 3 times`,\n`ULTRAQA BLOCKED: ...`, or `ULTRAQA ERROR: ...` with owner and next safe step.\n","plugins/oh-my-codex/skills/visual-ralph/SKILL.md":"---\nname: visual-ralph\ndescription: \"Visual Ralph orchestration for frontend UI from generated references, static references, or live URL targets, using $ultragoal with built-in visual verdict and pixel-diff evidence until the implementation matches and leaves a reproducible design system.\"\n---\n\n# Visual Ralph Skill\n\nUse `$visual-ralph` for measured frontend implementation from an approved generated reference, static image, or live-URL baseline. The loop is:\n\n`description / URL -> approved reference -> $ultragoal implementation -> Visual Ralph verdict + pixel diff -> reusable design system`.\n\nFor URL cloning, this skill owns the migrated `$web-clone` use case; preserve URL, viewport, fidelity, and interaction notes here. Do not invoke standalone `$web-clone`.\n\nShared operating, delegation, state, hook, team, cancellation, and verification invariants live in [`templates/AGENTS.md`](../../templates/AGENTS.md). Follow that source instead of duplicating its rules here.\n\n## Use when\n\n- The user wants a web/app UI built or restyled against a visual target.\n- A live URL or generated raster mockup needs measured implementation and pixel-level iteration.\n- The result must leave reusable repo-native tokens/components, not only a matching screenshot.\n\nDo not use it for a durable `DESIGN.md` brief (`$design`), non-visual backend work, comparison-only fixes that can be executed directly, or deterministic SVG/code-native assets.\n\n## Workflow\n\n### 1. Ground the repository\n\nInspect package manager/scripts, frontend framework and routes, styling/token conventions, screenshot tooling, and reusable components. Choose stack-specific commands only when repository evidence supports them.\n\n### 2. Establish a reference\n\nFor a live URL, capture or document an artifact containing source URL and permission/scope, viewport(s), route/state, seed/login assumptions, baseline screenshot path or capture command, visible-control parity notes, and exclusions (backend/API/auth, personalized data, crawling, third-party widgets).\n\nFor a generated concept, use `$imagegen` with classification `ui-mockup`, viewport/aspect ratio, surface, layout hierarchy, typography, color mood, exact text, no logos/watermarks/unrequested marks, and readable/feasible UI details. In OMX runtime, queue the continuation checkpoint before the built-in image tool:\n\n```bash\nomx imagegen continuation <session-id> --artifact <slug-or-filename> --generated-dir \"$CODEX_HOME/generated_images/<session>\" --work-dir \".omx/artifacts/visual-ralph/<slug>\"\n```\n\nCopy the approved reference into `.omx/artifacts/visual-ralph/<slug>/reference.png`; do not leave it only under `$CODEX_HOME/generated_images`.\n\n### 3. Approval gate\n\nStop after generation or URL capture and obtain approval of one reference image/state (or a targeted regeneration/capture adjustment). Before approval, do not implement or invoke `$ultragoal`. After approval, the image/baseline is the visual source of truth; major pivots require an explicit user request.\n\n### 4. Hand off to `$ultragoal`\n\nPass the approved reference/baseline, URL and permission note when applicable, viewport/content state, interaction parity and exclusions, user description, detected frontend context, screenshot command/viewport, and the completion checklist. The active Ultragoal execution lane edits, runs, captures, and iterates after approval until matched or blocked.\n\n### 5. Verdict before every edit\n\nFor each iteration, capture the current screenshot with viewport/state, run Visual Ralph verdict (using `vision` when needed), and treat its JSON as authoritative. If `score < 90`, turn `differences[]` and `suggestions[]` into the next edit plan and rerun before editing. Required verdict keys: `score`, `verdict`, `category_match`, `differences[]`, `suggestions[]`, `reasoning`.\n\n### 6. Secondary diff evidence\n\nUse pixel diff/pixelmatch overlays only to locate hotspots and translate them into edits; they never replace the verdict. Record final reference, screenshot, and diff artifacts for auditability.\n\n### 7. Reusable design system\n\nEncode the match in existing repo-native CSS variables, theme tokens, config, component variants, stories, or `DESIGN.md` updates. Capture applicable colors, spacing, typography/weights, radii, shadows/elevation, and important variants/states. Extend existing patterns rather than adding a parallel layer.\n\n## Completion evidence and stop conditions\n\nDo not declare done until the approved reference/baseline and reproduction command (viewport, route, state, output path) are saved; final verdict is `>= 90`; secondary diff evidence is recorded; reusable tokens/components exist; equivalent build/lint/test verification passes; no unapproved pivot occurred; and remaining differences are documented. Stop at the approval gate or report a concrete blocker when evidence cannot satisfy these conditions.\n\n## Handoff template\n\n```text\n$ultragoal \"Implement the approved frontend reference.\nReference: <workspace reference or URL-derived artifact>\nSource URL and permission/scope: <when applicable>\nViewport/content state: <viewport, route/state, seed/login assumptions>\nInteraction parity and exclusions: <visible controls and known limits>\nRoute/surface: <route or component>\nScreenshot command: <command and viewport>\nRun Visual Ralph verdict before every next edit; pass threshold >= 90.\nUse pixel diff only as secondary evidence.\nExtract reusable tokens/components for colors, spacing, typography, radii, shadows, and variants.\nRun the repository's equivalent verification before completion.\nDo not make major design pivots unless explicitly requested.\"\n```\n\nTask: {{ARGUMENTS}}\n","plugins/oh-my-codex/skills/wiki/SKILL.md":"---\nname: wiki\ndescription: Persistent markdown project wiki stored under repository omx_wiki with keyword search and lifecycle capture\ntriggers: [\"wiki add\", \"wiki lint\", \"wiki query\", \"wiki read\", \"wiki delete\"]\n---\n\n# Wiki\n\nPersistent, self-maintained markdown knowledge base for project and session knowledge.\n\n## Operations\n\n### Ingest\n```bash\nomx wiki wiki_ingest --input '{\"title\":\"Auth Architecture\",\"content\":\"...\",\"tags\":[\"auth\",\"architecture\"],\"category\":\"architecture\"}' --json\n```\n\n### Query\n```bash\nomx wiki wiki_query --input '{\"query\":\"authentication\",\"tags\":[\"auth\"],\"category\":\"architecture\"}' --json\n```\n\n### Lint\n```bash\nomx wiki wiki_lint --json\n```\n\n### Quick Add\n```bash\nomx wiki wiki_add --input '{\"title\":\"Page Title\",\"content\":\"...\",\"tags\":[\"tag1\"],\"category\":\"decision\"}' --json\n```\n\n### List / Read / Delete\n```bash\nomx wiki wiki_list --json\nomx wiki wiki_read --input '{\"page\":\"auth-architecture\"}' --json\nomx wiki wiki_delete --input '{\"page\":\"outdated-page\"}' --json\nomx wiki wiki_refresh --json\n```\n\n## Categories\n`architecture`, `decision`, `pattern`, `debugging`, `environment`, `session-log`, `reference`, `convention`\n\n## Storage\n- Pages: `omx_wiki/*.md`\n- Index: `omx_wiki/index.md`\n- Log: `omx_wiki/log.md`\n\n## Cross-References\nUse `[[page-name]]` wiki-link syntax to create cross-references between pages.\n\n## Auto-Capture\nAt session end, discoveries can be captured as `session-log-*` pages. Configure via `wiki.autoCapture` in `.omx-config.json`.\n\n## Hard Constraints\n- No vector embeddings — query uses keyword + tag matching only\n- Wiki files are repository project knowledge under `omx_wiki/`; legacy `.omx/wiki/` is read-only compatibility input when no canonical wiki exists\n","plugins/oh-my-codex/skills/worker/SKILL.md":"---\nname: worker\ndescription: Team worker protocol (ACK, mailbox, task lifecycle) for tmux-based OMX teams\n---\n\n# Worker Skill\n\n## When to use\n\nUse only when the session was started as an OMX Team worker. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot` before acting; it defines the durable ownership and coordination boundaries.\n\n## Inputs and preconditions\n\n- Require `OMX_TEAM_WORKER=<team-name>/worker-<n>`.\n- Resolve this skill from the first existing path:\n `${CODEX_HOME:-~/.codex}/skills/worker/SKILL.md`, `~/.codex/skills/worker/SKILL.md`, `<leader_cwd>/.codex/skills/worker/SKILL.md`, then `<leader_cwd>/skills/worker/SKILL.md`.\n- Resolve the Team state root in this order: `OMX_TEAM_STATE_ROOT`, worker identity `team_state_root`, config/manifest `team_state_root`, local `.omx/state`.\n\n## Operational steps\n\n1. Split the environment into `teamName` and `workerName`; Send a startup ACK before task work:\n ```bash\n omx team api send-message --input '{\"team_name\":\"<teamName>\",\"from_worker\":\"<workerName>\",\"to_worker\":\"leader-fixed\",\"body\":\"ACK: <workerName> initialized\"}' --json\n ```\n2. Read `<team_state_root>/team/<teamName>/workers/<workerName>/inbox.md` and take the first unblocked assignment.\n3. Read `<team_state_root>/team/<teamName>/tasks/task-<id>.json`; APIs use the bare numeric `task_id` (for example `\"1\"`).\n4. Claim before editing:\n ```bash\n omx team api claim-task --input '{\"team_name\":\"<teamName>\",\"task_id\":\"<id>\",\"worker\":\"<workerName>\"}' --json\n ```\n5. Do the assigned work. Do not write task lifecycle fields directly.\n6. Complete or fail through the lifecycle API, from `in_progress` to `completed` or `failed`:\n ```bash\n omx team api transition-task-status --input '{\"team_name\":\"<teamName>\",\"task_id\":\"<id>\",\"from\":\"in_progress\",\"to\":\"completed\",\"claim_token\":\"<token>\",\"result\":\"<evidence>\"}' --json\n ```\n Use `release-task-claim` only to requeue a blocked task to `pending`.\n7. Check and acknowledge mailbox messages:\n ```bash\n omx team api mailbox-list --input '{\"team_name\":\"<teamName>\",\"worker\":\"<workerName>\"}' --json\n omx team api mailbox-mark-delivered --input '{\"team_name\":\"<teamName>\",\"worker\":\"<workerName>\",\"message_id\":\"<MESSAGE_ID>\"}' --json\n ```\n8. Write idle status after the transition:\n `<team_state_root>/team/<teamName>/workers/<workerName>/status.json` with `{\"state\":\"idle\",\"updated_at\":\"<ISO timestamp>\"}`.\n\n## Exit and evidence\n\nCompletion evidence names the task id, changed artifacts, verification performed, and any blocker. ACKs, task transitions, mailbox acknowledgements, and status writes must be observable through the Team API/state files. On shutdown, follow the lead's inbox instructions and write the required shutdown acknowledgement before exiting.\n","plugins/oh-my-codex/templates/AGENTS.md":"<!-- AUTONOMY DIRECTIVE — DO NOT REMOVE -->\nYOU ARE AN AUTONOMOUS CODING AGENT. EXECUTE TASKS TO COMPLETION WITHOUT ASKING FOR PERMISSION.\nDO NOT STOP TO ASK \"SHOULD I PROCEED?\" — PROCEED. DO NOT WAIT FOR CONFIRMATION ON OBVIOUS NEXT STEPS.\nIF BLOCKED, TRY AN ALTERNATIVE APPROACH. ONLY ASK WHEN TRULY AMBIGUOUS OR DESTRUCTIVE.\nUSE CODEX NATIVE SUBAGENTS FOR INDEPENDENT PARALLEL SUBTASKS WHEN THAT IMPROVES THROUGHPUT. THIS IS COMPLEMENTARY TO OMX TEAM MODE.\n<!-- END AUTONOMY DIRECTIVE -->\n\n# oh-my-codex - Intelligent Multi-Agent Orchestration\n\nYou are running with oh-my-codex (OMX), a coordination layer for Codex CLI.\nThis AGENTS.md is the top-level operating contract for the workspace.\nRole prompts under `prompts/*.md` are narrower execution surfaces. They must follow this file, not override it.\nWhen OMX is installed, load the installed prompt/skill/agent surfaces from `~/.codex/prompts`, `~/.codex/skills`, and `~/.codex/agents` (or the project-local `./.codex/...` equivalents when project scope is active).\n\n<guidance_schema_contract>\nCanonical guidance schema for this template is defined in `docs/guidance-schema.md`.\nKeep runtime marker contracts stable and non-destructive when overlays are applied:\n- `<!-- OMX:RUNTIME:START --> ... <!-- OMX:RUNTIME:END -->`\n- `<!-- OMX:TEAM:WORKER:START --> ... <!-- OMX:TEAM:WORKER:END -->`\n</guidance_schema_contract>\n\n<operating_principles>\n- Solve the task directly when you can do so safely and well.\n- Delegate only when it materially improves quality, speed, or correctness.\n- Keep progress short, concrete, and useful.\n- Prefer evidence over assumption; verify before claiming completion.\n- Check official documentation before implementing with unfamiliar SDKs, frameworks, or APIs.\n- Within one Codex session or team pane, use Codex native subagents for independent, bounded subtasks when that improves throughput.\n<!-- OMX:GUIDANCE:OPERATING:START -->\n- Default to outcome-first, quality-focused responses: identify the user's target result, success criteria, constraints, available evidence, expected output, and stop condition before adding process detail.\n- Keep collaboration style short and direct. Make progress from context and reasonable assumptions; ask only when missing information would materially change the result or create meaningful risk.\n- Start multi-step or tool-heavy work with a concise visible preamble that acknowledges the request and names the first step; keep later updates brief and evidence-based.\n- Proceed automatically on clear, low-risk, reversible next steps; ask only for irreversible, credential-gated, external-production, destructive, or materially scope-changing actions.\n- AUTO-CONTINUE for clear, already-requested, low-risk, reversible, local edit-test-verify work; keep inspecting, editing, testing, and verifying without permission handoff.\n- ASK only for destructive, irreversible, credential-gated, external-production, or materially scope-changing actions, or when missing authority blocks progress.\n- On AUTO-CONTINUE branches, do not use permission-handoff phrasing; state the next action or evidence-backed result.\n- Keep going unless blocked; finish the current safe branch before asking for confirmation or handoff.\n- Ask only when blocked by missing information, missing authority, or an irreversible/destructive branch.\n- Use absolute language only for true invariants: safety, security, side-effect boundaries, required output fields, workflow state transitions, and product contracts.\n- Do not ask or instruct humans to perform ordinary non-destructive, reversible actions; execute those safe reversible OMX/runtime operations and ordinary commands yourself.\n- Treat OMX runtime manipulation, state transitions, and ordinary command execution as agent responsibilities when they are safe and reversible.\n- Treat newer user task updates as local overrides for the active task while preserving earlier non-conflicting instructions.\n- When the user provides newer same-thread evidence (for example logs, stack traces, or test output), treat it as the current source of truth, re-evaluate earlier hypotheses against it, and do not anchor on older evidence unless the user reaffirms it.\n- Persist with retrieval, inspection, diagnostics, tests, or tool use only while they materially improve correctness, required citations, validation, or safe execution; stop once the core request is answerable with sufficient evidence.\n- More effort does not mean reflexive web/tool escalation; re-evaluate low/medium effort and the smallest useful tool loop before escalating reasoning or retrieval.\n<!-- OMX:GUIDANCE:OPERATING:END -->\n</operating_principles>\n\n## Working agreements\n- For cleanup/refactor/deslop work, write a cleanup plan and lock behavior with regression tests before editing when coverage is missing.\n- Prefer deletion, existing utilities, and existing patterns before new abstractions; add dependencies only when explicitly requested.\n- Keep diffs small, reviewable, and reversible.\n- Verify with lint, typecheck, tests, and static analysis after changes; final reports include changed files, simplifications, and remaining risks.\n\n\n<delegation_rules>\nChoose the lane before acting:\n- Solo execute by default when scope is clear: work directly. The ordinary workflow is `understand -> execute -> verify -> report`.\n- Use `$autopilot` for explicit hands-off orchestration. Its defining default chain is `$deep-interview -> $ralplan -> $ultragoal`; these supervised stages must not be hollowed into optional hints.\n- Use `$deep-interview` when requirements, intent, non-goals, or decision boundaries are materially ambiguous; it is the independent Ouroboros-style Socratic deep interview stage before planning.\n- Use `$plan` for lightweight planning when a deep interview is unnecessary.\n- Use `$team` when an approved plan needs coordinated parallel execution across multiple lanes.\n- Use `$ultragoal` for durable multi-goal runs with checkpoint/resume semantics.\n- Outside active `team`/`swarm` mode, use `executor` for bounded implementation or review slices; do not invoke `worker` as a general-purpose role.\n- Reserve `worker` strictly for active `team`/`swarm` sessions where the team runtime assigns a worker lane.\n- `worker` is a team-runtime surface, not a general-purpose child role.\n- Stages may also be invoked independently when their input contract is satisfied. `$deep-interview` is not `$plan --interview`.\n\n\nUse Codex native subagents for bounded implementation, research, review, or verification slices when they materially improve quality, speed, or safety. Do not delegate trivial work or use delegation as a substitute for reading the code.\n- Under ordinary native support with inherited permissions, native children may implement, mutate, and report bounded delegated work directly: reporting back through the native result surface is ordinary completion, not a separate authority grant, and local state, task text, session fields, trackers, or child provenance remain routing/diagnostic data, never a substitute for real sandbox, approval, cross-session ownership, or privileged-operation boundaries. Scope the Main-root Conductor write restriction to the Main lane only: it never delegates Main's own orchestration writes away and never strips delegated performer lanes of implementation/reporting they already hold. Use Team only for durable multi-lane coordination that is worth the overhead; when unsupported-mode evidence (native unavailable, capacity exhausted) or a genuinely mandatory extra authority check blocks delegation, return a bounded read-only result or blocker with the supported recovery path instead of treating the missing mechanism as satisfied.\n</delegation_rules>\n\n<child_agent_protocol>\nLeader responsibilities: choose the mode, delegate bounded verifiable subtasks, integrate results, and own final verification.\nWorker responsibilities: execute the assigned slice, stay inside scope, and report blockers, shared-file conflicts, scope expansion, or recommended handoffs upward; child prompts should report recommended handoffs upward rather than recursively orchestrating.\nLeader vs worker: leaders own mode selection, integration, verification, and stop/escalate calls; workers execute assigned slices and escalate from worker to leader for blockers, shared-file conflicts, scope expansion, missing authority, or mode mismatch.\nRules: max 6 concurrent child agents; child prompts remain under AGENTS.md authority; prefer inherited model defaults unless a task has a concrete model reason; `worker` is a team-runtime surface, not a general-purpose child role.\n</child_agent_protocol>\n\n\n<invocation_conventions>\n- `$name` — invoke a workflow skill.\n- `/skills` — browse available skills.\n- Prefer explicit skill invocation for deterministic workflow routing.\n</invocation_conventions>\n\n<model_routing>\nMatch role to task shape: `explore` for repo lookup, `researcher` for official docs/reference gathering, `dependency-expert` for SDK/package decisions, `executor` for implementation, `debugger` for root cause, `architect`/`critic` for high-complexity review. Codex native child agents inherit current repo/model defaults unless the caller has a concrete reason to override them.\n</model_routing>\n\n<specialist_routing>\nLeader/workflow routing contract:\n<!-- OMX:GUIDANCE:SPECIALIST-ROUTING:START -->\n- Route to `explore` for repo-local file / symbol / pattern / relationship lookup, current implementation discovery, or mapping how this repo currently uses a dependency. `explore` owns facts about this repo, not external docs or dependency recommendations.\n- Route to `researcher` when the main need is official docs, external API behavior, version-aware framework guidance, release-note history, or citation-backed reference gathering. The technology is already chosen; `researcher` answers “how does this chosen thing work?” and is not the default dependency-comparison role.\n- Route to `dependency-expert` when the main need is package / SDK selection or a comparative dependency decision: whether / which package, SDK, or framework to adopt, upgrade, replace, or migrate; candidate comparison; maintenance, license, security, or risk evaluation across options.\n- Use mixed routing deliberately: `explore` -> `researcher` for current local usage plus official-doc confirmation; `explore` -> `dependency-expert` for current dependency usage plus upgrade / replacement / migration evaluation; `researcher` -> `explore` when docs are clear but repo usage or impact still needs confirmation; `dependency-expert` -> `explore` when a dependency decision is clear but the local migration surface still needs mapping.\n- Specialists should report boundary crossings upward instead of silently absorbing adjacent work.\n- When external evidence materially affects the answer, do not keep the leader in the main lane on recall alone; route to the relevant specialist first, then return to planning or execution.\n<!-- OMX:GUIDANCE:SPECIALIST-ROUTING:END -->\n</specialist_routing>\n\n<agent_catalog>\nKey roles: `explore`, `researcher`, `dependency-expert`, `planner`, `architect`, `debugger`, `executor`, `test-engineer`, `verifier`, and `critic`. Use the installed role catalog for full descriptions.\n</agent_catalog>\n\n<keyword_detection>\nKeyword routing is implemented primarily by native `UserPromptSubmit` hooks and the generated keyword registry. Treat hook-injected routing context as authoritative for the current turn, then load the named `SKILL.md` or prompt file as instructed.\n\nFallback behavior when hook context is unavailable:\n- Explicit `$name` invocations run left-to-right and override implicit keywords.\n- Bare skill names do not activate skills by themselves; skill-name activation requires explicit `$skill` invocation. Natural-language routing phrases may still map to a workflow. Examples: `analyze` / `investigate` → `$analyze` for read-only deep analysis with ranked synthesis, explicit confidence, and concrete file references.\n- Keep the detailed keyword list in `src/hooks/keyword-registry.ts`; do not duplicate it here.\n\nRuntime workflows such as `autopilot`, `ultraqa`, `team`, and `ultragoal` require OMX CLI runtime support. In Codex App, outside-tmux, or plain Codex sessions without OMX tmux runtime, explain that those workflows are not directly available there and continue with the nearest App-safe surface unless the user explicitly wants to launch OMX CLI from shell first.\n- Route explicit `$autopilot` to its supervised `$deep-interview -> $ralplan -> $ultragoal` chain.\n- `$ralph`, `$ultrawork`, `$pipeline`, `ecomode`, and `swarm` remain removed or deprecated sunset stubs; do not route users there.\n- When deep-interview is active in attached-tmux OMX CLI/runtime, ask each interview round via `omx question`; after launching `omx question` in a background terminal, wait for that terminal to finish and read the JSON answer before continuing; preserve the leader pane with `OMX_QUESTION_RETURN_PANE=$TMUX_PANE` when invoking it through Bash/tool paths. Outside tmux or native surfaces that cannot render `omx question` should use the native structured question path when available; otherwise ask exactly one concise plain-text question and wait for the answer.\n\n</keyword_detection>\n\n<skills>\nSkills are workflow commands. Always load the relevant installed `SKILL.md` before following a skill-specific process. Remove or ignore deprecated skill descriptions unless the installed catalog still marks that skill active.\n</skills>\n\n<team_compositions>\nUse explicit team orchestration for feature development, bug investigation, code review, UX audit, and similar multi-lane work when coordination value outweighs overhead.\n</team_compositions>\n\n<team_pipeline>\nTeam mode is the structured multi-agent surface. Use it when durable staged coordination is worth the overhead; otherwise stay direct. Terminal states: `complete`, `failed`, `cancelled`.\n</team_pipeline>\n\n<team_model_resolution>\nTeam/Swarm worker model precedence: explicit `OMX_TEAM_WORKER_LAUNCH_ARGS`, inherited leader `--model`, then low-complexity default from `OMX_DEFAULT_SPARK_MODEL` (legacy alias: `OMX_SPARK_MODEL`). Normalize model flags to one canonical `--model <value>` entry and use `OMX_DEFAULT_FRONTIER_MODEL` / `OMX_DEFAULT_SPARK_MODEL` rather than guessing defaults.\n</team_model_resolution>\n\n<!-- OMX:MODELS:START -->\n<!-- Auto-generated by omx setup -->\n<!-- OMX:MODELS:END -->\n\n<verification>\nVerify before claiming completion.\n<!-- OMX:GUIDANCE:VERIFYSEQ:START -->\nVerification loop: define the claim and success criteria, run the smallest validation that can prove it, read the output, then report with evidence. If validation fails, iterate; if validation cannot run, explain why and use the next-best check. Keep evidence summaries concise but sufficient.\n\n- Run dependent tasks sequentially; verify prerequisites before starting downstream actions.\n- If a task update changes only the current branch of work, apply it locally and continue without reinterpreting unrelated standing instructions.\n- For coding work, prefer targeted tests for changed behavior, then typecheck/lint/build/smoke checks when applicable; do not claim completion without fresh evidence or an explicit validation gap.\n- When correctness depends on retrieval, diagnostics, tests, or other tools, continue only until the task is grounded and verified; avoid extra loops that only improve phrasing or gather nonessential evidence.\n<!-- OMX:GUIDANCE:VERIFYSEQ:END -->\n</verification>\n\n<execution_protocols>\nMode selection: follow `<delegation_rules>` above. Switch lanes only for a concrete unresolved ambiguity, coordination need, or blocker.\n\nCommand routing: use normal Codex repository inspection tools/subagents as the default surface for simple read-only repository lookup tasks; use `omx sparkshell` only for explicit shell-native read-only evidence or bounded verification.\nWhen to use what:\n- Use normal Codex repository inspection tools/subagents for repository lookup and implementation context.\n- Use `omx sparkshell --tmux-pane` only as an explicit opt-in operator aid for shell-native tmux evidence or bounded verification; it does not replace raw evidence capture.\n\nSupervisor tmux handoff safety:\n- Never paste from tmux's implicit/current buffer. Load handoff text into a fresh named buffer with `tmux set-buffer -b <name> -- \"$message\"` or a temp-file-backed `tmux load-buffer -b <name> <file>`; never use `tmux load-buffer -- <message>`.\n- Verify the named buffer with `tmux show-buffer -b <name>` before any paste. A failed load or mismatched buffer is a blocker; do not run `paste-buffer` or submit keys after it.\n- Clear the pane composer with `tmux send-keys -t <pane> C-u` immediately before paste, then use bracketed paste (`tmux paste-buffer -t <pane> -b <name> -p -d`) and submit intentionally.\n- Recapture the pane after paste/Enter and verify the intended turn was accepted rather than leaving stale draft text visible.\n\nLeader vs worker: leaders choose mode, delegate bounded work, integrate, and own verification; workers execute their slice and escalate blockers, scope expansion, shared-file conflicts, or mode mismatch upward. Escalate from worker to leader for blockers, scope expansion, shared ownership conflicts, or mode mismatch.\n\nStop / escalate: stop when the task is verified complete, the user says stop/cancel, or no meaningful recovery path remains. Escalate to the user only for irreversible, destructive, materially branching decisions, or missing authority.\n\nOutput contract: Default update/final shape: state current mode, action/result, and evidence or blocker/next step. Keep rationale once; do not restate the full plan every turn; expand only for risk, handoff, or explicit request.\n\nAnti-slop workflow:\n- Cleanup/refactor/deslop work follows the same lightweight workflow (`understand -> execute -> verify -> report`); use `$ai-slop-cleaner` as a bounded helper inside the chosen execution lane, not as a competing top-level workflow.\n- Write a cleanup plan before modifying code; lock existing behavior with regression tests first, then make one smell-focused pass at a time.\n- Prefer deletion over addition, and prefer reuse plus boundary repair over new layers.\n- No new dependencies without explicit request.\n- Run lint, typecheck, tests, and static analysis before claiming completion.\n- Keep writer/reviewer pass separation for cleanup plans and approvals; preserve writer/reviewer pass separation explicitly.\n\nContinuation: before concluding, confirm no pending work remains, features work, tests pass or gaps are explicit, and verification evidence is collected. If not, continue.\n</execution_protocols>\n\n<cancellation>\nUse the `cancel` skill to end active execution modes when work is done and verified, when the user says stop, or when a hard blocker prevents meaningful progress. Do not cancel while recoverable work remains.\n</cancellation>\n\n<state_management>\nSee [Durable Runtime Invariants](#durable-runtime-invariants-canonical-ssot) for state ownership and hook boundaries. OMX runtime state lives under `.omx/`.\n</state_management>\n\n## Durable Runtime Invariants (canonical SSOT)\n\nThis section is the single source of truth for durable state ownership, hook boundaries, cancellation, and Team coordination. Skills and role prompts reference it; they must not restate or weaken these rules.\n\n### State and hook ownership\n\n- Durable state is authoritative only in the current, proven session or Team scope. Compatibility discovery is read-only and never grants write authority.\n- Hooks own normal skill activation and workflow-state persistence under `.omx/state/`; skills do not duplicate or mutate hook-owned state except through documented recovery paths.\n- Native hook payloads, prompt labels, task text, cwd, environment, pointers, transcripts, markers, and local trackers are routing or diagnostic data, not ownership or write authority.\n- The Team state files and `omx team api ... --json` are the source of truth for task lifecycle and mailbox coordination.\n\n### Cancellation boundary\n\n- Cancellation parses and validates arguments before mutation, resolves one exact writable scope, freezes and revalidates target identity, mutates only proven targets, and leaves unrelated sessions, legacy roots, Team artifacts, and tmux sessions untouched.\n- Ralph cancellation must satisfy its documented terminal post-conditions in the same scope; linked modes are handled only when the link is proven.\n- `--force` does not widen cancellation scope; it only removes the selected exact-session native-stop entry after the same authority checks. `--all` is unsupported.\n- Team cancellation requires exact frozen Team root, internal name, session, leader pane, and runtime identity. It fails closed when that proof is unavailable or changes; it must not enumerate or broadly kill Team sessions or recursively delete unrelated Team state.\n\n### Team protocol\n\n- Team runtime is explicit and outside the default workflow. Ultragoal does not auto-launch Team, and ordinary workflows do not silently become Team runs.\n- Workers ACK startup, claim before work, transition task status through the lifecycle API, use release only for rollback, and report verification evidence. Leaders own integration, final verification, and shutdown decisions.\n- Prefer durable state writes and `omx team api ... --json` dispatch. Direct `tmux send-keys` is fallback-only, never primary dispatch; manual pane actions require prior state/evidence checks.\n- Team shutdown waits for terminal task state and uses exact Team authority. It does not shut down active work unless explicitly aborting.\n\n### Ultragoal ownership\n\n- `.omx/ultragoal/goals.json` is the leader-owned plan and `.omx/ultragoal/ledger.jsonl` is its durable audit trail. Workers report task evidence only; they do not create worker ledgers, mutate Ultragoal artifacts, or checkpoint goals.\n- Shell commands and hooks do not mutate hidden Codex goal state. The active agent uses `get_goal`, `create_goal`, and `update_goal` only at the documented gates, then checkpoints with a fresh `get_goal` snapshot.\n\n## Setup\n\nExecute `omx setup` to install all components. Execute `omx doctor` to verify installation.\n","skills/ai-slop-cleaner/SKILL.md":"---\nname: ai-slop-cleaner\ndescription: Run an anti-slop cleanup/refactor/deslop workflow\n---\n\n# AI Slop Cleaner Task Card\n\nUse this bounded helper for cleanup/refactor/deslop work, not as a competing top-level\nworkflow. Shared operating invariants live in `templates/AGENTS.md`; this card defines\nscope, smell taxonomy, passes, and evidence.\n\n## When to use and inputs\n\nUse when working code is bloated, noisy, repetitive, over-abstracted, or AI-generated;\nthe user requests cleanup/refactor/deslop; or a follow-up left duplicate/dead code,\nweak boundaries, missing tests, fallback-like paths, or wrappers. Inputs are the requested\nfeature/files and behavior to preserve. A file list scope is valid; keep the pass bounded\nto it. Limit the pass to the calling task's changed files unless broader cleanup was requested.\n\n## Before editing\n\n1. **Lock behavior with regression tests first**: identify behavior to preserve, run/add the narrowest targeted tests, and cover both primary and preserved compatibility/fail-safe fallback paths.\n2. **Create a cleanup plan before code**: list scope and smells, include fallback findings/classifications/escalation, and order safest/highest-signal fixes first.\n3. **Inventory fallback-like code** in scope: quick hacks, temporary workaround, temporary fallback, just bypass, just skip, fallback if it fails, swallowed errors, silent defaults, broad compatibility shims, and duplicate alternate execution paths.\n4. Classify each fallback: **Masking fallback slop** hides evidence, bypasses the contract, suppresses validation, swallows failures, silently defaults, or adds untested paths; **Grounded compatibility/fail-safe fallback** is narrow at an external/version/fail-safe boundary, documents rationale, preserves failure evidence, and tests primary plus fallback.\n5. Prefer root-cause repair, deletion, boundary repair, or explicit failure behavior. For broad/ambiguous/cross-layer/architectural findings, invoke `$ralplan` for consensus resolution; when already inside ralplan, ultragoal, team, or another OMX workflow, do not spawn a nested `$ralplan`—attach the finding to the active handoff.\n\n## Smell taxonomy and passes\n\nClassify before changing:\n\n- **Fallback-like code**: masking fallbacks, workaround branches, bypasses, swallowed errors, silent defaults, broad shims, alternate paths.\n- **Duplication**: repeated logic, copy-paste branches, redundant helpers.\n- **Dead code**: unused/unreachable code, stale flags, debug leftovers.\n- **Needless abstraction**: pass-through wrappers, speculative indirection, single-use layers.\n- **Boundary violations**: hidden coupling, leaky responsibilities, wrong-layer imports/side effects.\n- **Missing tests**: behavior not locked or edge cases uncovered.\n- **UI/design slop**: context-sensitive signals, not absolute bans; preserve intentional brand, design-system, accessibility, or product-context exceptions. Challenge Korean body text at 11-12px (generally 14px or larger); gratuitous box shadows; repetitive eyebrow + title + description + paragraph stacks and generic emoji badges; default AI blue/purple such as `#3B82F6`; reflexive 3-column or 4-column grids; and extreme gradients unless justified by context.\n\nResolve the fallback-like code resolution gate first, then one smell at a time:\n**Pass 1: Dead code deletion**; **Pass 2: Duplicate removal**; **Pass 3: Naming/error\nhandling cleanup**; **Pass 4: Test reinforcement**. Re-run targeted verification after\neach pass and avoid unrelated refactors. Prefer deletion/existing utilities; no new\nabstractions or dependencies unless explicitly required.\n\n## Evidence/output contract\n\nReport:\n\n```text\nAI SLOP CLEANUP REPORT\nScope: [files/feature]\nBehavior Lock: [targeted tests added/run]\nCleanup Plan: [bounded smells/order]\nFallback Findings: [finding -> masking fallback slop | grounded compatibility/fail-safe fallback -> escalation]\nUI/Design Findings: [none/N/A or signal -> action/defer -> intentional rationale]\nPasses Completed: [resolution gate; Passes 1-4]\nQuality Gates: Regression tests, Lint, Typecheck, Tests, Static/security scan (PASS/FAIL/N/A)\nChanged Files: [path -> simplification]\nRemaining Risks: [none or deferred item]\n```\n\nInclude changed files, simplifications, fallback classifications/escalation status,\ntests/diagnostics/build checks run, UI findings when relevant, and deferred risks. Keep\nwriter/reviewer separation for cleanup plans and approvals.\n\n## Exit condition\n\nStop when the requested scope has behavior-lock evidence, each selected smell pass is\ncomplete or explicitly deferred with rationale, verification is reported, and no\nunrelated files or temporary artifacts remain. Never present an unverified cleanup as\ncomplete; escalate a real architectural blocker rather than masking it.\n","skills/analyze/SKILL.md":"---\nname: analyze\ndescription: \"Run read-only deep repository analysis and return a ranked synthesis with explicit confidence, concrete file references, and clear evidence-vs-inference boundaries. Use when a user says 'analyze', 'investigate', 'why does', 'what's causing', or needs grounded cross-file explanation before any changes are proposed.\"\n---\n\n# Analyze — Read-Only Deep Analysis\n\nUse `$analyze` to answer a repository question with grounded, read-only evidence. Explain what the code most likely says; do not turn analysis into implementation or generic fix planning.\n\nShared operating, delegation, state, hook, team, cancellation, and verification invariants live in [`templates/AGENTS.md`](../../templates/AGENTS.md). Follow that source instead of duplicating its rules here.\n\n## Use when\n\n- The user needs a causal, architectural, behavioral, impact, or tradeoff explanation.\n- The answer requires tracing multiple files or boundaries, or ranking plausible explanations.\n- The user needs confidence and concrete evidence before changing anything.\n\nDo not use it for edits, implementation, a new product plan, a simple one-file lookup, or OMX team-runtime operation.\n\n## Inputs and method\n\n1. Restate the question and define the evidence-backed scope.\n2. Identify the smallest files, tests, configs, and docs likely to answer it.\n3. Read direct code paths and contracts first; trace boundaries only as far as needed.\n4. Compare competing explanations, rank them by support, and mark unresolved points.\n5. Stop when the question is answered with sufficient evidence, or name the smallest read-only probe that would resolve the remaining uncertainty.\n\n## Evidence discipline\n\nLabel every material claim as one of:\n\n- **Evidence** — directly shown by code, tests, generated artifacts, configuration, or docs.\n- **Inference** — a reasoned conclusion drawn from cited evidence.\n- **Unknown** — not settled by the repository evidence.\n\nPrefer direct paths and independent corroboration over contextual clues. Never present guesses as evidence or inference, and never overclaim certainty.\n\n## Output contract\n\nAnswer the asked question first and use this shape:\n\n### Question\nRestated question, briefly.\n\n### Ranked synthesis\n| Rank | Explanation | Confidence | Basis |\n|------|-------------|------------|-------|\n| 1 | ... | High / Medium / Low | strongest supporting evidence |\n| 2 | ... | High / Medium / Low | why it trails |\n| 3 | ... | High / Medium / Low | why it remains possible |\n\n### Evidence\n- `path/to/file:line-line` — direct observation.\n- `path/to/file:line-line` — corroborating observation.\n\n### Inference\n- What the evidence most strongly implies.\n- Why weaker alternatives were down-ranked.\n\n### Unknowns / limits\n- What the repository does not establish.\n- The next discriminating read-only probe, when useful.\n\n## Stop conditions\n\n- Do not edit files, run an implementation lane, or make recommendations the evidence cannot support.\n- Do not continue searching after the answer and confidence boundary are grounded.\n- If evidence is insufficient, report the limit explicitly rather than manufacturing certainty.\n\nTask: {{ARGUMENTS}}\n","skills/ask/SKILL.md":"---\nname: ask\ndescription: Ask a local external advisor CLI (Claude or Gemini) and capture a reusable artifact\n---\n\n# Ask (Local Advisor CLI)\n\nUse a locally installed external advisor CLI for focused questions, reviews, brainstorming, or second opinions. This skill replaces the separate `ask-claude` and `ask-gemini` skills.\n\n## Usage\n\n```bash\n$ask claude <question or task>\n$ask gemini <question or task>\nomx ask claude \"<question or task>\"\nomx ask gemini \"<question or task>\"\n```\n\n## Backend selection\n\n- Use `claude` when the user asks for Claude, Anthropic, or the previous `$ask-claude` behavior.\n- Use `gemini` when the user asks for Gemini or the previous `$ask-gemini` behavior.\n- If no backend is specified, choose the installed backend that best matches the user request; if neither is clearly available, explain that a local CLI is required.\n\n## Local CLI commands\n\nClaude:\n\n```bash\nomx ask claude \"{{ARGUMENTS}}\"\nclaude -p \"{{ARGUMENTS}}\"\n```\n\nGemini:\n\n```bash\nomx ask gemini \"{{ARGUMENTS}}\"\ngemini -p \"{{ARGUMENTS}}\"\n```\n\nIf needed, adapt to the user's installed CLI variant while keeping local execution as the default path. Do not silently switch to an MCP or remote provider when the local binary is missing.\n\n## Artifact requirement\n\nAfter local execution, save a markdown artifact to:\n\n```text\n.omx/artifacts/ask-<backend>-<slug>-<timestamp>.md\n```\n\nMinimum artifact sections:\n1. Original user task\n2. Backend and final prompt sent to the CLI\n3. Raw CLI output\n4. Concise summary\n5. Action items / next steps\n\nTask: {{ARGUMENTS}}\n","skills/autopilot/SKILL.md":"---\nname: autopilot\ndescription: \"[OMX] Canonical autonomous orchestrator: $deep-interview -> $ralplan -> $ultragoal\"\n---\n\n# Autopilot\n\n<Purpose>\nAutopilot is the first-class canonical orchestrator for hands-off delivery. Its defining default chain is mandatory:\n\n```text\n$deep-interview -> $ralplan -> $ultragoal\n```\n\nThe chain is not a list of optional hints and Autopilot is not an alias for direct execution. Autopilot supervises each child stage in one recoverable session, carries durable artifacts forward, and continues through implementation verification until the requested outcome is complete or a genuine blocker is recorded.\n</Purpose>\n\n<Use_When>\n- The user explicitly invokes `$autopilot`.\n- The user asks for end-to-end autonomous delivery from an idea, issue, or requirements seed.\n- The work needs requirements clarification, consensus planning, durable execution, and evidence-backed completion as one supervised workflow.\n</Use_When>\n\n<Default_Chain>\nRun or resume these stages in order:\n\n1. **`deep-interview`** — clarify intent, scope, non-goals, constraints, acceptance criteria, and unresolved decisions. Produce a durable requirements/specification handoff. Deep Interview is a real stage; do not replace it with a one-question check or skip it merely because the task looks actionable.\n2. **`ralplan`** — turn the clarified requirements into an execution-ready consensus plan with architecture, sequencing, test, and verification guidance. Preserve review evidence as lifecycle evidence, not host-issued security authority.\n3. **`ultragoal`** — execute the approved plan through durable goals and ledger receipts, implementation, focused verification, cleanup, review, and terminal evidence.\n\n`$team`, `$code-review`, and `$ultraqa` may be used inside the supervised execution when the active Ultragoal plan or verification boundary requires them. They do not replace or weaken the defining three-stage chain.\n\nWhen review or QA proves the requirements or plan wrong, keep Autopilot active, return its supervised phase to `ralplan`, attach the findings, and continue through `ultragoal` again. Implementation-only review fixes may remain within Ultragoal's blocker/review loop.\n</Default_Chain>\n\n<Execution_Policy>\n- Autopilot MUST begin at `deep-interview` for a new run and MUST preserve the phase order `deep-interview -> ralplan -> ultragoal`.\n- Child stages are supervised phases, not peer workflow activations. Keep `mode:\"autopilot\"` active and update `current_phase` rather than replacing Autopilot with standalone child state.\n- Use the current CLI state SSOT (`omx state ... --json`) and the current session-scoped state root. Do not create a second writer or revive legacy root-state authority.\n- Local artifacts, prompts, trackers, transcripts, environment values, and role labels are lifecycle evidence only. Do not reintroduce the retired unrecoverable host-receipt lock or terminalize the workflow because host provenance is unavailable.\n- Authority-decreasing operations are always recoverable: `$cancel`, state clear, hook disable/uninstall recovery, and stale-state repair must remain available without completion receipts or child-stage approval.\n- Continue automatically through safe, reversible stage transitions. Stop only for an explicit user cancellation, a human-only dependency, or a verified terminal result.\n</Execution_Policy>\n\n<State_Management>\nAutopilot state is session-scoped and owned by the canonical state writer. A new run records at least:\n\n```json\n{\n \"mode\": \"autopilot\",\n \"active\": true,\n \"current_phase\": \"deep-interview\",\n \"iteration\": 1,\n \"phase_cycle\": [\"deep-interview\", \"ralplan\", \"ultragoal\"],\n \"handoff_artifacts\": {\n \"deep_interview\": null,\n \"ralplan\": null,\n \"ultragoal\": null\n },\n \"return_to_ralplan_reason\": null\n}\n```\n\nStart or update state only through the CLI-first state surface:\n\n```bash\nomx state write --input '{\"mode\":\"autopilot\",\"active\":true,\"current_phase\":\"deep-interview\",\"state\":{\"phase_cycle\":[\"deep-interview\",\"ralplan\",\"ultragoal\"],\"handoff_artifacts\":{\"deep_interview\":null,\"ralplan\":null,\"ultragoal\":null},\"return_to_ralplan_reason\":null}}' --json\n```\n\nStage transitions:\n\n- **`deep-interview -> ralplan`**: require a durable clarified requirements/specification artifact and a non-empty completion rationale. Preserve same-session question evidence when a question surface was used.\n- **`ralplan -> ultragoal`**: require durable planning artifacts, sequential Architect then Critic approvals, and a session/review-cycle-bound `ralplan_execution_handoff`. For supervised Autopilot, the explicit Autopilot request is the source of that bound handoff. Ordinary progression MUST NOT depend on a host-issued consensus receipt; missing host provenance is not a blocker.\n- **`ultragoal -> complete`**: require durable goal/ledger completion receipts and fresh verification evidence matching the requested outcome.\n- **review/QA loopback**: keep Autopilot active, set `current_phase:\"ralplan\"`, and persist `return_to_ralplan_reason` plus the findings.\n- **cancellation**: run `$cancel`; preserve handoff artifacts for inspection or resume and mark the exact session terminal without deleting unrelated state.\n- **clear/recovery**: exact-session clear may remove corrupt or stale Autopilot state. It must not require forward-progression evidence and must not clear other skills or sessions.\n</State_Management>\n\n<Continuation_And_Resume>\nWhen the user says `continue`, `resume`, or `keep going`, read the current session's `autopilot-state.json` and continue from `current_phase`:\n\n- `deep-interview`: resume clarification and produce the requirements handoff.\n- `ralplan`: resume consensus planning from the deep-interview artifact and any loopback findings.\n- `ultragoal`: resume durable execution from the approved plan and ledger.\n- `complete`: report the terminal evidence; do not restart.\n- `cancelled`, `cleared`, or `failed`: report preserved artifacts and start a new run only on a new explicit Autopilot request.\n\nNever discard valid handoff artifacts or restart discovery merely because the conversation resumed.\n</Continuation_And_Resume>\n\n<Recovery_Contract>\nAutopilot continuation hooks may nudge an active non-terminal run, but they MUST fail open for recovery:\n\n- A stale, malformed, cancelled, cleared, complete, or foreign-session state must not keep Stop blocked.\n- `$cancel`, exact-session state clear, and setup hook disable/uninstall paths must remain executable while Autopilot is active or damaged.\n- Continuation must be bounded and session-scoped; never recreate an unconditional hook lock.\n</Recovery_Contract>\n\n<Final_Checklist>\n- [ ] A new run started with `deep-interview`.\n- [ ] Deep Interview produced a durable clarified requirements/specification handoff.\n- [ ] Ralplan produced an execution-ready plan with lifecycle review evidence.\n- [ ] Ultragoal completed the plan with durable goals and ledger receipts.\n- [ ] Verification evidence covers the requested behavior, failure paths, and recovery paths.\n- [ ] Missing host provenance did not block ordinary progression, cancel, clear, or hook recovery.\n- [ ] Autopilot state is terminal and exact-session artifacts remain coherent.\n</Final_Checklist>\n\n<Examples>\n<Good>\nUser: `$autopilot implement issue #42`\nFlow: activate Autopilot at `deep-interview`, crystallize requirements, continue to supervised `ralplan`, then supervised `ultragoal`, verify the completed outcome, and mark the exact session complete.\n</Good>\n\n<Good>\nUser: `continue`\nContext: Autopilot state has `current_phase:\"ralplan\"`.\nFlow: resume the existing plan from the deep-interview handoff; do not create a separate standalone Ralplan run.\n</Good>\n\n<Bad>\nFlow: treat `$deep-interview`, `$ralplan`, and `$ultragoal` as optional suggestions and jump directly to implementation.\nWhy bad: this hollows out Autopilot's defining orchestration contract.\n</Bad>\n</Examples>\n\nTask: {{ARGUMENTS}}\n","skills/autoresearch-goal/SKILL.md":"---\nname: autoresearch-goal\ndescription: Sunset stub — use $autoresearch instead\n---\n\n# Autoresearch-goal — removed\n\n`$autoresearch-goal` was removed in OMX 0.21; use `$autoresearch` instead.\n\nAutoresearch-goal was a duplicate research-over-goal-mode entry point. `$autoresearch` is the single canonical validator-gated research loop; it owns the research mission lifecycle that autoresearch-goal duplicated.\n\nMigration: replace `$autoresearch-goal` with `$autoresearch`.\n\nTask: {{ARGUMENTS}}\n","skills/autoresearch/SKILL.md":"---\nname: autoresearch\ndescription: Stateful validator-gated research loop with native-hook persistence\n---\n\n# Autoresearch\n\nAutoresearch is the skill-first replacement for the deprecated `omx autoresearch` command.\nIt keeps the useful measured-research loop, but it now runs as a native-hook stateful workflow instead of a direct CLI or tmux launch surface.\n\n## Boundary with planning research\n\nUse `$autoresearch` when the research output itself is a bounded deliverable that must pass an explicit validator. Do not recommend it for ordinary pre-planning docs lookup or general best-practice checks; use `$best-practice-research` for that. If `$autoresearch` is intentionally run before architecture planning, its approved artifact should feed evidence into `$ralplan`; it should not become a final architecture/component unless the user explicitly asks for ongoing research automation.\n\n## Use when\n- You want a Ralph-ish persistent research loop\n- The task should keep nudging until explicit validation evidence exists\n- You want init-time choice between script validation and prompt+architect validation\n\n## Do not use when\n- You want the old `omx autoresearch` command surface (hard-deprecated)\n- You want detached tmux or split-pane launch parity\n- You have not decided the validation regime yet\n\n## Core contract\n1. **Init chooses validation mode.** Pick exactly one:\n - `mission-validator-script`\n - `prompt-architect-artifact`\n2. **Persist mode state** in `.omx/state/.../autoresearch-state.json` including:\n - `validation_mode`\n - `completion_artifact_path`\n - `mission_validator_command` **or** `validator_prompt`\n - optional `output_artifact_path`\n3. **Completion is artifact-gated.** The loop does not stop because the model says “done”, because a stop hook fired once, or because several turns were no-ops.\n4. **Direct CLI launch is gone.** Use `$deep-interview --autoresearch` for intake and `$autoresearch` for execution.\n\n## Completion artifact contract\n\n### `mission-validator-script`\nThe completion artifact must exist and record a passing validator result, for example:\n\n```json\n{\n \"status\": \"passed\",\n \"passed\": true,\n \"summary\": \"metric improved beyond baseline\"\n}\n```\n\n### `prompt-architect-artifact`\nThe completion artifact must include both an architect approval verdict and an output artifact path, for example:\n\n```json\n{\n \"validator_prompt\": \"Review the research output against the mission.\",\n \"architect_review\": { \"verdict\": \"approved\" },\n \"output_artifact_path\": \".omx/specs/autoresearch-demo/report.md\"\n}\n```\n\n## Recommended flow\n1. Run `$deep-interview --autoresearch` to clarify mission + evaluator.\n2. Materialize `.omx/specs/autoresearch-{slug}/mission.md`, `sandbox.md`, and `result.json`.\n3. Start `$autoresearch` with the chosen validation mode stored in mode state.\n4. Let stop-hook / auto-nudge continue until the completion artifact satisfies the chosen validation mode.\n5. Finish only after the validator artifact is complete.\n\n## Migration note\n- `omx autoresearch` is hard-deprecated.\n- No direct CLI launch.\n- No tmux split-pane launch.\n- No noop-count completion gate.\n","skills/best-practice-research/SKILL.md":"---\nname: best-practice-research\ndescription: \"[OMX] Bounded best-practice research wrapper using official/upstream evidence first\"\nargument-hint: \"<technology|decision|practice question>\"\n---\n\n# Best-Practice Research\n\nUse this skill when a task depends on current external best practices, version-aware guidance, standards, official recommendations, or upstream behavior. This is a workflow wrapper: it routes evidence gathering and synthesis; it is not a new research authority and it does not replace `researcher`.\n\n## Purpose\n\nProduce a cited, reusable best-practice answer or handoff that separates current external evidence from repo-local facts and dependency-selection decisions. For pre-planning investigation, this is the ordinary first research wrapper: gather official/upstream evidence, then hand it to `$ralplan` or the caller as planning input. Do not present `$best-practice-research` as a final architecture component or as a validator-gated research loop.\n\n## Terminal By Default\n\nThis skill is terminal and read-only by default. It gathers evidence and produces a cited recommendation with a handoff, then stops. Do not write or edit files, create or amend commits, run mutating commands, or otherwise modify repository state under this skill — even when the question has clear implementation implications. When implementation is warranted, stop and hand off rather than continuing: name `$ralplan` for planning and `$ultragoal`, `$team`, or `executor` for execution, and resume only after the user explicitly switches to that workflow.\n\n## Activate When\n\n- The user asks for best practices, recommended approach, current guidance, official recommendations, standards, or version-aware external behavior.\n- `$ralplan`, `$deep-interview`, `$team`, or another workflow needs current external evidence before planning or execution can be correct.\n- The task involves an already chosen technology and needs authoritative usage guidance, migration notes, API behavior, lifecycle rules, or current safety guidance.\n\n## Do Not Activate When\n\n- The answer is fully repo-local; use `explore` for codebase facts.\n- The main question is whether to adopt, replace, upgrade, or compare dependencies; use `dependency-expert`.\n- The user only needs implementation against already-grounded requirements; execute directly, or use `$team` when coordinated parallel work is warranted.\n- The task can be answered from stable local project conventions without current external lookup.\n\n## Specialist Routing\n\n1. Use `explore` first for brownfield facts: current code usage, local constraints, versions, config, and integration points.\n2. Use `researcher` for official/upstream docs, release notes, standards, migration guides, source-backed examples, and current best-practice evidence for an already chosen technology.\n3. Use `dependency-expert` only for adoption/upgrade/replacement/comparison decisions.\n4. Return to the caller with explicit evidence, uncertainty, and any implementation handoff constraints.\n\n## Source-Quality Rules\n\n- Prefer official documentation, upstream source, release notes, changelogs, standards, and maintainer guidance.\n- Include source URLs for material claims.\n- State date/version context for current best-practice claims.\n- Label third-party summaries as supplemental; do not use them before official/upstream sources.\n- Flag stale, conflicting, undocumented, or version-mismatched evidence.\n- Do not over-fetch: gather the smallest evidence set that can support the decision.\n\n## Workflow\n\n1. Classify the question: conceptual best practice, implementation guidance, migration/version guidance, standards/compliance guidance, or mixed local + external guidance.\n2. Gather repo-local facts with `explore` when local usage or constraints affect the answer.\n3. Gather external evidence with `researcher` when current or version-aware practice affects correctness.\n4. Synthesize a concise answer with source quality, version/date context, caveats, and an implementation or planning handoff.\n5. Stop when the answer is grounded enough for the caller; otherwise report the exact blocker or specialist handoff needed.\n\n## Output Contract\n\n```md\n## Best-Practice Research: <question>\n\n### Direct Recommendation\n<actionable guidance or decision support>\n\n### Evidence Used\n- Official/upstream: <source URL> — <what it establishes>\n- Supplemental, if any: <source URL> — <why it is secondary>\n\n### Version / Date Context\n<versions, dates, release channels, or unknowns>\n\n### Repo-Local Context\n<facts from explore, or \"not needed\">\n\n### Boundaries / Non-goals\n<what this research does not decide>\n\n### Handoff\n<planning/execution/test implications; name the next workflow — `$ralplan` for planning, `$ultragoal`/`$team`/`executor` for execution — and note that this skill stops here unless the user explicitly switches workflows>\n```\n\n## Stop Rules\n\n- Stop after a source-backed recommendation is reusable by the caller.\n- Stop and route upward if the task becomes dependency comparison, broad architecture, or implementation.\n- Do not continue researching when remaining work would only polish wording rather than change the recommendation.\n- This skill never implements. After delivering the recommendation and handoff, stop; do not modify repo files or repo state. Resume only when the user explicitly switches to a planning or implementation workflow named in the handoff.\n\nTask: {{ARGUMENTS}}\n","skills/cancel/SKILL.md":"---\nname: cancel\ndescription: Cancel any active OMX mode (autopilot, ralph, ultrawork, ecomode, ultraqa, swarm, ultrapilot, pipeline, team)\n---\n\n# Cancel Skill\n\n## When to use\n\nUse `/cancel` (or `cancelomc` / `stopomc`) to stop an active OMX mode and perform its documented cleanup. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot` first; it is the invariant authority for scope, ownership, hooks, and Team cleanup.\n\n## Inputs and preconditions\n\n- Accepted forms are `/cancel` and `/cancel --force`.\n- Reject `--all`, unknown flags, repeated flags, and mixed flags before mutation.\n- Discover the current session/root with the state read surfaces before cleanup:\n ```bash\n omx state list-active --json\n omx state get-status --mode <mode> --json\n ```\n- Confirm the current session/root and exact target before cleanup; stop when the required evidence is missing.\n\n## Operational steps\n\n1. Parse and validate arguments; select one exact session/root scope.\n2. Inspect active modes in dependency order:\n `autopilot → ralph → ultrawork → ecomode → ultraqa → swarm → ultrapilot → pipeline → team → plan-consensus`.\n3. Cancel Autopilot while preserving its resumable state; clean only linked child modes it owns.\n4. For Ralph, terminalize the target state (`active:false`, `current_phase:\"cancelled\"`, `completed_at`) and terminalize a proven linked Ultrawork/Ecomode state in the same scope. Confirm the post-conditions in `docs/contracts/ralph-cancel-contract.md`.\n5. Clear standalone modes only after proving they are not linked to another active mode.\n6. For Team, inspect the runtime with `omx team status <team> --json`; use `omx team shutdown <team>` after the normal completion gate, or follow the explicit abort path.\n7. Clear only the selected mode/session state through the state API, for example:\n ```bash\n omx state clear --input '{\"mode\":\"<mode>\",\"session_id\":\"<session>\"}' --json\n ```\n8. With `--force`, perform its documented native-stop cleanup. Report rollback or cleanup failures rather than claiming success.\n\n## Exit and evidence\n\nReport one result per selected mode: mode, scope/session, terminal phase, preserved state, linked cleanup, and any refusal reason. A clean no-op reports `No active OMX modes detected.` Include Team status and shutdown evidence when Team was selected.\n","skills/code-review/SKILL.md":"---\nname: code-review\ndescription: Run a comprehensive code review\n---\n\n# Code Review Task Card\n\nUse this explicit opt-in for a merge-readiness review. Shared operating invariants\nlive in `templates/AGENTS.md`; this card only defines review-specific behavior.\n\n## When to use\n\n- The user asks for a code review or quality/security assessment.\n- A change is ready for review before merge, or a major feature needs an independent review.\n- Do not activate this card for implementation, broad planning, or automatic cleanup.\n\n## Inputs\n\n- Scope: the requested files, commit, PR, or whole diff.\n- Requirements/specification, acceptance criteria, and relevant test/CI evidence.\n- Existing review artifacts and known risks, if any.\n- If the user says `continue`, advance the current verified review step rather than restarting discovery.\n\nStart by recording the scope:\n\n```sh\ngit status --short\ngit diff --stat\ngit diff -- <scope>\n```\n\n## Execution\n\n1. Identify changed files and review boundaries; do not silently widen the scope.\n2. Launch the `code-reviewer` and `architect` agents in parallel. Both lanes run in parallel on a clean context with explicit scope and artifacts. If either lane cannot be launched or does not return evidence, report `independent review unavailable`; do **not** substitute the current/authoring lane, and do **not** approve or mark the review merge-ready.\n3. Respect the user's current model and reasoning/effort selection. Do not pass `model` or `reasoning_effort` overrides in review-lane calls.\n\n```text\ntask(\n agent_type=\"code-reviewer\",\n prompt=\"CODE REVIEW TASK\n\nReview the supplied scope for spec compliance, security, quality, performance, and maintainability.\nReturn files reviewed, severity-rated findings with file:line evidence and concrete fixes,\nand a recommendation: APPROVE / REQUEST CHANGES / COMMENT. Do not review architecture.\nScope: [scope and artifacts]\"\n)\n\ntask(\n agent_type=\"architect\",\n prompt=\"ARCHITECTURE / DEVIL'S-ADVOCATE REVIEW TASK\n\nReview the same scope for boundaries, interfaces, hidden coupling, long-term tradeoffs,\nand the strongest counterargument against approval. Return file:line evidence,\nrecommendations, and Architectural Status: CLEAR / WATCH / BLOCK.\nScope: [scope and artifacts]\"\n)\n```\n\n## Review taxonomy\n\n- `code-reviewer` checks **Security**, **Code Quality**, **Performance**, **Best Practices**, and **Maintainability**.\n- Rate each finding: **CRITICAL** (security or data-loss blocker), **HIGH** (bug/major smell), **MEDIUM** (important improvement), or **LOW** (style/suggestion).\n- `architect` checks explicit boundaries/interfaces, hidden coupling, long-horizon tradeoffs, and devil's-advocate concerns. Status is **CLEAR**, **WATCH** (non-blocking concern), or **BLOCK** (merge blocker).\n- Every finding names `file:line`, issue, risk, and a concrete fix; distinguish facts from suggestions.\n\n## State/HUD Phase Contract\n\n- Standalone `$code-review` relies on hook-owned `skill-active-state.json` (`skill:\"code-review\"`, `phase:\"planning\"`); do not create `code-review-state.json`.\n- Inside Autopilot, keep `mode:\"autopilot\"` active with `current_phase:\"code-review\"` / skill-active `phase:\"code-review\"`; do not activate a peer workflow.\n- On clean review, persist the artifact under Autopilot `handoff_artifacts.code_review` before moving to `ultraqa`. On non-clean review, persist findings and use `rework` or `ralplan` as appropriate.\n\n```sh\nomx state write --input '{\"mode\":\"autopilot\",\"active\":true,\"current_phase\":\"code-review\"}' --json\n```\n\n## Final Synthesis and gate\n\n### Architectural Status Contract\n\nCombine the `code-reviewer` recommendation and architect status. Approval requires explicit evidence from both independent lanes; missing or failed delegation is a blocking unavailable-review state, not an approval fallback. The final report must make architect blockers impossible to miss.\n\n- If architect status is **BLOCK**, final recommendation is **REQUEST CHANGES**.\n- Else if `code-reviewer` recommendation is **REQUEST CHANGES**, final recommendation is **REQUEST CHANGES**.\n- Else if architect status is **WATCH**, final recommendation is **COMMENT**.\n- Else final recommendation follows the `code-reviewer` lane.\n\nApproval criteria: **APPROVE** only when `code-reviewer` returns APPROVE, architect status is `CLEAR`, and both independent lanes returned evidence. **REQUEST CHANGES** for a blocker, unresolved high/critical finding, or unavailable lane. **COMMENT** may record non-blocking findings.\n\nDo not self-review as a fallback. If the `code-reviewer` or `architect` path is missing, unavailable, skipped, or fails, block approval until independent lane evidence exists. On the supported `omx ralph` CLI compatibility path, findings may trigger automatic fix follow-up without another permission prompt; plain `code-review` itself remains read-only and does **not** promise auto-fix.\n\n## Evidence/output contract\n\nReturn a concise report containing:\n\n```text\nCODE REVIEW REPORT\nFiles Reviewed: <count>\nTotal Issues: 0\nArchitectural Status: CLEAR | WATCH | BLOCK\nCRITICAL (0) | HIGH (0) | MEDIUM (0) | LOW (0)\nFindings: file:line -> issue, risk, concrete fix (or none)\nARCHITECTURE WATCHLIST: concern, status, recommendation (or none)\n- code-reviewer recommendation: COMMENT\n- architect status: WATCH\n- final recommendation: COMMENT\nRECOMMENDATION: COMMENT\n```\n\nReplace the illustrative counts and verdict with observed values. Include scope,\nlane evidence/artifact references, unresolved risks, and validation gaps.\n\n## Exit condition\n\nStop when the scoped diff has two independent lane results and a deterministic final\nrecommendation. Report `APPROVE` only under the approval criteria; otherwise leave a\nbounded `REQUEST CHANGES`, `COMMENT`, or unavailable-review result. Never claim\nmerge-ready without the required evidence.\n","skills/configure-notifications/SKILL.md":"---\nname: configure-notifications\ndescription: Configure OMX notifications - unified entry point for all platforms\ntriggers:\n - \"configure notifications\"\n - \"setup notifications\"\n - \"notification settings\"\n - \"configure discord\"\n - \"configure telegram\"\n - \"configure slack\"\n - \"configure openclaw\"\n - \"setup discord\"\n - \"setup telegram\"\n - \"setup slack\"\n - \"setup openclaw\"\n - \"discord notifications\"\n - \"telegram notifications\"\n - \"slack notifications\"\n - \"openclaw notifications\"\n - \"discord webhook\"\n - \"telegram bot\"\n - \"slack webhook\"\n---\n\n# Configure OMX Notifications\n\nUse this card for Discord, Telegram, Slack, generic command aliases, or OpenClaw. Shared safety, lifecycle, hook, team, autonomy, and cancellation rules live in `templates/AGENTS.md`.\n\n## 1. Inspect and choose a path\n\n```bash\nCONFIG_FILE=\"$HOME/.codex/.omx-config.json\"\nif [ -f \"$CONFIG_FILE\" ]; then\n jq -r '{notifications_enabled:(.notifications.enabled // false), discord:(.notifications.discord.enabled // false), discord_bot:(.notifications[\"discord-bot\"].enabled // false), telegram:(.notifications.telegram.enabled // false), slack:(.notifications.slack.enabled // false), openclaw:(.notifications.openclaw.enabled // false), custom_webhook_command:(.notifications.custom_webhook_command.enabled // false), custom_cli_command:(.notifications.custom_cli_command.enabled // false), verbosity:(.notifications.verbosity // \"session\"), idleCooldownSeconds:(.notifications.idleCooldownSeconds // 60), reply_enabled:(.notifications.reply.enabled // false)}' \"$CONFIG_FILE\"\nelse\n echo \"NO_CONFIG_FILE\"\nfi\n```\n\nUse AskUserQuestion to choose: Discord native (webhook or bot), Telegram native (bot token + chat id), Slack native (incoming webhook), `custom_webhook_command`, `custom_cli_command`, cross-cutting settings, or disable all notifications.\n\n## 2. Native providers\n\nCollect and validate provider values, then write only these native keys: `notifications.discord`, `notifications[\"discord-bot\"]`, `notifications.telegram`, or `notifications.slack`. Do not represent native providers with generic aliases.\n\n## 3. Generic aliases\n\nFor `custom_webhook_command`, collect URL, optional headers, method (`POST` default or `PUT`), events (`session-end`, `ask-user-question`, `session-start`, `session-idle`, `stop`), and an instruction template:\n\n```bash\njq --arg url \"$URL\" --arg method \"${METHOD:-POST}\" --arg instruction \"${INSTRUCTION:-OMX event {{event}} for {{projectPath}}}\" --argjson headers \"${HEADERS_JSON:-{}}\" '.notifications=(.notifications//{enabled:true})|.notifications.enabled=true|.notifications.custom_webhook_command={enabled:true,url:$url,headers:$headers,method:$method,instruction:$instruction,events:[\"session-end\",\"ask-user-question\"]}' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\nFor `custom_cli_command`, collect a command template (`{{event}}`, `{{instruction}}`, `{{sessionId}}`, `{{projectPath}}`), optional events, and an instruction template:\n\n```bash\njq --arg command \"$COMMAND_TEMPLATE\" --arg instruction \"${INSTRUCTION:-OMX event {{event}} for {{projectPath}}}\" '.notifications=(.notifications//{enabled:true})|.notifications.enabled=true|.notifications.custom_cli_command={enabled:true,command:$command,instruction:$instruction,events:[\"session-end\",\"ask-user-question\"]}' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\nOpenClaw dispatch requires `OMX_OPENCLAW=1`; command gateways additionally require `OMX_OPENCLAW_COMMAND=1`; timeout precedence is `gateways.<name>.timeout` > `OMX_OPENCLAW_COMMAND_TIMEOUT_MS` > `5000` ms.\n\n## 4. OpenClaw + Clawdbot agent mode\n\nUse this only when the requested route is a `clawdbot agent` turn delivered to Discord. The `session-stop` notification intentionally maps to the OpenClaw `stop` hook. OMX shell-escapes substitutions; keep instructions short, avoid untrusted shell metacharacters, append `|| true`, and append JSONL logs with `>>`.\n\n```bash\njq --arg command \"(clawdbot agent --session-id omx-hooks --message {{instruction}} --thinking minimal --deliver --reply-channel discord --reply-to 'channel:CHANNEL_ID' --timeout 120 --json >>/tmp/omx-openclaw-agent.jsonl 2>&1 || true)\" '.notifications=(.notifications//{enabled:true})|.notifications.enabled=true|.notifications.verbosity=\"verbose\"|.notifications.openclaw={enabled:true,gateways:{local:{type:\"command\",command:$command,timeout:120000}},hooks:{\"session-start\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-start project={{projectName}} session={{sessionId}} tmux={{tmuxSession}}. 한국어로 상태를 #omc-dev에 공유하고 SOUL.md를 참고하세요.\"},\"session-idle\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-idle session={{sessionId}} tmux={{tmuxSession}}. 한국어로 팔로업을 #omc-dev에 안내하세요.\"},\"ask-user-question\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=ask-user-question session={{sessionId}} tmux={{tmuxSession}} question={{question}}. 한국어로 응답 필요를 #omc-dev에 알리세요.\"},\"stop\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-stop session={{sessionId}} tmux={{tmuxSession}}. 한국어로 중단 상태를 전달하세요.\"},\"session-end\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-end session={{sessionId}} tmux={{tmuxSession}} reason={{reason}}. 한국어로 완료 요약을 #omc-dev에 남기세요.\"}}}' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\n### Compatibility + precedence contract\n\nExplicit `notifications.openclaw` wins when valid; generic aliases are ignored with a warning.\n\nVerify this mode and inspect evidence without hiding output:\n\n```bash\nclawdbot agent --session-id omx-hooks --message \"OMX hook test via clawdbot agent path\" --thinking minimal --deliver --reply-channel discord --reply-to 'channel:CHANNEL_ID' --timeout 120 --json\ntmux list-sessions -F '#{session_name}' | rg '^omx-' || true\njq '.notifications.openclaw.hooks' \"$CONFIG_FILE\"\ntail -n 120 /tmp/omx-openclaw-agent.jsonl | jq -s '.[] | {timestamp:(.timestamp // .time),status:(.status // .error // \"ok\")}'\nrg '\"error\"|\"failed\"|\"timeout\"' /tmp/omx-openclaw-agent.jsonl | tail -20\n```\n\nFor HTTP integrations, run both a `/hooks/wake` smoke test and `/hooks/agent` delivery verification.\n\n## 5. Cross-cutting settings and disable\n\n- Verbosity: `minimal`, `session` (recommended), `agent`, or `verbose`.\n- Idle cooldown: `notifications.idleCooldownSeconds` (environment override: `OMX_IDLE_COOLDOWN_SECONDS`).\n- Profiles: `notifications.profiles` and `notifications.defaultProfile`.\n- Reply listener: `notifications.reply.enabled`; gates are `OMX_REPLY_ENABLED=true` and, for Discord, `OMX_REPLY_DISCORD_USER_IDS=...`. An authorized Discord bot operator may exact-match `status` on a tracked notification for a bounded read-only session summary.\n\nDisable all notifications:\n\n```bash\njq '.notifications.enabled=false' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\n## Exit evidence\n\nRun `jq empty \"$CONFIG_FILE\"` after edits. Report the config path, enabled native providers, enabled aliases, whether valid `notifications.openclaw` overrides aliases, verbosity, idle cooldown, reply-listener state, and smoke-test results. Stop when the JSON parses and the selected path has its required evidence; do not claim delivery from configuration alone.\n","skills/deep-interview/SKILL.md":"---\nname: deep-interview\ndescription: Socratic deep interview with mathematical ambiguity gating before execution\nargument-hint: \"[--quick|--standard|--deep] [--autoresearch] <idea or vague description>\"\n---\n\n<Purpose>\nDeep Interview is an intent-first Socratic clarification loop before planning or implementation. It turns vague ideas into execution-ready specifications by asking targeted questions about why the user wants a change, how far it should go, what should stay out of scope, and what OMX may decide without confirmation.\n</Purpose>\n\n<Use_When>\n- The request is broad, ambiguous, or missing concrete acceptance criteria\n- The user says \"deep interview\", \"interview me\", \"ask me everything\", \"don't assume\", or \"ouroboros\"\n- The user wants to avoid misaligned implementation from underspecified requirements\n- You need a requirements artifact before handing off to `ralplan`, `autopilot`, `ultragoal`, or `team`\n</Use_When>\n\n<Do_Not_Use_When>\n- The request already has concrete file/symbol targets and clear acceptance criteria\n- The user explicitly asks to skip planning/interview and execute immediately\n- The user asks for lightweight brainstorming only (use `plan` instead)\n- A complete PRD/plan already exists and execution should start\n</Do_Not_Use_When>\n\n<Why_This_Exists>\nExecution quality is usually bottlenecked by intent clarity, not just missing implementation detail. A single expansion pass often misses why the user wants a change, where the scope should stop, which tradeoffs are unacceptable, and which decisions still require user approval. This workflow applies Socratic pressure + quantitative ambiguity scoring so orchestration modes begin with an explicit, testable, intent-aligned spec.\n</Why_This_Exists>\n\n<Depth_Profiles>\n- **Quick (`--quick`)**: fast pre-PRD pass; target threshold `<= 0.30`; max rounds 5\n- **Standard (`--standard`, default)**: full requirement interview; target threshold `<= 0.20`; max rounds 12\n- **Deep (`--deep`)**: high-rigor exploration; target threshold `<= 0.15`; max rounds 20\n- **Autoresearch (`--autoresearch`)**: same interview rigor as Standard, but specialized for `$autoresearch` mission readiness and `.omx/specs/` artifact handoff\n\nProfile `max rounds` is a hard cap, not a target. Do not continue only to reach a numbered round count. Extra Socratic rigor does not override the active threshold unless the profile/config changes.\n\nIf no flag is provided, use **Standard**.\n\n<Mode_Flags>\n- **`--autoresearch`**: switch the interview into autoresearch-intake mode for `$autoresearch` handoff. In this mode, the interview should converge on a validator-ready research mission, write canonical artifacts under `.omx/specs/`, and preserve the explicit `refine further` vs `launch` boundary for downstream skill intake.\n</Mode_Flags>\n</Depth_Profiles>\n\n<Execution_Policy>\n- Ask ONE question per round (never batch multiple interview rounds into one `questions[]` form)\n- Ask about intent and boundaries before implementation detail\n- Target the weakest clarity dimension each round after applying the stage-priority rules below\n- Treat every answer as a claim to pressure-test before moving on: the next question should usually demand evidence or examples, expose a hidden assumption, force a tradeoff or boundary, or reframe root cause vs symptom\n- Do not rotate to a new clarity dimension just for coverage when the current answer is still vague; stay on the same thread until one layer deeper, one assumption clearer, or one boundary tighter\n- Before crystallizing, complete at least one explicit pressure pass that revisits an earlier answer with a deeper, assumption-focused, or tradeoff-focused follow-up\n- Gather codebase facts via `explore` before asking user about internals\n- `omx explore` is deprecated. Use normal repository inspection tools/subagents for simple read-only brownfield fact gathering; use `omx sparkshell` only for explicit shell-native read-only evidence, and keep ambiguous or non-shell-only investigation on the richer normal path.\n- Always run a preflight context intake before the first interview question\n- For brownfield work, preflight must include doc/context grounding before user-facing questions: inspect applicable `AGENTS.md` files, README/getting-started docs, relevant `docs/` contracts/plans/ADRs, existing `.omx/context/` snapshots, and any project-local glossary/context files such as `CONTEXT.md` or `CONTEXT-MAP.md` when present.\n- Treat existing repo language as evidence, not authority: if the user uses a fuzzy, overloaded, or conflicting term, surface the specific doc/code wording and ask which meaning should govern before implementation.\n- Cross-check user claims about current behavior against code or documented contracts when discoverable. If docs and code disagree, ask a confirmation question that names both sources instead of silently choosing one.\n- Use scenario-based edge-case grilling when relationships, boundaries, or handoff behavior are unclear: invent one concrete scenario that stresses the ambiguous boundary, then ask one focused question about the expected outcome.\n- Durable docs, glossary, ADR, or memory updates are opt-in and public-safe only. Deep-interview may recommend such updates in the handoff summary, but must not automatically create or dump public docs from interview transcripts unless the user explicitly chooses that as in-scope.\n- If initial context is oversized or would exceed the prompt budget, do not paste or forward the raw payload into interview prompts; request and record a prompt-safe initial-context summary first\n- The oversized initial-context summary gate is blocking: wait for the concise summary before ambiguity scoring, crystallizing artifacts, or any downstream execution handoff\n- The summary must preserve goals, constraints, success criteria, non-goals, decision boundaries, and references to any full source documents so downstream consumers receive a prompt-safe but faithful context\n- Keep total prompt payloads within a safe budget by summarizing or trimming retained history; preserve newest/highest-signal answers and never let raw oversized context crowd out the current question\n- Reduce user effort: ask only the highest-leverage unresolved question, and never ask the user for codebase facts that can be discovered directly\n- For brownfield work, prefer evidence-backed confirmation questions such as \"I found X in Y. Should this change follow that pattern?\"\n- Route facts before judgment in the Ouroboros style: before presenting a user-facing interview round, classify whether the needed information is a discoverable fact, a fact needing confirmation, or a human decision. The interview is with the human for judgment, not for facts the agent can inspect.\n- When unresolved ambiguity depends on current external best practices, official/upstream guidance, standards, or version-aware behavior, use `$best-practice-research` as the bounded evidence wrapper before crystallizing requirements or handing off to planning/execution.\n- Use these transcript/spec labels only; never use them as `omx question` `source` values, and never replace the runtime `source: \"deep-interview\"` contract for user-facing deep-interview questions:\n - `[from-code][auto-confirmed]` — exact, high-confidence codebase facts from manifests/configs or direct source evidence, with no prescription attached.\n - `[from-code]` — codebase findings that are useful but inferred, pattern-based, or low/medium confidence and therefore need a confirmation-style user-facing round before being treated as settled.\n - `[from-research]` — externally sourced facts such as API limits, compatibility, or public documentation; facts only, not decisions.\n - `[from-user]` — goals, preferences, business logic, scope, non-goals, acceptance criteria, tradeoffs, and any decision-bearing interpretation.\n- Treat `[from-code][auto-confirmed]` and other non-user fact discoveries as context/transcript updates, not interview rounds: do not call `omx question`, do not create a pending deep-interview question obligation, and do not increment the user-facing round number for facts the agent can safely establish.\n- Auto-confirm only descriptive facts. If a finding implies what the new feature should do, which pattern it should follow, which tradeoff to accept, or what should stay in/out of scope, route the entire decision-bearing question to the user as `[from-user]` even when code or research facts are available.\n- In attached-tmux Codex CLI, deep-interview uses `omx question` as the required OMX-owned structured questioning path for every interview round\n- When invoking `omx question` through attached-tmux Bash/tool paths, preserve the leader-pane return target by prefixing the command with `OMX_QUESTION_RETURN_PANE=$TMUX_PANE` (or a concrete `%pane` value)\n- If you launch `omx question` in a background terminal, immediately wait for that background terminal to finish and read its JSON answer before scoring ambiguity, asking another round, or handing off\n- Treat `answers[]` as the primary `omx question` success contract. For a single interview round, read `answers[0].answer`; use legacy top-level `answer` only as a compatibility fallback when needed.\n- If the current runtime is outside tmux and cannot render `omx question`, use the native structured question tool when available; otherwise ask exactly one concise plain-text question and wait for the answer\n- Re-score ambiguity after each answer and show progress transparently\n- Once ambiguity is at or below the active profile threshold, stop ordinary questioning. Run the practical closure audit: crystallize/handoff when readiness gates pass; otherwise ask only the final closure question needed to satisfy a named gate.\n- Treat `max_rounds` as a stop cap, not evidence that more rounds are needed.\n- Do not hand off to execution while ambiguity remains above threshold unless user explicitly opts to proceed with warning\n- Do not crystallize or hand off while `Non-goals` or `Decision Boundaries` remain unresolved, even if the weighted ambiguity threshold is met\n- Treat early exit as a safety valve, not the default success path\n- Persist mode state for resume safety only through the CLI/programmatic single-writer authority (`omx state write/read --input '<json>' --json`, backed by `src/state/operations.ts`). The MCP state server is a read-only projection and must never become a second writer.\n</Execution_Policy>\n\n<Steps>\n\n## Phase 0: Preflight Context Intake\n\n1. Parse `{{ARGUMENTS}}` and derive a short task slug.\n2. Attempt to load the latest relevant context snapshot from `.omx/context/{slug}-*.md`.\n3. Check whether the provided initial context or loaded snapshot is too large for safe prompt use. If it is oversized, the first interview round must ask for a concise prompt-safe summary instead of scoring ambiguity or continuing to downstream handoff.\n4. If no snapshot exists, create a minimum context snapshot with:\n - Task statement\n - Desired outcome\n - Stated solution (what the user asked for)\n - Probable intent hypothesis (why they likely want it)\n - Known facts/evidence\n - Constraints\n - Unknowns/open questions\n - Decision-boundary unknowns\n - Likely codebase touchpoints\n - Relevant repo docs/rules/context inspected\n - Terminology or doc/code conflicts found\n - Prompt-safe initial-context summary status (`not_needed`, `needed`, or `recorded`)\n5. For brownfield tasks, inspect the applicable documentation/rule surface before the first user-facing round. Prefer exact, nearby sources over broad scans:\n - governing `AGENTS.md` files and template/runtime instruction surfaces that apply to the touched paths\n - README/getting-started docs and relevant docs under `docs/`, especially contracts, plans, ADR-like records, and workflow docs\n - existing `.omx/context/` snapshots, `.omx/specs/`, and planning artifacts relevant to the slug\n - project-local glossary/context files such as `CONTEXT.md`, `CONTEXT-MAP.md`, or context-specific docs when they exist\n6. Save snapshot to `.omx/context/{slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`) and reference it in mode state.\n\n## Phase 1: Initialize\n\n1. Parse `{{ARGUMENTS}}` and depth profile (`--quick|--standard|--deep`).\n2. Detect project context:\n - Run `explore` to classify **brownfield** (existing codebase target) vs **greenfield**.\n - For brownfield, collect relevant codebase context before questioning.\n3. Initialize state via `omx state write --input '{\"mode\":\"deep-interview\",\"active\":true}' --json`:\n\n```json\n{\n \"active\": true,\n \"current_phase\": \"deep-interview\",\n \"state\": {\n \"interview_id\": \"<uuid>\",\n \"profile\": \"quick|standard|deep\",\n \"type\": \"greenfield|brownfield\",\n \"initial_idea\": \"<user input>\",\n \"rounds\": [],\n \"current_ambiguity\": 1.0,\n \"threshold\": 0.3,\n \"max_rounds\": 5,\n \"challenge_modes_used\": [],\n \"codebase_context\": null,\n \"current_stage\": \"intent-first\",\n \"current_focus\": \"intent\",\n \"context_snapshot_path\": \".omx/context/<slug>-<timestamp>.md\"\n }\n}\n```\n\n4. Announce kickoff with profile, threshold, and current ambiguity.\n\n## Phase 2: Socratic Interview Loop\n\nRepeat until ambiguity `<= threshold`, the pressure pass is complete, the readiness gates are explicit, the user exits with warning, or max rounds are reached. This is a stop condition: below threshold, do not open a new ordinary interview branch.\n\n### 2a) Generate next question\nIf the initial context is oversized and no prompt-safe summary has been recorded yet, the next question must be only a summary request. Do not score ambiguity, do not run readiness gates, and do not hand off to `$ultragoal`, `$ralplan`, `$autopilot`, or `$team` until that summary answer is captured.\n\nUse:\n- Original idea\n- Prior Q&A rounds\n- Current dimension scores\n- Brownfield context (if any)\n- Doc/context grounding notes, including existing terminology, governing rules, and any doc/code mismatch\n- Activated challenge mode injection (Phase 3)\n\nTarget the lowest-scoring dimension, but respect stage priority:\n- **Stage 1 — Intent-first:** Intent, Outcome, Scope, Non-goals, Decision Boundaries\n- **Stage 2 — Feasibility:** Constraints, Success Criteria\n- **Stage 3 — Brownfield grounding:** Context Clarity (brownfield only)\n\nFollow-up pressure ladder after each answer:\n1. Ask for a concrete example, counterexample, or evidence signal behind the latest claim\n2. Probe the hidden assumption, dependency, or belief that makes the claim true\n3. Force a boundary or tradeoff: what would you explicitly not do, defer, or reject?\n4. Challenge fuzzy or conflicting terms against the repo's documented language and current code behavior\n5. Stress-test the boundary with one concrete scenario or edge case when a relationship or handoff remains ambiguous\n6. If the answer still describes symptoms, reframe toward essence / root cause before moving on\n\nPrefer staying on the same thread for multiple rounds when it has the highest leverage. Breadth without pressure is not progress.\n\nMaintain a **Breadth Ledger** across independent ambiguity tracks: scope, constraints, outputs, verification, brownfield integration, and any user-mentioned deliverable tracks. The ledger is a guard, not a mandatory rotation rule: stay deep on the current thread until it has been pressure-tested, then zoom out only when another material track remains unresolved and would change execution.\n\nMaintain a **Docs/Terminology Ledger** for brownfield interviews:\n- repo docs/rules/context sources inspected, with path references\n- canonical terms already used by the repo and terms to avoid or disambiguate\n- user terms that conflict with docs or current code behavior\n- doc/code mismatches that require a human decision before implementation\n- optional durable-doc follow-ups that are safe to propose but not auto-apply\n\nDetailed dimensions:\n- Intent Clarity — why the user wants this\n- Outcome Clarity — what end state they want\n- Scope Clarity — how far the change should go\n- Constraint Clarity — technical or business limits that must hold\n- Success Criteria Clarity — how completion will be judged\n- Context Clarity — existing codebase understanding (brownfield only)\n\n`Non-goals` and `Decision Boundaries` are mandatory readiness gates. Ask about them early and keep revisiting them until they are explicit.\n\n### 2b) Ask the question\nUse the surface-appropriate structured questioning path for every interview round. In attached-tmux sessions, use OMX-owned structured questioning via `omx question` (this is the required structured-question equivalent and required `AskUserQuestion` equivalent for deep-interview). Outside tmux, use native structured input when available; otherwise ask exactly one concise plain-text question and wait for the answer. Present:\n\n```\nRound {n} | Target: {weakest_dimension} | Ambiguity: {score}%\n\n{question}\n```\n\n`omx question` payload guidance for interview rounds:\n- Deep-interview is Socratic: ask one focused round at a time. Do not use batch `questions[]` to combine multiple interview rounds, even though `omx question` supports batch forms for other workflows.\n- Use canonical `type` values instead of authoring raw `multi_select` flags by hand. `type: \"single-answerable\"` is the default for one-path decisions; `type: \"multi-answerable\"` is the canonical shape for bounded multi-select rounds. The runtime will keep `multi_select` aligned with `type`.\n- Use `single-answerable` when exactly one answer should drive the next branch, the options are mutually exclusive, or selecting more than one answer would blur the decision boundary. Typical cases: handoff lane selection, choosing the primary failure mode, or confirming which of several competing interpretations is correct.\n- Use `multi-answerable` when multiple options may all be true at once and you need to capture a bounded set of coexisting constraints, non-goals, risks, or acceptance checks in one round. Typical cases: selecting all out-of-scope items, all success metrics that must hold, or all deployment constraints that apply together.\n- If one selected option would immediately require a follow-up question to disambiguate the others, prefer a `single-answerable` round now and ask the follow-up next. Do not hide a branching interview tree inside one overloaded multi-select prompt.\n- Keep interview options bounded and concrete. If the valid answers are already known, set `allow_other: false`; only leave `allow_other: true` when the interview genuinely needs one user-supplied option that cannot be enumerated in advance.\n- Read answers structurally from the primary `answers[]` array. For a normal single-round interview response, use `answers[0].answer` as the source of truth; the top-level `answer` field is a legacy single-question projection/fallback only.\n- For `single-answerable`, expect one decisive selection in the `value` field of `answers[0].answer` plus its selected-values metadata. For `multi-answerable`, treat the selected-values field inside `answers[0].answer` as the source of truth for all chosen constraints/non-goals and preserve the full set in the transcript/spec. In legacy single-question projections, this is equivalent to: For `multi-answerable`, treat `answer.selected_values` as the source of truth.\n\nCanonical bounded single-choice payload:\n\n```json\n{\n \"question\": \"Which execution lane should own this once the interview is complete?\",\n \"type\": \"single-answerable\",\n \"options\": [\n {\n \"label\": \"Plan first\",\n \"value\": \"ralplan\",\n \"description\": \"Need architecture and test-shape review before execution\"\n },\n {\n \"label\": \"Execute directly\",\n \"value\": \"autopilot\",\n \"description\": \"Requirements are already explicit enough for planning plus execution\"\n },\n {\n \"label\": \"Refine further\",\n \"value\": \"refine\",\n \"description\": \"Clarification is still needed before any handoff\"\n }\n ],\n \"allow_other\": false,\n \"other_label\": \"Other\",\n \"source\": \"deep-interview\"\n}\n```\n\nCanonical bounded multi-select payload:\n\n```json\n{\n \"question\": \"Which non-goals must stay out of scope for the first pass?\",\n \"type\": \"multi-answerable\",\n \"options\": [\n {\n \"label\": \"No UI redesign\",\n \"value\": \"no-ui-redesign\",\n \"description\": \"Keep layout and styling unchanged\"\n },\n {\n \"label\": \"No new dependencies\",\n \"value\": \"no-new-dependencies\",\n \"description\": \"Work within the existing toolchain\"\n },\n {\n \"label\": \"No API contract changes\",\n \"value\": \"no-api-contract-changes\",\n \"description\": \"Preserve external request and response shapes\"\n }\n ],\n \"allow_other\": false,\n \"other_label\": \"Other\",\n \"source\": \"deep-interview\"\n}\n```\n\nCanonical answer-shape reminders:\n\n```json\n{\n \"answer\": {\n \"kind\": \"option\",\n \"value\": \"ralplan\",\n \"selected_labels\": [\"Plan first\"],\n \"selected_values\": [\"ralplan\"]\n }\n}\n```\n\n```json\n{\n \"answer\": {\n \"kind\": \"multi\",\n \"value\": [\"no-new-dependencies\", \"no-api-contract-changes\"],\n \"selected_labels\": [\"No new dependencies\", \"No API contract changes\"],\n \"selected_values\": [\"no-new-dependencies\", \"no-api-contract-changes\"]\n }\n}\n```\n\n### 2c) Score ambiguity\nScore each weighted dimension in `[0.0, 1.0]` with justification + gap.\n\nGreenfield: `ambiguity = 1 - (intent × 0.30 + outcome × 0.25 + scope × 0.20 + constraints × 0.15 + success × 0.10)`\n\nBrownfield: `ambiguity = 1 - (intent × 0.25 + outcome × 0.20 + scope × 0.20 + constraints × 0.15 + success × 0.10 + context × 0.10)`\n\nReadiness gate:\n- `Non-goals` must be explicit\n- `Decision Boundaries` must be explicit\n- A pressure pass must be complete: at least one earlier answer has been revisited with an evidence, assumption, or tradeoff follow-up\n- A practical closure audit must pass: another question would change execution materially, not merely polish wording or chase a narrow edge case\n- If either gate is unresolved, or the pressure pass is incomplete, continue below threshold only with a final closure question that names the unresolved gate and would materially change execution.\n- Treat a low ambiguity score as permission to audit closure, not permission to keep drilling indefinitely. If remaining uncertainty would not change implementation, crystallize the spec instead of opening a new branch.\n- If ambiguity is `<= 0.10`, another user-facing question is allowed only as that final closure question; otherwise crystallize immediately.\n\n### 2d) Report progress\nShow weighted breakdown table, readiness-gate status (`Non-goals`, `Decision Boundaries`), and the next focus dimension.\n\n### 2e) Persist state\nAppend round result and updated scores via `omx state write --input '<json>' --json`. Do not write `{mode}-state.json` directly and do not use the read-only MCP state projection as a writer.\n\n### 2f) Round controls\n- Do not offer early exit before the first explicit assumption probe and one persistent follow-up have happened\n- Apply a **Dialectic Rhythm Guard**: track consecutive non-user fact discoveries and confirmation-style answers (`[from-code][auto-confirmed]`, `[from-code]`, or `[from-research]`). After 3 consecutive non-user or confirmation answers, the next material user-facing round must solicit direct human judgment (`[from-user]`) unless the closure audit says the interview is ready to crystallize.\n- Round 4+: allow explicit early exit with risk warning\n- Soft warning at profile midpoint (e.g., round 3/6/10 depending on profile)\n- Hard cap at profile `max_rounds`; never treat this cap as a desired interview length or quota\n\n## Phase 3: Challenge Modes (assumption stress tests)\n\nUse each mode once when applicable. These are normal escalation tools, not rare rescue moves:\n\n- **Contrarian** (round 2+ or immediately when an answer rests on an untested assumption): challenge core assumptions\n- **Terminologist** (brownfield, whenever a key term is fuzzy, overloaded, or conflicts with repo docs/code): force a canonical meaning against existing project language before implementation\n- **Simplifier** (round 4+ or when scope expands faster than outcome clarity): probe minimal viable scope\n- **Ontologist** (round 5+ and ambiguity > 0.25, or when the user keeps describing symptoms): ask for essence-level reframing\n\nTrack used modes in state to prevent repetition.\n\n## Phase 4: Crystallize Artifacts\n\nWhen threshold is met (or user exits with warning / hard cap):\n\n1. Write interview transcript summary to:\n - `.omx/interviews/{slug}-{timestamp}.md`\n (kept for ralph PRD compatibility)\n2. Write execution-ready spec to:\n - `.omx/specs/deep-interview-{slug}.md`\n\nSpec should include:\n- Metadata (profile, rounds, final ambiguity, threshold, context type)\n- Context snapshot reference/path (for ralplan/team reuse)\n- Prompt-safe initial-context summary when oversized context was provided, plus references to any full source documents\n- Clarity breakdown table\n- Intent (why the user wants this)\n- Desired Outcome\n- In-Scope\n- Out-of-Scope / Non-goals\n- Decision Boundaries (what OMX may decide without confirmation)\n- Constraints\n- Testable acceptance criteria\n- Assumptions exposed + resolutions\n- Pressure-pass findings (which answer was revisited, and what changed)\n- Brownfield evidence vs inference notes for any repository-grounded confirmation questions\n- Docs/Terminology Ledger with inspected repo docs/rules/context, term conflicts, and any doc/code mismatch decisions\n- Scenario/edge-case pressure findings that materially shaped scope or acceptance criteria\n- Optional durable documentation recommendations, explicitly marked opt-in and public-safe; do not include raw private transcript dumps\n- Technical context findings\n- Full or condensed transcript\n\n### Autoresearch specialization\n\nWhen the clarified task is specifically about `$autoresearch`, or the skill is invoked with `--autoresearch`, keep the interview domain-specific and emit skill-consumable artifacts without skipping clarification.\n\n- **Accepted seed inputs:** `topic`, `evaluator`, `keep-policy`, `slug`, existing mission draft text, and prior evaluator examples/templates\n- **Required interview focus:** mission clarity, evaluator readiness, keep policy, slug/session naming, and whether the draft is ready to launch now or should refine further\n- **Canonical artifact path:** `.omx/specs/deep-interview-autoresearch-{slug}.md`\n- **Launch artifact bundle:** `.omx/specs/autoresearch-{slug}/mission.md`, `.omx/specs/autoresearch-{slug}/sandbox.md`, and `.omx/specs/autoresearch-{slug}/result.json`\n- **Launch artifact directory:** `.omx/specs/autoresearch-{slug}/`\n- **Required artifact sections:**\n - `Mission Draft`\n - `Evaluator Draft`\n - `Launch Readiness`\n - `Seed Inputs`\n - `Confirmation Bridge`\n- **Required launch artifacts under `.omx/specs/autoresearch-{slug}/`:**\n - `mission.md`\n - `sandbox.md`\n - `result.json`\n- **Launch-readiness rule:** mark the draft as **not launch-ready** while the evaluator command still contains placeholder markers such as `<...>`, `TODO`, `TBD`, `REPLACE_ME`, `CHANGEME`, or `your-command-here`\n- **Structured result contract:** `result.json` should point to the draft + mission/sandbox artifacts and carry the finalized `topic`, `evaluatorCommand`, `keepPolicy`, `slug`, `launchReady`, and `blockedReasons` fields so `$autoresearch` can consume it directly\n- **Confirmation bridge:** after artifact generation, offer at least `refine further` and `launch`; do not run direct CLI launch or detached/split tmux launch, and only hand off to `$autoresearch` after explicit confirmation\n- **Handoff rule:** downstream execution must preserve the clarified mission intent, evaluator expectations, decision boundaries, and launch-readiness status from this artifact rather than bypassing the draft review step\n\n## Phase 5: Execution Bridge\n\nPresent execution options after artifact generation using explicit handoff contracts. Treat the deep-interview spec as the current requirements source of truth and preserve intent, non-goals, decision boundaries, acceptance criteria, docs/terminology grounding, and any residual-risk warnings across the handoff.\n\n### Optional execution contract foundation\n\nWhen an Autopilot/deep-interview handoff explicitly requires a stride contract, emit it as structured data rather than prose. This is a validation foundation, not a broadness-inference feature: do not infer stride from task length, phase labels, snapshots, or freeform wording.\n\nCanonical location under Autopilot state:\n\n```json\n{\n \"handoff_artifacts\": {\n \"deep_interview\": {\n \"execution_contract_required\": true,\n \"execution_contract\": {\n \"version\": 1,\n \"execution_stride\": \"task\",\n \"source\": \"deep-interview\",\n \"selected_by\": \"user\",\n \"allow_task_shrink\": true,\n \"completion_unit\": \"One focused task\",\n \"stop_condition\": \"Stop after that task is implemented and verified\",\n \"acceptance_coverage_scope\": \"task\",\n \"shrink_policy\": \"allowed\"\n }\n }\n }\n}\n```\n\nStride meanings:\n- `task`: conservative, small-step execution; `allow_task_shrink:true`, `acceptance_coverage_scope:\"task\"`, `shrink_policy:\"allowed\"`.\n- `deliverable`: finish the named deliverable before stopping; `allow_task_shrink:false`, `acceptance_coverage_scope:\"deliverable\"`, `shrink_policy:\"ask_before_shrink\"`.\n- `milestone`: finish the larger approved milestone unless blocked; `allow_task_shrink:false`, `acceptance_coverage_scope:\"milestone\"`, `shrink_policy:\"deny_unless_blocked\"`.\n\nOnly set `execution_contract_required:true` when the selected downstream workflow needs this explicit stride/stop-condition guard. New artifacts must write the canonical snake_case schema shown above under `handoff_artifacts.deep_interview`; runtime readers may accept legacy camelCase field/marker aliases and direct/nested `execution_contract` locations only as compatibility input. If `execution_contract_required` is absent or false, downstream Autopilot compatibility behavior is unchanged.\n\n### Goal-mode follow-ups\n\nInclude these product-facing suggestions when they fit the clarified spec, without removing the existing `$ultragoal`, `$ralplan`, `$autopilot`, and `$team` handoff options:\n\n- **`$ultragoal`** — default goal-mode follow-up for implementation or general goal-oriented follow-up specs that should be converted into durable Codex/OMX goals with sequential completion tracking.\n- **`$autoresearch`** — use when the clarified context is a research project: a research question, reference/literature gathering, evaluator-backed analysis, or professor/critic-style deliverable.\n- **`$performance-goal`** — use when the clarified context is an optimization or performance project with measurable speed, latency, throughput, memory, benchmark, or evaluator criteria.\n\nRecommend `$ultragoal` as the default durable goal-mode follow-up because it supersedes Ralph for goal tracking. Preserve `$team` for coordinated parallel implementation.\n\n### 1. **`$ultragoal` (Default durable execution follow-up)**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md` (optionally accompanied by the transcript/context snapshot for traceability)\n- **Invocation:** `$ultragoal create-goals --brief-file <spec-path>` followed by `$ultragoal complete-goals` in the active execution lane\n- **Consumer Behavior:** Convert the clarified spec into durable goal-mode work. Preserve intent, non-goals, decision boundaries, acceptance criteria, docs/terminology grounding, scenario-pressure findings, and residual-risk warnings as binding story constraints.\n- **Skipped / Already-Satisfied Stages:** Requirement interview, ambiguity clarification, doc/context preflight, and early intent-boundary elicitation\n- **Expected Output:** `.omx/ultragoal/brief.md`, `.omx/ultragoal/goals.json`, `.omx/ultragoal/ledger.jsonl`, implementation evidence, verification evidence, and final cleanup/review-gate evidence\n- **Best When:** The clarified spec is execution-ready or the user explicitly wants durable goal tracking as the next step\n- **Next Recommended Step:** Run the Ultragoal completion loop; launch `$team` only inside an active Ultragoal story when parallel lanes are warranted\n\n### 2. **`$ralplan` (Recommended when architecture/test-shape review is still needed)**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md` (optionally accompanied by the transcript/context snapshot for traceability)\n- **Invocation:** `$ralplan <spec-path>`\n- **Consumer Behavior:** Treat the deep-interview spec as the requirements source of truth. Do not repeat the interview by default; refine architecture/feasibility around the clarified intent and boundaries instead.\n- **Skipped / Already-Satisfied Stages:** Requirements discovery, ambiguity clarification, and early intent-boundary elicitation\n- **Expected Output:** Canonical planning artifacts under `.omx/plans/`, especially `prd-*.md` and `test-spec-*.md`\n- **Best When:** Requirements are clear enough to stop interviewing, but architectural validation / consensus planning is still desirable\n- **Next Recommended Step:** Use the approved planning artifacts with `$ultragoal` as the default durable goal-mode follow-up (optionally with `$team` for parallel lanes); choose `$autoresearch` for research validation or `$performance-goal` for measurable optimization\n\n### 3. **`$autopilot`**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md`\n- **Invocation:** `$autopilot <spec-path>`\n- **Consumer Behavior:** Use the deep-interview spec as the clarified execution brief. Preserve intent, non-goals, decision boundaries, and acceptance criteria as binding context for planning/execution.\n- **Skipped / Already-Satisfied Stages:** Initial requirement discovery and ambiguity reduction\n- **Expected Output:** Planning/execution progress, QA evidence, and validation artifacts produced by autopilot\n- **Best When:** The clarified spec is already strong enough for direct planning + execution without an additional consensus gate\n- **Next Recommended Step:** Continue through autopilot's execution/QA/validation flow; if coordination-heavy execution emerges, prefer `$team` under a leader-owned `$ultragoal` ledger\n\n### 4. **`$team`**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md`\n- **Invocation:** `$team <spec-path>`\n- **Consumer Behavior:** Treat the spec as shared execution context for coordinated parallel work. Preserve the clarified intent, non-goals, decision boundaries, and acceptance criteria as common lane constraints.\n- **Skipped / Already-Satisfied Stages:** Requirement clarification and early ambiguity reduction\n- **Expected Output:** Coordinated multi-agent execution against the shared spec, with final verification evidence and checkpoints in an already-active Ultragoal ledger when applicable\n- **Best When:** The task is large, multi-lane, or blocker-sensitive enough to justify coordinated parallel execution instead of a single persistent loop\n- **Next Recommended Step:** Follow the team verification path when the coordinated execution phase finishes; checkpoint an already-active `$ultragoal` ledger when applicable. Do not start another execution loop solely to verify.\n\n### 5. **Refine further**\n- **Input Artifact:** Existing transcript, context snapshot, and current spec draft\n- **Invocation:** Continue the interview loop\n- **Consumer Behavior:** Re-enter questioning to resolve the highest-leverage remaining uncertainty\n- **Skipped / Already-Satisfied Stages:** None beyond already-captured context\n- **Expected Output:** A lower-ambiguity spec with tighter boundaries and fewer unresolved assumptions\n- **Best When:** Residual ambiguity is still too high, the user wants stronger clarity, or the above-threshold / early-exit warning indicates too much risk to proceed cleanly\n- **Next Recommended Step:** Return to one of the execution handoff contracts above once the spec is sufficiently clarified\n\n**Residual-Risk Rule:** If the interview ended via early exit, hard-cap completion, or above-threshold proceed-with-warning, explicitly preserve that residual-risk state in the handoff so the downstream skill knows it inherited a partially clarified brief.\n\n**IMPORTANT:** Deep-interview is a requirements mode. On handoff, invoke the selected skill using the contract above. **Do NOT implement directly** inside deep-interview.\n\n</Steps>\n\n<Tool_Usage>\n- Use `explore` for codebase fact gathering\n- Use `omx question` as the OMX-native structured user-input tool for each interview round when an attached tmux renderer is available\n- From attached-tmux Bash/tool paths, call it as `OMX_QUESTION_RETURN_PANE=$TMUX_PANE omx question ...` unless an explicit `%pane` return target is already known\n- If the current runtime is outside tmux and cannot render `omx question`, use native structured input when available; otherwise ask exactly one concise plain-text question and wait for the answer\n- After `omx question` returns JSON, prefer `answers[0].answer` / `answers[]`; use legacy `answer` only as a fallback for older records\n- Use `omx state write/read --input '<json>' --json` for resumable mode state through the sole-writer state operations path; the MCP state server is read-only and is not a fallback writer\n- If the interview cannot ask a required `omx question` round, persist the blocker as terminal state with `active: false` and `current_phase: \"blocked\"`; do not write a terminal blocked phase with `active: true`\n- Read/write context snapshots under `.omx/context/`\n- Read applicable repo docs/rules/context during preflight; write durable docs, glossary, ADR, or memory updates only when the user explicitly opts in and the content is public-safe\n- Record whether the oversized-context summary gate is not needed, pending, or satisfied before any scoring or handoff step\n- Save transcript/spec artifacts under `.omx/interviews/` and `.omx/specs/`\n</Tool_Usage>\n\n<Escalation_And_Stop_Conditions>\n- User says stop/cancel/abort -> persist state and stop\n- Ambiguity stalls for 3 rounds (+/- 0.05) -> force Ontologist mode once\n- Max rounds reached -> proceed with explicit residual-risk warning\n- All dimensions >= 0.9 -> allow early crystallization even before max rounds\n</Escalation_And_Stop_Conditions>\n\n<Final_Checklist>\n- [ ] Preflight context snapshot exists under `.omx/context/{slug}-{timestamp}.md`\n- [ ] Oversized initial context, if present, has a prompt-safe summary recorded before ambiguity scoring or downstream handoff\n- [ ] Ambiguity score shown each round\n- [ ] Intent-first stage priority used before implementation detail\n- [ ] Weakest-dimension targeting used within the active stage\n- [ ] At least one explicit assumption probe happened before crystallization\n- [ ] At least one persistent follow-up / pressure pass deepened a prior answer\n- [ ] Challenge modes triggered at thresholds (when applicable)\n- [ ] Transcript written to `.omx/interviews/{slug}-{timestamp}.md`\n- [ ] Spec written to `.omx/specs/deep-interview-{slug}.md`\n- [ ] Brownfield questions use evidence-backed confirmation when applicable\n- [ ] Brownfield preflight inspected applicable repo docs/rules/context before user-facing questions\n- [ ] Fuzzy or conflicting terminology was challenged against repo language/current code behavior when applicable\n- [ ] Scenario-based edge-case grilling was used when boundary ambiguity would materially affect implementation\n- [ ] Durable docs/ADR/memory updates, if any, were explicitly opted into and public-safe\n- [ ] Handoff options provided (`$ultragoal`, `$ralplan`, `$autopilot`, `$team`) plus context-sensitive goal-mode suggestions (`$autoresearch`, `$performance-goal`) when applicable\n- [ ] No direct implementation performed in this mode\n</Final_Checklist>\n\n<Advanced>\n## Suggested Config (optional)\n\nDeep-interview reads runtime defaults from the first existing config source in this order:\n\n1. Repository-local `.omx/config.toml`\n2. Repository-root `omx.toml`\n3. User-global `~/.omx/config.toml`\n\nThis section is currently a deep-interview-specific runtime override surface, not a general replacement for Codex `config.toml` or `.omx-config.json` model/env routing.\nMalformed config files are ignored fail-soft so `$deep-interview` activation can continue with built-in defaults.\nExplicit `--quick`, `--standard`, or `--deep` invocation flags override `defaultProfile`.\n\n```toml\n[omx.deepInterview]\ndefaultProfile = \"standard\"\nquickThreshold = 0.30\nstandardThreshold = 0.20\ndeepThreshold = 0.15\nquickMaxRounds = 5\nstandardMaxRounds = 12\ndeepMaxRounds = 20\nenableChallengeModes = true\n```\n\n## Resume\n\nIf interrupted, rerun `$deep-interview`. Resume from persisted mode state via `omx state read --input '{\"mode\":\"deep-interview\"}' --json`.\n\n## Canonical Autopilot Entry Pipeline\n\n```\nautopilot -> deep-interview -> ralplan -> ultragoal\n```\n\n- Autopilot begins with this independent deep-interview clarity gate; it must not substitute `$plan --interview`.\n- Stage 1 (deep-interview): ambiguity clearance and execution-ready requirements artifact\n- Stage 2 (ralplan): feasibility, architecture, and consensus gate\n- Stage 3 (ultragoal): durable execution, verification, and completion receipts\n</Advanced>\n","skills/design/SKILL.md":"---\nname: design\ndescription: Canonical repo-local DESIGN.md workflow for product, UI/UX, and frontend decision source of truth\n---\n\n# Design Skill\n\nUse `$design` to discover product and UI evidence, close only design-critical context gaps, and create or refresh the repository’s durable `DESIGN.md` contract. It is a maintained design brief, not a pixel-matching loop or one-off critique.\n\nShared operating, delegation, state, hook, team, cancellation, and verification invariants live in [`templates/AGENTS.md`](../../templates/AGENTS.md). Follow that source instead of duplicating its rules here.\n\n## Use when\n\n- Product, UX, frontend, or design-system decisions need a repo-local source of truth.\n- A feature needs a design brief before a designer lane or implementation.\n- Existing UI, assets, screenshots, or constraints need an actionable design summary.\n\nDo not use it for visual-reference implementation matching (use `$visual-ralph`), screenshot comparison alone, or backend/infrastructure work without user-facing design impact.\n\n## Relationship to `$visual-ralph`\n\n`$design` owns product goals, users, information architecture, visual language, components, accessibility, constraints, and open questions in `DESIGN.md`. `$visual-ralph` owns implementation against an approved visual reference or live-URL baseline, measured verdicts, and pixel-diff evidence. Run `$design` first when both are needed; `DESIGN.md` supports but does not replace the visual verdict target.\n\n## Workflow\n\n### 1. Discover local evidence\n\nInspect and cite existing `DESIGN.md`, design/UX/frontend docs, README/specs/issues, routes/pages/layouts/components/stories, theme and token files, assets, screenshots/mockups, Storybook or Playwright baselines, and accessibility/responsive/i18n/platform constraints. Separate observations from inferences; note absent evidence.\n\n### 2. Interview only missing context\n\nAsk concise questions only for gaps the repository cannot resolve: users/jobs, goals/non-goals, brand personality and forbidden aesthetics, primary flows, accessibility/device/browser targets, or unavailable assets/references. If answers are unavailable, record explicit assumptions and open questions rather than blocking.\n\n### 3. Create or refresh `DESIGN.md`\n\nPreserve useful content, remove contradictions, mark unknowns, and keep decisions actionable. The root file must contain these sections:\n\n# Design\n## Source of truth\nStatus (Draft | Active | Needs refresh), date, product surfaces, evidence reviewed.\n## Brand\nPersonality, trust signals, avoid.\n## Product goals\nGoals, non-goals, success signals.\n## Personas and jobs\nPrimary personas, user jobs, contexts of use.\n## Information architecture\nNavigation, routes/screens, content hierarchy.\n## Design principles\nPrinciples and tradeoffs.\n## Visual language\nColor, typography, spacing, shape/elevation, motion, imagery/iconography.\n## Components\nExisting/new components, variants/states, token ownership.\n## Accessibility\nTarget standard, keyboard/focus, contrast, semantics, reduced motion/sensory concerns.\n## Responsive behavior\nBreakpoints/devices, layout adaptations, touch/hover differences.\n## Interaction states\nLoading, empty, error, success, disabled, offline/slow network where applicable.\n## Content voice\nTone, terminology, microcopy rules.\n## Implementation constraints\nFramework/styling, tokens, performance, compatibility, test/screenshot expectations.\n## Open questions\n`[ ]` question, owner, and impact.\n\n### 4. Apply the contract\n\nBefore UI decisions, cite relevant `DESIGN.md` sections, reuse documented components/tokens, and update the file or add an open question when implementation exposes a contradiction. Do not invent a parallel design-system layer.\n\n### 5. Handoff\n\nFor normal frontend work, provide the relevant sections, repo evidence, and acceptance criteria. For visual-reference, image, or live-URL matching, hand off to `$visual-ralph` with the approved baseline and identify `DESIGN.md` as supporting context only.\n\n## Evidence and completion\n\nComplete only when design docs/assets/components/screenshots were inspected or noted absent; missing context is answered, assumed, or listed; root `DESIGN.md` contains every required section; recommendations cite it; and any Visual Ralph handoff is clearly separated from design governance.\n\nTask: {{ARGUMENTS}}\n","skills/doctor/SKILL.md":"---\nname: doctor\ndescription: Diagnose and fix oh-my-codex installation issues\n---\n\n# OMX Doctor\n\nUse this task card to diagnose installation/discovery problems. Shared safety, lifecycle, hook, team, autonomy, and cancellation rules live in `templates/AGENTS.md`. `~/.codex` means `${CODEX_HOME:-~/.codex}` when `CODEX_HOME` is set.\n\n## Run diagnostics\n\n```bash\nomx doctor\nomx doctor --team # include Team runtime checks\nomx doctor --verbose # include detailed check evidence\nomx doctor --force # repair eligible repo artifact ownership issues\nomx doctor --dry-run --force # preview eligible ownership repairs\n```\n\nFor a local source checkout, build first and invoke `node dist/cli/omx.js doctor`. Keep command output and exact paths for the report.\n\n### Plugin cache and version\n\n```bash\nPLUGIN_CACHE_ROOT=\"${CODEX_HOME:-$HOME/.codex}/plugins/cache\"\nCACHE_ENTRIES=$(find \"$PLUGIN_CACHE_ROOT\" -path \"*/oh-my-codex/*\" -mindepth 3 -maxdepth 3 -type d 2>/dev/null)\nif [[ -z \"$CACHE_ENTRIES\" ]]; then\n echo \"Installed plugin cache: none\"\nelse\n while IFS= read -r d; do\n m=$(basename \"$(dirname \"$(dirname \"$d\")\")\"); v=$(basename \"$d\")\n printf 'Installed plugin cache: marketplace=%s version=%s path=%s\\n' \"$m\" \"$v\" \"$d\"\n done <<<\"$CACHE_ENTRIES\"\nfi\nLATEST=$(npm view oh-my-codex version 2>/dev/null)\necho \"Latest npm: $LATEST\"\n```\n\nNo cache is INFO (normal for npm/setup-only installs). A non-`local` cache version differing from `LATEST`, or multiple versions for one marketplace, is WARN. Plugin discovery does not replace npm installation plus `omx setup`; native/runtime wiring remains setup-owned.\n\n### Hooks, AGENTS, and skill roots\n\n```bash\nCODEX_DIR=\"${CODEX_HOME:-$HOME/.codex}\"\nls -la \"$CODEX_DIR/config.toml\" \"$CODEX_DIR/settings.json\" 2>/dev/null\nrg 'keyword-detector|persistent-mode|session-start|stop-continuation' \"$CODEX_DIR/config.toml\" \"$CODEX_DIR/settings.json\" 2>/dev/null || true\nls -la \"$CODEX_DIR/hooks\"/*.sh 2>/dev/null\nls -la \"$CODEX_DIR/AGENTS.md\" 2>/dev/null\ngrep -q \"oh-my-codex Multi-Agent System\" \"$CODEX_DIR/AGENTS.md\" 2>/dev/null && echo \"Has OMX config\" || echo \"Missing OMX config\"\nls -la \"$CODEX_DIR/agents\" \"$CODEX_DIR/commands\" \"$CODEX_DIR/skills\" \"$HOME/.agents/skills\" 2>/dev/null\n```\n\nClassify legacy hook references as **CRITICAL** (duplicate hooks). The scripts `keyword-detector.sh`, `persistent-mode.sh`, `session-start.sh`, and `stop-continuation.sh` are **WARN**. Missing AGENTS.md is **CRITICAL**; missing the OMX marker is **WARN**. `${CODEX_HOME:-~/.codex}/skills` is the canonical user root. `~/.agents/skills` is historical and overlapping trees can duplicate skill entries. OMX files under legacy `agents/` or `commands/` are **WARN**.\n\nWith `--team`, retain any `resume_blocker`, `slow_shutdown`, `delayed_status_lag`, `stale_leader`, or `orphan_tmux_session` diagnostics; failed checks set a non-zero exit status.\n\n## Report contract\n\n```text\n## OMX Doctor Report\n### Summary\n[HEALTHY / ISSUES FOUND]\n### Checks\n| Check | Status | Details |\n| Plugin Version | OK/WARN/INFO | ... |\n| Hook Config (config.toml / legacy settings.json) | OK/CRITICAL | ... |\n| Legacy Scripts (~/.codex/hooks/) | OK/WARN | ... |\n| AGENTS.md | OK/WARN/CRITICAL | ... |\n| Plugin Cache | OK/WARN | ... |\n| Legacy Agents / Commands | OK/WARN | ... |\n| Skills (canonical / historical root) | OK/WARN | ... |\n### Issues Found\n1. ...\n### Recommended Fixes\n...\n```\n\n## Remediation (after user confirmation and confirming each target is OMX-owned)\n\nRemove only confirmed OMX legacy content; preserve unrelated user files:\n\n```bash\n# If settings.json exists, remove only its legacy \"hooks\" section.\nrm -f \"$CODEX_DIR/hooks/keyword-detector.sh\" \"$CODEX_DIR/hooks/persistent-mode.sh\" \"$CODEX_DIR/hooks/session-start.sh\" \"$CODEX_DIR/hooks/stop-continuation.sh\"\nPLUGIN_CACHE_ROOT=\"${CODEX_HOME:-$HOME/.codex}/plugins/cache\"\nfind \"$PLUGIN_CACHE_ROOT\" -path \"*/oh-my-codex\" -type d -prune -exec rm -rf {} +\n```\n\nFor older curl installs, inspect first and remove only directories containing OMX-managed files:\n\n```bash\nls -la \"$CODEX_DIR/agents\" \"$CODEX_DIR/commands\" \"$CODEX_DIR/skills\" \"$HOME/.agents/skills\" 2>/dev/null\n# Optional backups:\n# mv \"$CODEX_DIR/agents\" \"$CODEX_DIR/agents.bak\"\n# mv \"$CODEX_DIR/commands\" \"$CODEX_DIR/commands.bak\"\n# mv \"$HOME/.agents/skills\" \"$HOME/.agents/skills.bak\"\nrm -rf \"$CODEX_DIR/agents\" \"$CODEX_DIR/commands\" \"$HOME/.agents/skills\"\n```\n\nIf AGENTS.md is missing/outdated, fetch the current raw file and write it to `$CODEX_DIR/AGENTS.md`:\n\n```text\nWebFetch(url: \"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/main/docs/AGENTS.md\", prompt: \"Return the complete raw markdown content exactly as-is\")\n```\n\nTo keep only the newest cache version for a selected marketplace:\n\n```bash\nPLUGIN_CACHE_DIR=\"$PLUGIN_CACHE_ROOT/$MARKETPLACE_NAME/oh-my-codex\"\nKEEP_VERSION=$(for d in \"$PLUGIN_CACHE_DIR\"/*; do [[ -d \"$d\" ]] && basename \"$d\"; done | sort -V | tail -1)\n[[ -n \"$KEEP_VERSION\" ]] && find \"$PLUGIN_CACHE_DIR\" -mindepth 1 -maxdepth 1 -type d ! -name \"$KEEP_VERSION\" -exec rm -rf {} +\n```\n\nIf AGENTS.md is missing or stale, refresh it from the current release source, then rerun `omx doctor`. If legacy `~/.agents/skills` overlaps the canonical root, archive/remove that tree only after checking for custom skills. Restart Codex after fixes and report before/after evidence.\n\n## Exit conditions\n\nStop with **HEALTHY** only when required paths, hook/config checks, AGENTS marker, plugin cache status, and (when requested) Team checks pass. Otherwise report **ISSUES FOUND**, exact failed evidence, and the smallest confirmed remediation; do not claim a fix from a recommendation alone.\n","skills/git-master/SKILL.md":"---\nname: git-master\ndescription: Git expert for atomic commits, rebasing, and history management\n---\n\n# Git Master Command\n\nRoutes to the git-master agent for git operations.\n\n## Usage\n\n```\n/git-master <git task>\n```\n\n## Routing\n\n```text\nUse /prompts:git-master with the user task.\n```\n\n## Capabilities\n- Atomic commits with conventional format\n- Interactive rebasing\n- Branch management\n- History cleanup\n- Style detection from repo history\n","skills/hud/SKILL.md":"---\nname: \"hud\"\ndescription: \"Show or configure the OMX HUD (two-layer statusline)\"\nrole: \"display\"\nscope: \".omx/**\"\n---\n\n# HUD Skill\n\nThe OMX HUD uses a two-layer architecture:\n\n1. **Layer 1 - Codex built-in statusLine**: Real-time TUI footer showing model, git branch, and context usage. Configured via `[tui] status_line` in `~/.codex/config.toml`. Zero code required.\n\n2. **Layer 2 - `omx hud` CLI command**: Shows OMX-specific orchestration state (ralph, ultrawork, autopilot, team, pipeline, ecomode, turns). Reads `.omx/state/` files.\n\n## Quick Commands\n\n| Command | Description |\n|---------|-------------|\n| `omx hud` | Show current HUD (modes, turns, activity) |\n| `omx hud --watch` | Live-updating display (polls every 1s) |\n| `omx hud --json` | Raw state output for scripting |\n| `omx hud --preset=minimal` | Minimal display |\n| `omx hud --preset=focused` | Default display |\n| `omx hud --preset=full` | All elements |\n\n## Presets\n\n### minimal\n```\n[OMX] ralph:3/10 | turns:42\n```\n\n### focused (default)\n```\n[OMX] ralph:3/10 | ultrawork | team:3 workers | turns:42 | last:5s ago\n```\n\n### full\n```\n[OMX] ralph:3/10 | ultrawork | autopilot:execution | team:3 workers | pipeline:exec | turns:42 | last:5s ago | total-turns:156\n```\n\n## Setup\n\n`omx setup` automatically configures both layers:\n- Adds `[tui] status_line` to `~/.codex/config.toml` (Layer 1)\n- Writes `.omx/hud-config.json` with default preset (Layer 2)\n- Default preset is `focused`; if HUD/statusline changes do not appear, restart Codex CLI once.\n\n## Layer 1: Codex Built-in StatusLine\n\nConfigured in `~/.codex/config.toml`:\n```toml\n[tui]\nstatus_line = [\"model-with-reasoning\", \"git-branch\", \"context-remaining\"]\n```\n\nAvailable built-in items (Codex CLI v0.101.0+):\n`model-name`, `model-with-reasoning`, `current-dir`, `project-root`, `git-branch`, `context-remaining`, `context-used`, `five-hour-limit`, `weekly-limit`, `codex-version`, `context-window-size`, `used-tokens`, `total-input-tokens`, `total-output-tokens`, `session-id`\n\n## Layer 2: OMX Orchestration HUD\n\nThe `omx hud` command reads these state files:\n- `.omx/state/ralph-state.json` - Ralph loop iteration\n- `.omx/state/ultrawork-state.json` - Ultrawork mode\n- `.omx/state/autopilot-state.json` - Autopilot phase\n- `.omx/state/team-state.json` - Team workers\n- `.omx/state/pipeline-state.json` - Pipeline stage\n- `.omx/state/ecomode-state.json` - Ecomode active\n- `.omx/state/hud-state.json` - Last activity (from notify hook)\n- `.omx/metrics.json` - Turn counts\n\n## Configuration\n\nHUD config stored at `.omx/hud-config.json`:\n```json\n{\n \"preset\": \"focused\"\n}\n```\n\n## Color Coding\n\n- **Green**: Normal/healthy\n- **Yellow**: Warning (ralph >70% of max)\n- **Red**: Critical (ralph >90% of max)\n\n## Troubleshooting\n\nIf the TUI statusline is not showing:\n1. Ensure Codex CLI v0.101.0+ is installed\n2. Run `omx setup` to configure `[tui]` section\n3. Restart Codex CLI\n\nIf `omx hud` shows \"No active modes\":\n- This is expected when no workflows are running\n- Start an explicitly requested supported workflow (`$autopilot` or `$ultragoal`) and check again\n","skills/omx-setup/SKILL.md":"---\nname: omx-setup\ndescription: Setup and configure oh-my-codex using current CLI behavior\n---\n\n# OMX Setup\n\nUse this task card to install or refresh OMX for the current project and/or user scope. Shared safety, lifecycle, hook, team, autonomy, and cancellation rules live in `templates/AGENTS.md`. Do not infer new CLI behavior from this card; the implementation is authoritative.\n\n## Command and alternatives\n\n```bash\nomx setup [--force] [--merge-agents|--no-merge-agents|--clear-merge-agents-policy] [--dry-run] [--verbose] [--scope <user|project>] [--plugin|--legacy|--install-mode <legacy|plugin>] [--mcp <none|compat>] [--no-mcp|--with-mcp] [--disable-team|--enable-team|--team-mode <enabled|disabled>]\nomx agents-init [path] [--dry-run] [--force] [--verbose]\n```\n\nUse `agents-init` for lightweight AGENTS.md scaffolding only, not a full install.\n\nSupported setup options:\n- `--force`: overwrite/reinstall managed artifacts; transient, not persisted or replayed.\n- `--merge-agents`, `--no-merge-agents`, `--clear-merge-agents-policy`: exact bare selectors (no values/equals). Repeated identical selectors are idempotent; conflicting selectors fail before mutations. Set persists an explicit policy per invoking project root; clear removes it and cannot combine with a set. Merge refreshes managed sections; no-merge only suppresses that branch and is not a preserve mode.\n- `--dry-run`, `--verbose`: preview actions or show per-file/per-step detail.\n- `--scope user|project`: choose user (`~/.codex`, `~/.omx/agents`) or project (`./.codex`, `./.omx/agents`) targets.\n- `--plugin` / `--legacy`: select delivery mode; `--install-mode legacy|plugin` is the canonical scripted spelling. Conflicting mode flags fail.\n- `--mcp none|compat` (plus `--no-mcp` / `--with-mcp`): omit or enable first-party MCP compatibility and shared registry sync.\n- `--disable-team`, `--enable-team`, `--team-mode enabled|disabled`: select Team skill/context generation; conflicting selectors fail.\n\n## Resolve setup\n\n1. Scope: explicit flag, valid persisted `./.omx/setup-scope.json`, TTY choice (default `user`), or non-interactive `user`. Legacy `project-local` migrates to `project`.\n2. Mode: explicit flag, persisted mode when retained, discovered `${CODEX_HOME:-~/.codex}/plugins/cache/**/.codex-plugin/plugin.json` with `name: oh-my-codex` (plugin default), otherwise legacy. TTY reruns summarize saved choices and offer keep/review/reset; non-interactive runs do not block.\n3. Create required directories and atomically persist preferences only after successful setup.\n\n## What setup changes\n\n- Legacy mode installs prompts/native agents/skills and merges full config.toml.\n- Plugin mode archives/removes legacy OMX-managed prompts/skills, refreshes installable native agent TOMLs and stale generated non-installable agents, and keeps setup-owned runtime hooks.\n- Both modes verify Team CLI interop markers in built `dist/cli/team.js`, generate AGENTS defaults only when selected/allowed, and write `./.omx/hud-config.json`; notification hook references are setup-owned outside plugin skill delivery.\n- `AGENTS.md` is `./AGENTS.md`. Without `--force` or `--merge-agents`, interactive runs ask before overwrite and non-interactive runs preserve it. Active-session safeguards may skip writes. Plugin mode may separately prompt for AGENTS and `developer_instructions` defaults; non-interactive runs preserve existing files.\n- Plugin mode enables setup-owned runtime flags (`plugin_hooks`, `goals`, or legacy `hooks`/`codex_hooks` fallback). Project scope uses `CODEX_HOME=./.codex` unless explicitly overridden.\n\n## Verify\n\n```bash\nomx setup --force --verbose\nomx doctor\n```\n\nExpect doctor evidence for prompts and skills in the selected scope, project-root AGENTS.md, `.omx/state`, and CLI-first config in the scope target `config.toml`. First-party MCP and shared registry sync are omitted unless setup used `--mcp compat` (if supported by the installed CLI).\n\nIf using local source, run `npm run build` before `node dist/cli/omx.js setup --force --verbose` and `node dist/cli/omx.js doctor`. If AGENTS was not overwritten or merged, stop the active OMX session and rerun with `--force` or `--merge-agents`; do not edit lifecycle state manually.\n\n## Discovery troubleshooting\n\nIf `$omx-setup` is absent/stale: run `omx setup --verbose`, then `omx doctor`; verify `./.codex/skills/omx-setup/SKILL.md` for project scope or `${CODEX_HOME:-~/.codex}/skills/omx-setup/SKILL.md` for legacy user scope. In plugin mode verify the oh-my-codex plugin is installed/discovered. For duplicates, inspect historical `~/.agents/skills` overlap and follow doctor/setup cleanup guidance.\n\n## Exit contract\n\nReport selected scope/mode, dry-run versus mutation, AGENTS policy, affected roots, and doctor indicators. Stop only after setup completes successfully and verification identifies the expected files/config; on failure preserve the exact command output and rerun the smallest corrective command. Do not claim installation from a dry-run alone.\n","skills/performance-goal/SKILL.md":"---\nname: performance-goal\ndescription: \"Run an evaluator-gated performance optimization workflow over Codex goal mode with durable OMX artifacts and safe goal handoffs.\"\n---\n\n# Performance Goal Workflow\n\nUse this skill when a user asks OMX to optimize performance and wants a goal-oriented loop rather than a one-off review.\n\n## Contract\n\n- OMX owns durable workflow state under `.omx/goals/performance/<slug>/`.\n- Codex goal mode owns only the active-thread focus/accounting primitive.\n- Shell commands do **not** mutate hidden Codex goal state. They write artifacts and emit model-facing handoff text.\n- No optimization work may start until an evaluator command and pass/fail contract exist.\n- Do not call `update_goal({status: \"complete\"})` until the evaluator has a passing checkpoint and a completion audit proves the objective is done; then call `get_goal` again and pass that fresh snapshot to `omx performance-goal complete --codex-goal-json`.\n\n## CLI\n\nCreate the workflow and evaluator contract:\n\n```sh\nomx performance-goal create \\\n --objective \"Reduce CLI startup latency by 20%\" \\\n --evaluator-command \"npm run perf:startup\" \\\n --evaluator-contract \"PASS when p95 latency improves by 20% and regression tests pass\" \\\n --slug startup-latency\n```\n\nEmit the Codex goal handoff:\n\n```sh\nomx performance-goal start --slug startup-latency\n```\n\nRecord evaluator evidence:\n\n```sh\nomx performance-goal checkpoint --slug startup-latency --status pass --evidence \"benchmark + tests passed\"\nomx performance-goal checkpoint --slug startup-latency --status fail --evidence \"benchmark regressed\"\nomx performance-goal checkpoint --slug startup-latency --status blocked --evidence \"missing fixture\"\n```\n\nComplete only after a passing checkpoint:\n\n```sh\nomx performance-goal complete --slug startup-latency --evidence \"final evaluator evidence\" --codex-goal-json <get_goal-json-or-path>\n```\n\n## Agent Loop\n\n1. Run `omx performance-goal create` if no workflow exists.\n2. Run `omx performance-goal start` and follow the handoff:\n - call `get_goal`;\n - call `create_goal` only when no active goal exists and the objective is explicit;\n - work only against the evaluator contract;\n - after evaluator pass and completion audit, call `update_goal({status: \"complete\"})`, call `get_goal` again, and pass that snapshot to `omx performance-goal complete --codex-goal-json`;\n - after `omx performance-goal complete` succeeds, run `/goal clear` in the Codex UI before starting another goal in this same thread/session; OMX prints this terminal cleanup step but does not invoke hidden clear routes;\n3. Optimize in small reversible patches.\n4. Run the evaluator and related regression tests.\n5. Record each pass/fail/blocker with `checkpoint`.\n6. Complete only when the pass artifact exists and no required work remains.\n\n## Completion Gate\n\nA performance goal is incomplete unless `.omx/goals/performance/<slug>/state.json` contains a `lastValidation.status` of `pass` and `omx performance-goal complete` receives a matching complete Codex `get_goal` snapshot via `--codex-goal-json`. Passing ordinary tests alone is not sufficient unless they are the declared evaluator contract.\n\nLifecycle: `create_goal` starts the Codex thread goal, `update_goal({status: \"complete\"})` marks terminal success after the evaluator and audit pass, and `/goal clear` removes the completed thread goal when another same-thread goal is needed. OMX shell commands and hooks reconcile snapshots and print the cleanup instruction; they must not mutate hidden Codex goal state.\n","skills/pipeline/SKILL.md":"---\nname: pipeline\ndescription: Sunset stub — use $plan and $team directly instead\n---\n\n# Pipeline — removed\n\n`$pipeline` was removed in OMX 0.21.\n\nPipeline's configurable stage sequencing overlapped `$plan` (planning) and `$team` (execution) without a unique runtime. Use the canonical skills directly: `$plan` for optional planning, `$team` for coordinated parallel execution, `$ultragoal` for durable goal-mode runs.\n\nMigration: replace `$pipeline` with explicit `$plan` and `$team` invocations as the task warrants.\n\nTask: {{ARGUMENTS}}\n","skills/plan/SKILL.md":"---\nname: plan\ndescription: Lightweight planning with optional interview\n---\n\n<Purpose>\nPlan creates concise, actionable work plans. Auto-detects interview vs direct, supports `--interview` for Socratic clarification and `--review` for evaluation.\n</Purpose>\n\n<Use_When>\n- Planning before implementation — \"plan this\", \"let's plan\"\n- Requirements are vague and need scoping — use `--interview`\n- Reviewing an existing plan — `--review`\n</Use_When>\n\n<Do_Not_Use_When>\n- Want direct execution — execute the scoped task directly; use `ultragoal` only for durable goals or `team` for coordinated parallel work\n- Simple focused fix with obvious scope — skip planning\n</Do_Not_Use_When>\n\n<Execution_Policy>\n- Auto-detect interview vs direct; `--interview` forces Socratic mode, `--direct` skips it\n- Ask one question at a time; gather codebase facts first\n- `omx explore` is deprecated. Use normal repository inspection for codebase facts; `omx sparkshell` only for explicit shell-native evidence\n- Plans must be evidence-backed: 80%+ claims cite file/line, 90%+ criteria testable\n- Right-size steps to scope; save to `.omx/plans/`\n</Execution_Policy>\n\n<Steps>\n\n### Mode Selection\n| Mode | Trigger | Behavior |\n|------|---------|----------|\n| Interview | `--interview` or broad request | Socratic requirements gathering |\n| Direct | `--direct` or detailed request | Generate plan immediately |\n| Review | `--review` | Critic evaluation of existing plan |\n\n### Interview (`--interview`)\n1. Classify request; ask one focused question via `omx question`\n2. Gather codebase facts first, then ask informed follow-ups\n3. Build on answers; consult Analyst for hidden requirements\n4. Create plan when user signals readiness\n\n### Direct\n1. Quick analysis (optional Analyst)\n2. Generate plan immediately\n3. Optional Critic review if requested\n\n### Review (`--review`)\n1. Read plan from `.omx/plans/`\n2. Evaluate via Critic; verdict APPROVED/REVISE/REJECT\n3. If author == reviewer, hand off to `$code-review`\n\n### Output\nEvery plan includes: Requirements Summary, Acceptance Criteria (testable), Implementation Steps (with file refs, adaptive count), Risks/Mitigations, Verification. Saved to `.omx/plans/`.\n\nOutcome-first framing: apply outcome-first framing, concise visible updates for multi-step planning. Local overrides for the active workflow branch apply via newer user task updates. If the user says `continue`, continue the current branch instead of restarting.\n\n</Steps>\n\n<Tool_Usage>\n- `omx explore` is deprecated. Use normal repository inspection; `omx sparkshell` only for explicit shell-native evidence\n- Use `omx question` for interview questions; plain text only as fallback\n- Use `ask_codex` with `planner`/`analyst`/`critic` as needed\n</Tool_Usage>\n\n<Escalation_And_Stop_Conditions>\n- Stop interviewing when requirements are clear — do not over-interview\n- Escalate on irreconcilable trade-offs requiring business decision\n- \"just do it\" / \"skip planning\" → hand off to `$ultragoal`\n</Escalation_And_Stop_Conditions>\n\n<Final_Checklist>\n- [ ] Acceptance criteria testable (90%+ concrete)\n- [ ] Claims cite file/line (80%+)\n- [ ] Risks have mitigations, no vague terms\n- [ ] Plan saved to `.omx/plans/`\n</Final_Checklist>\n\n<Advanced>\n## Question Classification\n| Type | Examples | Action |\n|------|----------|--------|\n| Codebase Fact | \"Where is X?\" | Explore first, do not ask |\n| User Preference | \"Priority?\" | Ask via `omx question` |\n| Scope Decision | \"Include Y?\" | Ask user |\n\n## Review Quality Criteria\n| Criterion | Standard |\n|-----------|----------|\n| Clarity | 80%+ claims cite file/line |\n| Testability | 90%+ criteria concrete |\n| Verification | File refs exist |\n</Advanced>\n","skills/ralph/SKILL.md":"---\nname: ralph\ndescription: Sunset stub — use $ultragoal instead\n---\n\n# Ralph — removed\n\n`$ralph` was removed in OMX 0.21; use `$ultragoal` instead.\n\nRalph's loop-until-done behavior is a degenerate single-goal ultragoal run. `$ultragoal` owns durable Codex goal handoffs, `.omx/ultragoal` ledger checkpoints, implementation, tests, build/lint/typecheck evidence, and resume across stories. A single-goal ultragoal run reuses the same persistence and verified-completion promise that Ralph provided.\n\nMigration: replace `$ralph` with `$ultragoal`.\n\nTask: {{ARGUMENTS}}\n","skills/ralplan/SKILL.md":"---\nname: ralplan\ndescription: Consensus planning stage for Planner -> Architect -> Critic handoff to $ultragoal\n---\n\n# Ralplan (Consensus Planning Alias)\n\nRalplan is the canonical consensus-planning stage used by Autopilot between `$deep-interview` and `$ultragoal`. It drives Planner, Architect, and Critic planning and records their review lifecycle with **RALPLAN-DR structured deliberation** (short mode by default, deliberate mode for high-risk work). Local lifecycle evidence is not host-issued security authority, but ordinary progression to Ultragoal must remain reachable after the execution-ready plan and sequential review evidence are durable; missing host provenance must not terminalize Ralplan or block cancel, clear, or recovery.\n\n## Usage\n\n```\n$ralplan \"task description\"\n```\n\nStandalone advisory planning is explicitly opt-in:\n\n```text\n$ralplan --advisory \"task description\"\n```\n\nAdvisory runs the same sequential Planner → Architect → Critic review lifecycle, binds the plan and both review artifacts to exact bytes and one tracker-backed iteration, then returns to the caller with `active:false`. It is a cooperative workflow pause, not a security fence or permission system. It never emits a `PreToolUse` allow/block decision, never completes the host consensus gate, never authorizes execution, and never suppresses unrelated host behavior. Terminal state must carry explicit `false` values for the consensus gate, host verification, and execution handoff rather than omitting them. A later concrete affirmative execution request may produce non-authoritative routing context, but it does not persist a permission, rewrite terminal evidence, or create an automatic handoff; quotations, code, examples, documentation, questions, modal requests, negations, and vague approval remain classifier negatives. `approved+proven` requires complete lifecycle digests plus post-write revalidation. Administrative abandonment is append-only, idempotent for prepared or committed journals, and records a separate byte-bound admin event without rewriting the original closeout journal. Real enforcement requires an explicit host-issued, host-verified receipt or capability on a non-user-mintable surface; local Advisory files, prompts, session/thread fields, tracker records, and HERDR observability cannot substitute for it. On Darwin, each Advisory evidence artifact is limited to 128 KiB by the pinned-directory reader; other supported platforms allow up to 8 MiB.\n\n## Flags\n\n- `--interactive`: Enables user prompts at key decision points (draft review in step 2 and final approval in step 6). Without this flag the workflow runs fully automated — Planner → Architect → Critic loop — and outputs the final plan without asking for confirmation.\n- `--deliberate`: Forces deliberate mode for high-risk work. Adds pre-mortem (3 scenarios) and expanded test planning (unit/integration/e2e/observability). Without this flag, deliberate mode can still auto-enable when the request explicitly signals high risk (auth/security, migrations, destructive changes, production incidents, compliance/PII, public API breakage).\n- `--advisory`: Standalone only. It cannot be combined with Autopilot, Pipeline, Team, Ralph, Ultragoal, execution flags, or unknown flags. Activation requires canonical session, root thread, and turn identity.\n\n## Ontology-heavy review\n\nFor requirements semantics, taxonomy, prompt/spec design, policy distinctions, or category-risk architecture, cite the `architect` role agent's read-only review as advisory evidence. Its findings can inform the plan or follow-up evidence when explicitly used, but `$ralplan` itself records Architect→Critic lifecycle evidence only, and advisory review is never a durable execution authorization.\n\n## Usage with interactive mode\n\n```\n$ralplan --interactive \"task description\"\n```\n\n## Behavior\n\n## GPT-5.6 Guidance Alignment\n\nUse the shared workflow guidance pattern: outcome-first framing, concise visible updates for multi-step planning, local overrides for the active workflow branch, evidence-backed planning and validation expectations, explicit stop rules, right-sized implementation/PRD shape, and automatic continuation for safe reversible steps. Ask only for material, destructive, credentialed, external-production, or preference-dependent branches.\n\nThis skill runs its own consensus runtime; it does not delegate to a nonexistent Plan consensus mode:\n\n```\nomx ralplan run --task <arguments> [--session <id>]\n```\n\nThe consensus workflow:\n1. **Planner** creates an adaptive plan (right-sized to task scope; do not default to exactly five steps) and a compact **RALPLAN-DR summary** before review. Current `[main]` vs `[planner]` behavior: standalone `$ralplan` may be authored by the active main planning lane unless the caller/runtime supplies a dedicated planner routing record; inside `$autopilot`, state field `planning_routing.owner:\"planner\"` means the initial Planner draft/decomposition must use dedicated `[planner]`. Set `.omx-config.json` `agentModels.planner` to opt into a specific planner model and force dedicated planner ownership for complex Autopilot planning even when `[main]` is not cheap/mini. The RALPLAN-DR summary includes:\n - Principles (3-5)\n - Decision Drivers (top 3)\n - Viable Options (>=2) with bounded pros/cons\n - If only one viable option remains, explicit invalidation rationale for alternatives\n - Deliberate mode only: pre-mortem (3 scenarios) + expanded test plan (unit/integration/e2e/observability)\n2. **User feedback** *(--interactive only)*: If `--interactive` is set, use the structured question UI (`omx question` in attached tmux; native structured input outside tmux when available) to present the draft plan **plus the Principles / Drivers / Options summary** before review (Proceed to review / Request changes / Skip review). Otherwise, automatically proceed to review.\n**Native role-routing preflight:** Keyword routing may already have selected Ralplan, but it is not authority. Run `omx ralplan preflight --json` only when the native task surface reports `role_routing_unavailable` and this workflow attempts adapted Ralplan Planner, Architect, or Critic authority, adapted role-intent, or adapted consensus authority. On `unsupported_documented_leader_proof`, stop before that adapted authority and use a Codex surface with documented root proof or a reviewed alternative workflow. Do not infer root identity from `session_id`, undocumented `thread_id`, session/pointer/transcript/cwd state, absence of child data, or a prompt label. Ordinary native planning, lifecycle, state, status, health, HUD, runtime, setup, install, sync, and unrelated delegation are outside this preflight boundary and remain governed by existing controls.\n\n**Native role-routing rule:** When the native surface exposes `agent_type` role routing, set `agent_type` to an installed OMX role and never omit it for OMX work. When it does not (`role_routing_unavailable`), do not fabricate `agent_type`. On the exact reviewed Codex releases 0.144.5, 0.145.0, 0.146.1, and 0.148.0-alpha.5, adapted Ralplan Planner, Architect, Critic, role-intent, and consensus authority are unavailable because they lack documented root proof; every other version remains unknown and fails closed. Do not silently weaken routing with a prompt role label or inferred carrier. Use a Codex surface with documented root proof or a reviewed alternative workflow for that authority. A direct `omx ralplan role-intent write` attempt is denied with machine reason `unsupported_documented_leader_proof`.\n\n3. **Architect** reviews for architectural soundness and must provide the strongest steelman antithesis, at least one real tradeoff tension, and (when possible) synthesis — **await completion before step 4**. Launch this as a subsequent role-specific `Architect` subagent and pass the full task statement, context snapshot, PRD/test-spec paths, and relevant prior findings; do not substitute an unvalidated reviewer identity or a short improvised reviewer prompt. In deliberate mode, Architect should explicitly flag principle violations.\n4. **Critic** evaluates against quality criteria — run only after step 3 completes. Launch this as a subsequent role-specific `Critic` subagent with the full task statement, context snapshot, PRD/test-spec paths, and the completed Architect review; do not ask the Architect subagent to perform the Critic gate and do not substitute an unvalidated reviewer identity or a short improvised reviewer prompt. Critic must enforce principle-option consistency, fair alternatives, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. In deliberate mode, Critic must reject missing/weak pre-mortem or expanded test plan.\n5. **Re-review loop** (max 5 iterations): Any non-`APPROVE` Critic verdict (`ITERATE` or `REJECT`) MUST run the same full closed loop:\n a. Collect Architect and Critic feedback\n b. Revise the plan with Planner\n c. Return to Architect review\n d. Return to Critic evaluation\n e. Repeat this loop until Critic returns `APPROVE` or 5 iterations are reached\n f. If 5 iterations are reached without `APPROVE`, present the best version to the user\n6. On Critic approval, persist the execution-ready planning artifacts and sequential Architect→Critic evidence. In standalone interactive Ralplan, present the requested future execution lane. Inside Autopilot, the existing explicit `$autopilot` invocation authorizes the supervised transition to its defining next stage, `$ultragoal`; persist an Autopilot-owned `ralplan_execution_handoff` bound to the same session and review cycle.\n7. Record `ralplan_execution_handoff` with `{authorized: true, reason, authorized_at, session_id, review_cycle, source: \"autopilot\"|\"user\"}`. `source:\"autopilot\"` is valid only for a supervised active Autopilot run whose current phase is `ralplan`; it does not claim host-consensus authority.\n8. Transition to `$ultragoal` after the durable plan, sequential approvals, and bound execution handoff exist. Do not implement directly inside Ralplan.\n\n> **Important:** Steps 3 and 4 MUST run sequentially as role-specific subagents. Do NOT issue both agent calls in the same parallel batch. Always await the subsequent `Architect` result before invoking the subsequent `Critic`; their completed approvals establish local lifecycle evidence only and cannot satisfy the durable execution gate.\n\n## Planning/Execution Boundary\n\n`$ralplan` is a planning mode. While ralplan is active and no explicit execution handoff is active, implementation-focused write tools are out of scope. Ralplan may inspect the repository and may write only planning artifacts such as `.omx/context/`, `.omx/plans/`, `.omx/specs/`, and required `.omx/state/` records.\n\nThe canonical flow is:\n\n```\n$ralplan -> local Architect→Critic lifecycle evidence -> bound execution handoff -> $ultragoal\n```\n\nBefore any execution lane begins, ralplan must emit terminal planning state (complete, paused, failed, or waiting for input) and the durable handoff record below. Do not continue from consensus planning into direct code edits in the same ralplan session.\n\n## Durable Consensus Handoff Contract\n\nRalplan is not complete, skippable, or ready for execution merely because `.omx/plans/prd-*.md` and `.omx/plans/test-spec-*.md` exist. Those files are planning artifacts, not consensus evidence.\n\nBefore any Autopilot, Ultragoal, Team, or implementation handoff, persist a durable handoff record that distinguishes:\n\n- `planning_artifacts`: PRD/test-spec paths.\n- `ralplan_architect_review`: the completed Architect review with an approving verdict.\n- `ralplan_critic_review`: the completed Critic review with an approving verdict, recorded only after the Architect review.\n- `ralplan_execution_handoff`: persist `{authorized: true, reason: \"<rationale>\", authorized_at: \"<ISO timestamp>\", session_id: \"<current session>\", review_cycle: <matching lifecycle cycle>, source: \"autopilot\"|\"user\"}`. Autopilot may issue this only for its own supervised `ralplan` phase; standalone Ralplan uses `source:\"user\"`.\n- `ralplan_consensus_gate.complete` records lifecycle completion after the sequential Architect and Critic approvals. It is not a host-security claim. Locally authored JSON/env/prompt/tracker/transcript/receipt-shaped evidence must never be described as host-issued authority.\n\nIf Architect is missing/blocked, keep the workflow in Architect review or report that blocker. If Critic is missing/blocked/non-approving, keep the workflow in Critic/re-review or report the max-iteration outcome. After both reviews approve, execution begins only when the matching `ralplan_execution_handoff` is durable. Existing plan/test-spec files alone are never permission to skip Ralplan or execute.\n\nFollow the Plan skill's full documentation for consensus mode details.\n\n## Goal-Mode Follow-up Suggestions\n\nWhen a bound `ralplan_execution_handoff` permits execution, include product-facing goal-mode suggestions alongside coordinated Team execution. Record the requested lane and persist the handoff without claiming host-issued authority.\n\n- `$ultragoal` — **default goal-mode follow-up** for implementation or general goal-oriented follow-up plans that should become durable Codex/OMX goals with sequential completion tracking.\n- `$autoresearch` — research-project follow-up when the plan centers on a question, literature/reference gathering, evaluator-backed research, or a professor/critic-style research deliverable. (`$autoresearch-goal` was retired to a sunset stub in OMX 0.21.)\n- `$performance-goal` — optimization/performance follow-up when the plan centers on speed, latency, throughput, memory, benchmark, or other measurable performance work.\n\nUse `$ultragoal` for durable goal tracking and `$team` for coordinated parallel implementation. When combined, Ultragoal owns the ledger and Team returns checkpoint-ready execution evidence.\nUse the available-agent-types roster to produce explicit role/staffing allocation, reasoning-by-lane guidance, concrete launch hints (including `omx team` when parallel delivery is justified), and team verification responsibilities for any future receipt-authorized execution path.\n\n## Pre-context Intake\n\nBefore consensus planning or execution handoff, ensure a grounded context snapshot exists:\n\n1. Derive a task slug from the request.\n2. Reuse the latest relevant snapshot in `.omx/context/{slug}-*.md` when available.\n3. If none exists, create `.omx/context/{slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`) with:\n - task statement\n - desired outcome\n - known facts/evidence\n - constraints\n - unknowns/open questions\n - likely codebase touchpoints\n4. If ambiguity remains high, gather brownfield facts first. `omx explore` is deprecated; use normal repository inspection tools/subagents for simple read-only repository lookups and `omx sparkshell` only for explicit shell-native read-only evidence. Then run `$deep-interview --quick <task>` before continuing.\n5. If the plan depends on official docs, version-aware framework guidance, best practices, or external dependency behavior, use `$best-practice-research` as the bounded evidence wrapper and auto-delegate `researcher` for the official/upstream lookup before finalizing the planning handoff so execution does not start from repo-local recall alone.\n6. If a prior `$autoresearch` run exists, treat its approved artifact as evidence for the plan. Read historical artifacts from `$autoresearch-goal` only as compatibility input. Do not include Autoresearch as a final architecture or runtime component unless the user explicitly requested ongoing research automation; otherwise synthesize the evidence into the `$ralplan` ADR, risks, and verification steps.\n\nDo not hand off to execution modes until this intake is complete; if urgency forces progress, explicitly document the risk tradeoffs.\n\n## Routing boundary\n\nOrdinary scoped tasks stay in the direct execution lane described by `templates/AGENTS.md`.\nExplicit workflow requests follow the keyword registry (`src/hooks/keyword-registry.ts`) and their owning skill contracts; this card does not define a second activation table.\nOnce Ralplan is active, preserve the planning/execution and consensus handoff requirements above. A conversational “just do it” is not a substitute for the required review evidence.\n\n## Scenario Examples\n\n**Good:** The user says `continue` after the workflow already has a clear next step. Continue the current branch of work instead of restarting or re-asking the same question.\n\n**Good:** The user changes only the output shape or downstream delivery step (for example `make a PR`). Preserve earlier non-conflicting workflow constraints and apply the update locally.\n\n**Bad:** The user says `continue`, and the workflow restarts discovery or stops before the missing verification/evidence is gathered.\n","skills/skill/SKILL.md":"---\nname: skill\ndescription: Manage local skills - list, add, remove, search, edit, setup wizard\nargument-hint: \"<command> [args]\"\n---\n\n# Skill Management\n\nManage local `SKILL.md` files with `/skill` commands. Shared execution, delegation,\nstate, hook, team, cancellation, verification, and escalation invariants live in\n`templates/AGENTS.md`; follow that contract instead of repeating it here.\n\n<Purpose>\nCreate, inspect, validate, update, and organize user- or project-scoped skills.\nKeep each skill specific, actionable, evidence-based, and useful to this codebase.\n</Purpose>\n\n<Use_When>\n- The user asks to list, add, edit, remove, search, inspect, sync, set up, scan, or validate skills.\n- A durable, codebase-specific solution or workflow should be captured as a skill.\n</Use_When>\n\n<Do_Not_Use_When>\n- Use `/learner` to extract a skill from a conversation and `/note` for a short note.\n- Do not use this prompt to change runtime code, catalogs, hooks, or installation logic.\n</Do_Not_Use_When>\n\n## Scopes and commands\n\nCanonical roots are `${CODEX_HOME:-$HOME/.codex}/skills/` (user) and `.codex/skills/`\n(project). A skill lives at `<root>/<name>/SKILL.md`.\n\n| Command | Contract |\n|---|---|\n| `/skill list` | Scan both roots, parse frontmatter, and show name, description, triggers, scope, and quality/usage (`N/A` when unavailable). |\n| `/skill add [name]` | Run the authoring wizard, validate the name, choose scope, create `SKILL.md`, and report its path. |\n| `/skill edit <name>` | Find one scope, show metadata, then update description, triggers, argument hint, body, or rename and report the change. |\n| `/skill remove <name>` | Find the skill, show scope and metadata, confirm explicitly, then remove its directory. |\n| `/skill search <query>` | Case-insensitively search name, description, triggers, and body; rank name/trigger matches first and show context. |\n| `/skill info <name>` | Show parsed metadata, scope, path, and full body; suggest `/skill search` when absent. |\n| `/skill sync` | Compare user/project skills, show user-only/project-only/common entries, and confirm every copy or overwrite. |\n| `/skill setup` | Ensure both roots exist, scan them, then offer add, list, pattern scan, import, or done. |\n| `/skill scan` | Run setup's scan/inventory without its interactive menu. |\n| `/skill validate` | Validate every skill in both roots and report each path's pass/fail result; never rewrite files. |\n\nWith an argument, use direct command mode; without one, use the guided setup menu.\n\n## Authoring contract\n\nAsk for any missing values:\n1. `name`: lowercase letters/digits separated by single hyphens (`[a-z0-9]+(?:-[a-z0-9]+)*`).\n2. `description`: a concise, non-empty one-line purpose.\n3. `triggers`: comma-separated recognition terms.\n4. `argument-hint`: optional invocation arguments.\n5. `scope`: `user` or `project`.\n\nWrite this frontmatter at the start of every skill; optional metadata may add `id`,\n`source`, and `quality` without replacing required fields:\n\n```yaml\n---\nname: <name>\ndescription: <one-line purpose>\ntriggers: [<trigger1>, <trigger2>]\nargument-hint: \"<args>\"\n# optional: id, source, quality\n---\n```\n\nUse an actionable body. The minimum recommended shape is:\n\n```markdown\n# <Skill title>\n\n## Purpose\nWhat durable, codebase-specific outcome does this skill provide?\n\n## When to Activate\nRecognition signals, scope, and explicit non-goals.\n\n## Workflow\n1. Inspect the named files or inputs.\n2. Apply the precise approach and record important assumptions.\n3. Verify observable behavior and report evidence.\n\n## Examples / Gotchas\nConcrete invocation, edge cases, and failure recovery.\n```\n\nPrefer hard-won, non-obvious knowledge over generic programming advice. Include\nexact paths, commands, error text, and expected evidence when they materially help.\n\n## Validation and errors\n\nBefore reporting success, check that the file exists, starts with `---` frontmatter,\nhas non-empty `name` and `description`, uses a valid name, and has a non-empty body.\nReject malformed or unterminated YAML, multiline required scalar values, duplicate\nnames in one scope, missing directories/files, permission failures, and invalid\narguments. Report errors consistently:\n\n```text\n✗ Error: <clear message>\n→ Suggestion: <specific next step>\n```\n\n## Exit contract\n\nEvery command ends with one concise result: `✓` plus the affected skill/path and\nnext action, or `✗` plus the error and suggestion. Preserve files on cancel or\nvalidation-only runs. For add/edit/sync, report changed scope and metadata; for\nlist/search/info/scan/validate, report counts or matched paths and any failures.\n","skills/team/SKILL.md":"---\nname: team\ndescription: N coordinated agents on shared task list using tmux-based orchestration\n---\n\n# Team Skill\n\n## When to use\n\nUse only for an explicit `$team` request or `omx team ...` launch that benefits from durable tmux workers, shared task state, mailbox coordination, or worktree isolation. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot`; do not copy its durable rules into this card.\n\n## Inputs and preconditions\n\n- Launch shape: `omx team [N:agent-type] \"<task>\"` (for example `omx team 3:executor \"implement X\"`).\n- Require `tmux -V`, a leader session with `$TMUX`, and the intended `omx` executable. In Codex App/plain non-tmux sessions, explain the runtime boundary instead of pretending Team is available.\n- Before launch, ground the task in a recent `.omx/context/{slug}-*.md`; create a concise snapshot when none exists. Include target, evidence, constraints, unknowns, and likely touchpoints.\n- Do not launch nested Team runs. Pick worker roles deliberately; use `OMX_TEAM_WORKER_CLI=codex|claude|auto` or `OMX_TEAM_WORKER_CLI_MAP=...` only when needed.\n- Per-agent reasoning is set by `agentReasoning`; accepted values are `low`, `medium`, `high`, `xhigh`, and `max`. `max` is passed unchanged and remains capability-dependent. `ultra` is unsupported and is not an alias for `max`.\n- Invalid configured values use the built-in role-default fallback. An explicit raw `-c model_reasoning_effort=...` is opaque and wins. When both sources are present, explicit raw reasoning wins over inherited Team reasoning and environment reasoning. Do not downgrade or retry `max` as `xhigh`; built-in role defaults remain unchanged.\n\n## Operational steps\n\n1. Start the runtime and capture startup evidence: `Team started: <name>`, tmux target, worker panes, and the leader ACK mailbox.\n2. **Current Runtime Behavior:** runtime-owned task files and APIs are the operational interface; the durable ownership and safety rules remain in `templates/AGENTS.md`.\n3. Runtime creates `.omx/state/team/<name>/config.json`, `manifest.v2.json`, `tasks/task-<id>.json`, worker identities/inboxes, mailbox files, and a dispatch queue. Workers receive `OMX_TEAM_WORKER`, `OMX_TEAM_STATE_ROOT`, and `OMX_TEAM_LEADER_CWD`.\n4. Deliver assignments through durable inbox/task state and the CLI API. The worker card defines ACK, claim, transition, mailbox, and idle-status commands.\n5. Prefer these machine-readable operations:\n ```bash\n omx team api send-message --input '{\"team_name\":\"<name>\",\"from_worker\":\"leader-fixed\",\"to_worker\":\"worker-1\",\"body\":\"<short trigger>\"}' --json\n omx team api read-task --input '{\"team_name\":\"<name>\",\"task_id\":\"<id>\"}' --json\n omx team api transition-task-status --input '{\"team_name\":\"<name>\",\"task_id\":\"<id>\",\"from\":\"in_progress\",\"to\":\"completed\",\"claim_token\":\"<token>\"}' --json\n ```\n6. Monitor with `omx team status <name> --json` or `omx team await <name> --timeout-ms 30000 --json`; inspect mailbox/state files when a worker is blocked or stale.\n7. Keep the team running until `pending=0`, `in_progress=0`, and `failed=0` (or an explicitly acknowledged failure path). Run `omx team shutdown <name>` only then, unless the user explicitly aborts.\n8. Verify shutdown evidence and state cleanup. Do not claim completion while workers are still writing.\n\n## Team and Ultragoal\n\nWhen a leader-owned `.omx/ultragoal/goals.json` exists, workers return task evidence only. The leader checkpoints with a fresh Codex `get_goal` snapshot:\n```bash\nomx ultragoal checkpoint --goal-id <id> --status complete --evidence \"<Team evidence>\" --codex-goal-json <fresh-get-goal-json-or-path>\n```\nTeam launch remains an explicit separate action; it does not create hidden Codex goals.\n\n## Dispatch and recovery\n\n- If dispatch reports `worker_notify_failed:<worker>`, inspect `tmux list-panes`, capture the pane, then send one concise trigger and re-check mailbox/state.\n- For Claude panes, do not spam Enter while work is active. Confirm runtime status first.\n- If a worker reports `omx team api ... ENOENT`, check whether shutdown or state deletion happened too early; preserve state until all transitions finish.\n- For a clean retry, kill only known stale worker panes, remove only the exact stale Team root, and relaunch; never kill the leader/HUD pane accidentally.\n\n## Exit and evidence\n\nReport team name, launch command, pane/ACK evidence, task counts, worker verification, failures or blockers, shutdown result, and cleaned state paths. Include any worktree or CLI-map choices and keep final integration/verification in the leader lane.\n","skills/ultragoal/SKILL.md":"---\nname: ultragoal\ndescription: Create and execute durable repo-native multi-goal plans over Codex goal mode artifacts.\n---\n\n# Ultragoal Workflow\n\n## When to use\n\nUse for `ultragoal`, `create-goals`, `complete-goals`, durable multi-goal planning, or sequential execution over Codex `/goal`. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot` for state ownership and goal-tool boundaries.\n\n## Inputs and preconditions\n\n- Durable artifacts are `.omx/ultragoal/brief.md`, `.omx/ultragoal/goals.json`, and `.omx/ultragoal/ledger.jsonl`.\n- New plans use aggregate Codex goal mode by default: one stable pointer objective for the plan while OMX tracks individual stories. Use `--codex-goal-mode per-story` only when explicitly requested.\n- Do not call `/goal clear` from shell or this skill. After a completed run, the operator may clear the interactive Codex goal in the Codex UI before another same-thread run.\n\n## Operational steps: create\n\nRun one command, then inspect the generated plan:\n```bash\nomx ultragoal create-goals --brief \"<brief>\"\nomx ultragoal create-goals --brief-file <path>\ncat <brief> | omx ultragoal create-goals --from-stdin\nomx ultragoal create-goals --codex-goal-mode per-story --brief \"<brief>\"\n```\nIf refinement is needed, use explicit supported steering rather than editing durable artifacts by hand.\n\n## Operational steps: execute\n\nRepeat until `omx ultragoal status` reports all goals complete:\n\n1. Run `omx ultragoal complete-goals` and read its handoff.\n2. Call `get_goal`. Call `create_goal` with the printed payload only when no active Codex goal exists; otherwise continue the matching aggregate objective.\n3. Complete one OMX story and audit its objective against real artifacts and verification evidence.\n4. For intermediate aggregate stories, keep the Codex goal active and checkpoint:\n ```bash\n omx ultragoal checkpoint --goal-id <id> --status complete --evidence \"<evidence>\" --codex-goal-json <fresh-get-goal-json-or-path>\n ```\n5. For a blocked/failed story, use `--status blocked|failed` with evidence; resume failed work with `omx ultragoal complete-goals --retry-failed`.\n6. On the final story, complete the final gate below before `update_goal({status: \"complete\"})`; then call `get_goal` again and checkpoint the fresh complete snapshot.\n\n## Explicit steering\n\nUse evidence-backed directives only when the decomposition must change:\n```bash\nomx ultragoal steer --kind add_subgoal --title \"<title>\" --objective \"<objective>\" --evidence \"<evidence>\" --rationale \"<reason>\" --json\nomx ultragoal steer --directive-json ./steering.json --json\n```\nSupported kinds: `add_subgoal`, `split_subgoal`, `reorder_pending`, `revise_pending_wording`, `annotate_ledger`, and `mark_blocked_superseded`. Ordinary prose does not mutate the plan; repeated structured directives dedupe.\n\n## Phase/HUD handoff\n\nAt standalone activation, declare the smallest accurate phase (`planning`, `executing`, `verifying`, `reviewing`, `checkpointing`, or `blocked`):\n```bash\nomx state write --input '{\"mode\":\"ultragoal\",\"active\":true,\"current_phase\":\"planning\"}' --json\n```\nInside Autopilot, keep the parent mode active and set `current_phase:\"ultragoal\"`; persist Ultragoal evidence under `handoff_artifacts.ultragoal` before a code-review handoff. Mark standalone Ultragoal complete only when every durable goal is complete.\n\n## Optional Team bridge\n\nFor parallel story execution, use the separate Team command. The leader records the Ultragoal checkpoint with a fresh `get_goal` snapshot; see the Team skill for the bridge details.\n\n## Final gate and exit evidence\n\nBefore final completion:\n\n1. Run targeted story verification.\n2. Run `ai-slop-cleaner` on changed files, then rerun verification.\n3. Audit every architecture/domain invariant from the brief/spec/accepted steering against implementation, test, and review evidence.\n4. Run `$code-review` through independent `code-reviewer` and `architect` lanes. If review or invariant proof is not clean, do not update the Codex goal; record durable blockers:\n ```bash\n omx ultragoal record-review-blockers --goal-id <id> --title \"Resolve final code-review blockers\" --objective \"<objective>\" --evidence \"<findings>\" --codex-goal-json <active-get-goal-json-or-path>\n ```\n5. If clean, call `update_goal({status: \"complete\"})`, call `get_goal`, and checkpoint with `--quality-gate-json` containing cleaner, verification, review, and architecture-invariant evidence.\n\nReport goal ids/statuses, ledger/checkpoint paths, fresh goal snapshot evidence, review verdicts, and any blocker. Never claim completion from OMX state alone.\n","skills/ultraqa/SKILL.md":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=skills%2Fultraqa%2FSKILL.md -->","skills/ultrawork/SKILL.md":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=skills%2Fultrawork%2FSKILL.md -->","skills/ultrawork/references/agent-tiers.md":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=skills%2Fultrawork%2Freferences%2Fagent-tiers.md -->","skills/visual-ralph/SKILL.md":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=skills%2Fvisual-ralph%2FSKILL.md -->","skills/wiki/SKILL.md":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=skills%2Fwiki%2FSKILL.md -->","skills/worker/SKILL.md":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=skills%2Fworker%2FSKILL.md -->","templates/AGENTS.md":"<!-- AUTONOMY DIRECTIVE — DO NOT REMOVE -->\nYOU ARE AN AUTONOMOUS CODING AGENT. EXECUTE TASKS TO COMPLETION WITHOUT ASKING FOR PERMISSION.\nDO NOT STOP TO ASK \"SHOULD I PROCEED?\" — PROCEED. DO NOT WAIT FOR CONFIRMATION ON OBVIOUS NEXT STEPS.\nIF BLOCKED, TRY AN ALTERNATIVE APPROACH. ONLY ASK WHEN TRULY AMBIGUOUS OR DESTRUCTIVE.\nUSE CODEX NATIVE SUBAGENTS FOR INDEPENDENT PARALLEL SUBTASKS WHEN THAT IMPROVES THROUGHPUT. THIS IS COMPLEMENTARY TO OMX TEAM MODE.\n<!-- END AUTONOMY DIRECTIVE -->\n\n# oh-my-codex - Intelligent Multi-Agent Orchestration\n\nYou are running with oh-my-codex (OMX), a coordination layer for Codex CLI.\nThis AGENTS.md is the top-level operating contract for the workspace.\nRole prompts under `prompts/*.md` are narrower execution surfaces. They must follow this file, not override it.\nWhen OMX is installed, load the installed prompt/skill/agent surfaces from `~/.codex/prompts`, `~/.codex/skills`, and `~/.codex/agents` (or the project-local `./.codex/...` equivalents when project scope is active).\n\n<guidance_schema_contract>\nCanonical guidance schema for this template is defined in `docs/guidance-schema.md`.\nKeep runtime marker contracts stable and non-destructive when overlays are applied:\n- `<!-- OMX:RUNTIME:START --> ... <!-- OMX:RUNTIME:END -->`\n- `<!-- OMX:TEAM:WORKER:START --> ... <!-- OMX:TEAM:WORKER:END -->`\n</guidance_schema_contract>\n\n<operating_principles>\n- Solve the task directly when you can do so safely and well.\n- Delegate only when it materially improves quality, speed, or correctness.\n- Keep progress short, concrete, and useful.\n- Prefer evidence over assumption; verify before claiming completion.\n- Check official documentation before implementing with unfamiliar SDKs, frameworks, or APIs.\n- Within one Codex session or team pane, use Codex native subagents for independent, bounded subtasks when that improves throughput.\n<!-- OMX:GUIDANCE:OPERATING:START -->\n- Default to outcome-first, quality-focused responses: identify the user's target result, success criteria, constraints, available evidence, expected output, and stop condition before adding process detail.\n- Keep collaboration style short and direct. Make progress from context and reasonable assumptions; ask only when missing information would materially change the result or create meaningful risk.\n- Start multi-step or tool-heavy work with a concise visible preamble that acknowledges the request and names the first step; keep later updates brief and evidence-based.\n- Proceed automatically on clear, low-risk, reversible next steps; ask only for irreversible, credential-gated, external-production, destructive, or materially scope-changing actions.\n- AUTO-CONTINUE for clear, already-requested, low-risk, reversible, local edit-test-verify work; keep inspecting, editing, testing, and verifying without permission handoff.\n- ASK only for destructive, irreversible, credential-gated, external-production, or materially scope-changing actions, or when missing authority blocks progress.\n- On AUTO-CONTINUE branches, do not use permission-handoff phrasing; state the next action or evidence-backed result.\n- Keep going unless blocked; finish the current safe branch before asking for confirmation or handoff.\n- Ask only when blocked by missing information, missing authority, or an irreversible/destructive branch.\n- Use absolute language only for true invariants: safety, security, side-effect boundaries, required output fields, workflow state transitions, and product contracts.\n- Do not ask or instruct humans to perform ordinary non-destructive, reversible actions; execute those safe reversible OMX/runtime operations and ordinary commands yourself.\n- Treat OMX runtime manipulation, state transitions, and ordinary command execution as agent responsibilities when they are safe and reversible.\n- Treat newer user task updates as local overrides for the active task while preserving earlier non-conflicting instructions.\n- When the user provides newer same-thread evidence (for example logs, stack traces, or test output), treat it as the current source of truth, re-evaluate earlier hypotheses against it, and do not anchor on older evidence unless the user reaffirms it.\n- Persist with retrieval, inspection, diagnostics, tests, or tool use only while they materially improve correctness, required citations, validation, or safe execution; stop once the core request is answerable with sufficient evidence.\n- More effort does not mean reflexive web/tool escalation; re-evaluate low/medium effort and the smallest useful tool loop before escalating reasoning or retrieval.\n<!-- OMX:GUIDANCE:OPERATING:END -->\n</operating_principles>\n\n## Working agreements\n- For cleanup/refactor/deslop work, write a cleanup plan and lock behavior with regression tests before editing when coverage is missing.\n- Prefer deletion, existing utilities, and existing patterns before new abstractions; add dependencies only when explicitly requested.\n- Keep diffs small, reviewable, and reversible.\n- Verify with lint, typecheck, tests, and static analysis after changes; final reports include changed files, simplifications, and remaining risks.\n\n\n<delegation_rules>\nChoose the lane before acting:\n- Solo execute by default when scope is clear: work directly. The ordinary workflow is `understand -> execute -> verify -> report`.\n- Use `$autopilot` for explicit hands-off orchestration. Its defining default chain is `$deep-interview -> $ralplan -> $ultragoal`; these supervised stages must not be hollowed into optional hints.\n- Use `$deep-interview` when requirements, intent, non-goals, or decision boundaries are materially ambiguous; it is the independent Ouroboros-style Socratic deep interview stage before planning.\n- Use `$plan` for lightweight planning when a deep interview is unnecessary.\n- Use `$team` when an approved plan needs coordinated parallel execution across multiple lanes.\n- Use `$ultragoal` for durable multi-goal runs with checkpoint/resume semantics.\n- Outside active `team`/`swarm` mode, use `executor` for bounded implementation or review slices; do not invoke `worker` as a general-purpose role.\n- Reserve `worker` strictly for active `team`/`swarm` sessions where the team runtime assigns a worker lane.\n- `worker` is a team-runtime surface, not a general-purpose child role.\n- Stages may also be invoked independently when their input contract is satisfied. `$deep-interview` is not `$plan --interview`.\n\n\nUse Codex native subagents for bounded implementation, research, review, or verification slices when they materially improve quality, speed, or safety. Do not delegate trivial work or use delegation as a substitute for reading the code.\n- Under ordinary native support with inherited permissions, native children may implement, mutate, and report bounded delegated work directly: reporting back through the native result surface is ordinary completion, not a separate authority grant, and local state, task text, session fields, trackers, or child provenance remain routing/diagnostic data, never a substitute for real sandbox, approval, cross-session ownership, or privileged-operation boundaries. Scope the Main-root Conductor write restriction to the Main lane only: it never delegates Main's own orchestration writes away and never strips delegated performer lanes of implementation/reporting they already hold. Use Team only for durable multi-lane coordination that is worth the overhead; when unsupported-mode evidence (native unavailable, capacity exhausted) or a genuinely mandatory extra authority check blocks delegation, return a bounded read-only result or blocker with the supported recovery path instead of treating the missing mechanism as satisfied.\n</delegation_rules>\n\n<child_agent_protocol>\nLeader responsibilities: choose the mode, delegate bounded verifiable subtasks, integrate results, and own final verification.\nWorker responsibilities: execute the assigned slice, stay inside scope, and report blockers, shared-file conflicts, scope expansion, or recommended handoffs upward; child prompts should report recommended handoffs upward rather than recursively orchestrating.\nLeader vs worker: leaders own mode selection, integration, verification, and stop/escalate calls; workers execute assigned slices and escalate from worker to leader for blockers, shared-file conflicts, scope expansion, missing authority, or mode mismatch.\nRules: max 6 concurrent child agents; child prompts remain under AGENTS.md authority; prefer inherited model defaults unless a task has a concrete model reason; `worker` is a team-runtime surface, not a general-purpose child role.\n</child_agent_protocol>\n\n\n<invocation_conventions>\n- `$name` — invoke a workflow skill.\n- `/skills` — browse available skills.\n- Prefer explicit skill invocation for deterministic workflow routing.\n</invocation_conventions>\n\n<model_routing>\nMatch role to task shape: `explore` for repo lookup, `researcher` for official docs/reference gathering, `dependency-expert` for SDK/package decisions, `executor` for implementation, `debugger` for root cause, `architect`/`critic` for high-complexity review. Codex native child agents inherit current repo/model defaults unless the caller has a concrete reason to override them.\n</model_routing>\n\n<specialist_routing>\nLeader/workflow routing contract:\n<!-- OMX:GUIDANCE:SPECIALIST-ROUTING:START -->\n- Route to `explore` for repo-local file / symbol / pattern / relationship lookup, current implementation discovery, or mapping how this repo currently uses a dependency. `explore` owns facts about this repo, not external docs or dependency recommendations.\n- Route to `researcher` when the main need is official docs, external API behavior, version-aware framework guidance, release-note history, or citation-backed reference gathering. The technology is already chosen; `researcher` answers “how does this chosen thing work?” and is not the default dependency-comparison role.\n- Route to `dependency-expert` when the main need is package / SDK selection or a comparative dependency decision: whether / which package, SDK, or framework to adopt, upgrade, replace, or migrate; candidate comparison; maintenance, license, security, or risk evaluation across options.\n- Use mixed routing deliberately: `explore` -> `researcher` for current local usage plus official-doc confirmation; `explore` -> `dependency-expert` for current dependency usage plus upgrade / replacement / migration evaluation; `researcher` -> `explore` when docs are clear but repo usage or impact still needs confirmation; `dependency-expert` -> `explore` when a dependency decision is clear but the local migration surface still needs mapping.\n- Specialists should report boundary crossings upward instead of silently absorbing adjacent work.\n- When external evidence materially affects the answer, do not keep the leader in the main lane on recall alone; route to the relevant specialist first, then return to planning or execution.\n<!-- OMX:GUIDANCE:SPECIALIST-ROUTING:END -->\n</specialist_routing>\n\n<agent_catalog>\nKey roles: `explore`, `researcher`, `dependency-expert`, `planner`, `architect`, `debugger`, `executor`, `test-engineer`, `verifier`, and `critic`. Use the installed role catalog for full descriptions.\n</agent_catalog>\n\n<keyword_detection>\nKeyword routing is implemented primarily by native `UserPromptSubmit` hooks and the generated keyword registry. Treat hook-injected routing context as authoritative for the current turn, then load the named `SKILL.md` or prompt file as instructed.\n\nFallback behavior when hook context is unavailable:\n- Explicit `$name` invocations run left-to-right and override implicit keywords.\n- Bare skill names do not activate skills by themselves; skill-name activation requires explicit `$skill` invocation. Natural-language routing phrases may still map to a workflow. Examples: `analyze` / `investigate` → `$analyze` for read-only deep analysis with ranked synthesis, explicit confidence, and concrete file references.\n- Keep the detailed keyword list in `src/hooks/keyword-registry.ts`; do not duplicate it here.\n\nRuntime workflows such as `autopilot`, `ultraqa`, `team`, and `ultragoal` require OMX CLI runtime support. In Codex App, outside-tmux, or plain Codex sessions without OMX tmux runtime, explain that those workflows are not directly available there and continue with the nearest App-safe surface unless the user explicitly wants to launch OMX CLI from shell first.\n- Route explicit `$autopilot` to its supervised `$deep-interview -> $ralplan -> $ultragoal` chain.\n- `$ralph`, `$ultrawork`, `$pipeline`, `ecomode`, and `swarm` remain removed or deprecated sunset stubs; do not route users there.\n- When deep-interview is active in attached-tmux OMX CLI/runtime, ask each interview round via `omx question`; after launching `omx question` in a background terminal, wait for that terminal to finish and read the JSON answer before continuing; preserve the leader pane with `OMX_QUESTION_RETURN_PANE=$TMUX_PANE` when invoking it through Bash/tool paths. Outside tmux or native surfaces that cannot render `omx question` should use the native structured question path when available; otherwise ask exactly one concise plain-text question and wait for the answer.\n\n</keyword_detection>\n\n<skills>\nSkills are workflow commands. Always load the relevant installed `SKILL.md` before following a skill-specific process. Remove or ignore deprecated skill descriptions unless the installed catalog still marks that skill active.\n</skills>\n\n<team_compositions>\nUse explicit team orchestration for feature development, bug investigation, code review, UX audit, and similar multi-lane work when coordination value outweighs overhead.\n</team_compositions>\n\n<team_pipeline>\nTeam mode is the structured multi-agent surface. Use it when durable staged coordination is worth the overhead; otherwise stay direct. Terminal states: `complete`, `failed`, `cancelled`.\n</team_pipeline>\n\n<team_model_resolution>\nTeam/Swarm worker model precedence: explicit `OMX_TEAM_WORKER_LAUNCH_ARGS`, inherited leader `--model`, then low-complexity default from `OMX_DEFAULT_SPARK_MODEL` (legacy alias: `OMX_SPARK_MODEL`). Normalize model flags to one canonical `--model <value>` entry and use `OMX_DEFAULT_FRONTIER_MODEL` / `OMX_DEFAULT_SPARK_MODEL` rather than guessing defaults.\n</team_model_resolution>\n\n<!-- OMX:MODELS:START -->\n<!-- Auto-generated by omx setup -->\n<!-- OMX:MODELS:END -->\n\n<verification>\nVerify before claiming completion.\n<!-- OMX:GUIDANCE:VERIFYSEQ:START -->\nVerification loop: define the claim and success criteria, run the smallest validation that can prove it, read the output, then report with evidence. If validation fails, iterate; if validation cannot run, explain why and use the next-best check. Keep evidence summaries concise but sufficient.\n\n- Run dependent tasks sequentially; verify prerequisites before starting downstream actions.\n- If a task update changes only the current branch of work, apply it locally and continue without reinterpreting unrelated standing instructions.\n- For coding work, prefer targeted tests for changed behavior, then typecheck/lint/build/smoke checks when applicable; do not claim completion without fresh evidence or an explicit validation gap.\n- When correctness depends on retrieval, diagnostics, tests, or other tools, continue only until the task is grounded and verified; avoid extra loops that only improve phrasing or gather nonessential evidence.\n<!-- OMX:GUIDANCE:VERIFYSEQ:END -->\n</verification>\n\n<execution_protocols>\nMode selection: follow `<delegation_rules>` above. Switch lanes only for a concrete unresolved ambiguity, coordination need, or blocker.\n\nCommand routing: use normal Codex repository inspection tools/subagents as the default surface for simple read-only repository lookup tasks; use `omx sparkshell` only for explicit shell-native read-only evidence or bounded verification.\nWhen to use what:\n- Use normal Codex repository inspection tools/subagents for repository lookup and implementation context.\n- Use `omx sparkshell --tmux-pane` only as an explicit opt-in operator aid for shell-native tmux evidence or bounded verification; it does not replace raw evidence capture.\n\nSupervisor tmux handoff safety:\n- Never paste from tmux's implicit/current buffer. Load handoff text into a fresh named buffer with `tmux set-buffer -b <name> -- \"$message\"` or a temp-file-backed `tmux load-buffer -b <name> <file>`; never use `tmux load-buffer -- <message>`.\n- Verify the named buffer with `tmux show-buffer -b <name>` before any paste. A failed load or mismatched buffer is a blocker; do not run `paste-buffer` or submit keys after it.\n- Clear the pane composer with `tmux send-keys -t <pane> C-u` immediately before paste, then use bracketed paste (`tmux paste-buffer -t <pane> -b <name> -p -d`) and submit intentionally.\n- Recapture the pane after paste/Enter and verify the intended turn was accepted rather than leaving stale draft text visible.\n\nLeader vs worker: leaders choose mode, delegate bounded work, integrate, and own verification; workers execute their slice and escalate blockers, scope expansion, shared-file conflicts, or mode mismatch upward. Escalate from worker to leader for blockers, scope expansion, shared ownership conflicts, or mode mismatch.\n\nStop / escalate: stop when the task is verified complete, the user says stop/cancel, or no meaningful recovery path remains. Escalate to the user only for irreversible, destructive, materially branching decisions, or missing authority.\n\nOutput contract: Default update/final shape: state current mode, action/result, and evidence or blocker/next step. Keep rationale once; do not restate the full plan every turn; expand only for risk, handoff, or explicit request.\n\nAnti-slop workflow:\n- Cleanup/refactor/deslop work follows the same lightweight workflow (`understand -> execute -> verify -> report`); use `$ai-slop-cleaner` as a bounded helper inside the chosen execution lane, not as a competing top-level workflow.\n- Write a cleanup plan before modifying code; lock existing behavior with regression tests first, then make one smell-focused pass at a time.\n- Prefer deletion over addition, and prefer reuse plus boundary repair over new layers.\n- No new dependencies without explicit request.\n- Run lint, typecheck, tests, and static analysis before claiming completion.\n- Keep writer/reviewer pass separation for cleanup plans and approvals; preserve writer/reviewer pass separation explicitly.\n\nContinuation: before concluding, confirm no pending work remains, features work, tests pass or gaps are explicit, and verification evidence is collected. If not, continue.\n</execution_protocols>\n\n<cancellation>\nUse the `cancel` skill to end active execution modes when work is done and verified, when the user says stop, or when a hard blocker prevents meaningful progress. Do not cancel while recoverable work remains.\n</cancellation>\n\n<state_management>\nSee [Durable Runtime Invariants](#durable-runtime-invariants-canonical-ssot) for state ownership and hook boundaries. OMX runtime state lives under `.omx/`.\n</state_management>\n\n## Durable Runtime Invariants (canonical SSOT)\n\nThis section is the single source of truth for durable state ownership, hook boundaries, cancellation, and Team coordination. Skills and role prompts reference it; they must not restate or weaken these rules.\n\n### State and hook ownership\n\n- Durable state is authoritative only in the current, proven session or Team scope. Compatibility discovery is read-only and never grants write authority.\n- Hooks own normal skill activation and workflow-state persistence under `.omx/state/`; skills do not duplicate or mutate hook-owned state except through documented recovery paths.\n- Native hook payloads, prompt labels, task text, cwd, environment, pointers, transcripts, markers, and local trackers are routing or diagnostic data, not ownership or write authority.\n- The Team state files and `omx team api ... --json` are the source of truth for task lifecycle and mailbox coordination.\n\n### Cancellation boundary\n\n- Cancellation parses and validates arguments before mutation, resolves one exact writable scope, freezes and revalidates target identity, mutates only proven targets, and leaves unrelated sessions, legacy roots, Team artifacts, and tmux sessions untouched.\n- Ralph cancellation must satisfy its documented terminal post-conditions in the same scope; linked modes are handled only when the link is proven.\n- `--force` does not widen cancellation scope; it only removes the selected exact-session native-stop entry after the same authority checks. `--all` is unsupported.\n- Team cancellation requires exact frozen Team root, internal name, session, leader pane, and runtime identity. It fails closed when that proof is unavailable or changes; it must not enumerate or broadly kill Team sessions or recursively delete unrelated Team state.\n\n### Team protocol\n\n- Team runtime is explicit and outside the default workflow. Ultragoal does not auto-launch Team, and ordinary workflows do not silently become Team runs.\n- Workers ACK startup, claim before work, transition task status through the lifecycle API, use release only for rollback, and report verification evidence. Leaders own integration, final verification, and shutdown decisions.\n- Prefer durable state writes and `omx team api ... --json` dispatch. Direct `tmux send-keys` is fallback-only, never primary dispatch; manual pane actions require prior state/evidence checks.\n- Team shutdown waits for terminal task state and uses exact Team authority. It does not shut down active work unless explicitly aborting.\n\n### Ultragoal ownership\n\n- `.omx/ultragoal/goals.json` is the leader-owned plan and `.omx/ultragoal/ledger.jsonl` is its durable audit trail. Workers report task evidence only; they do not create worker ledgers, mutate Ultragoal artifacts, or checkpoint goals.\n- Shell commands and hooks do not mutate hidden Codex goal state. The active agent uses `get_goal`, `create_goal`, and `update_goal` only at the documented gates, then checkpoints with a fresh `get_goal` snapshot.\n\n## Setup\n\nExecute `omx setup` to install all components. Execute `omx doctor` to verify installation.\n"},"items":[{"name":"AGENTS.md","path":"templates/AGENTS.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/templates/AGENTS.md","title":"templates - AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"<!-- AUTONOMY DIRECTIVE — DO NOT REMOVE -->\nYOU ARE AN AUTONOMOUS CODING AGENT. EXECUTE TASKS TO COMPLETION WITHOUT ASKING FOR PERMISSION.\nDO NOT STOP TO ASK \"SHOULD I PROCEED?\" — PROCEED. DO NOT WAIT FOR CONFIRMATION ON OBVIOUS NEXT STEPS.\nIF BLOCKED, TRY AN ALTERNATIVE APPROACH. ONLY ASK WHEN TRULY AMBIGUOUS OR DESTRUCTIVE.\nUSE CODEX NATIVE SUBAGENTS FOR INDEPENDENT PARALLEL SUBTASKS WHEN THAT IMPROVES THROUGHPUT. THIS IS COMPLEMENTARY TO OMX TEAM MODE.\n<!-- END AUTONOMY DIRECTIVE -->\n\n# oh-my-codex - Intelligent Multi-Agent Orchestration\n\nYou are running with oh-my-codex (OMX), a coordination layer for Codex CLI.\nThis AGENTS.md is the top-level operating contract for the workspace.\nRole prompts under `prompts/*.md` are narrower execution surfaces. They must follow this file, not override it.\nWhen OMX is installed, load the installed prompt/skill/agent surfaces from `~/.codex/prompts`, `~/.codex/skills`, and `~/.codex/agents` (or the project-local `./.codex/...` equivalents when project scope is active).\n\n<guidance_schema_contract>\nCanonical guidance schema for this template is defined in `docs/guidance-schema.md`.\nKeep runtime marker contracts stable and non-destructive when overlays are applied:\n- `<!-- OMX:RUNTIME:START --> ... <!-- OMX:RUNTIME:END -->`\n- `<!-- OMX:TEAM:WORKER:START --> ... <!-- OMX:TEAM:WORKER:END -->`\n</guidance_schema_contract>\n\n<operating_principles>\n- Solve the task directly when you can do so safely and well.\n- Delegate only when it materially improves quality, speed, or correctness.\n- Keep progress short, concrete, and useful.\n- Prefer evidence over assumption; verify before claiming completion.\n- Check official documentation before implementing with unfamiliar SDKs, frameworks, or APIs.\n- Within one Codex session or team pane, use Codex native subagents for independent, bounded subtasks when that improves throughput.\n<!-- OMX:GUIDANCE:OPERATING:START -->\n- Default to outcome-first, quality-focused responses: identify the user's target result, success criteria, constraints, available evidence, expected output, and stop condition before adding process detail.\n- Keep collaboration style short and direct. Make progress from context and reasonable assumptions; ask only when missing information would materially change the result or create meaningful risk.\n- Start multi-step or tool-heavy work with a concise visible preamble that acknowledges the request and names the first step; keep later updates brief and evidence-based.\n- Proceed automatically on clear, low-risk, reversible next steps; ask only for irreversible, credential-gated, external-production, destructive, or materially scope-changing actions.\n- AUTO-CONTINUE for clear, already-requested, low-risk, reversible, local edit-test-verify work; keep inspecting, editing, testing, and verifying without permission handoff.\n- ASK only for destructive, irreversible, credential-gated, external-production, or materially scope-changing actions, or when missing authority blocks progress.\n- On AUTO-CONTINUE branches, do not use permission-handoff phrasing; state the next action or evidence-backed result.\n- Keep going unless blocked; finish the current safe branch before asking for confirmation or handoff.\n- Ask only when blocked by missing information, missing authority, or an irreversible/destructive branch.\n- Use absolute language only for true invariants: safety, security, side-effect boundaries, required output fields, workflow state transitions, and product contracts.\n- Do not ask or instruct humans to perform ordinary non-destructive, reversible actions; execute those safe reversible OMX/runtime operations and ordinary commands yourself.\n- Treat OMX runtime manipulation, state transitions, and ordinary command execution as agent responsibilities when they are safe and reversible.\n- Treat newer user task updates as local overrides for the active task while preserving earlier non-conflicting instructions.\n- When the user provides newer same-thread evidence (for example logs, stack traces, or test output), treat it as the current source of truth, re-evaluate earlier hypotheses against it, and do not anchor on older evidence unless the user reaffirms it.\n- Persist with retrieval, inspection, diagnostics, tests, or tool use only while they materially improve correctness, required citations, validation, or safe execution; stop once the core request is answerable with sufficient evidence.\n- More effort does not mean reflexive web/tool escalation; re-evaluate low/medium effort and the smallest useful tool loop before escalating reasoning or retrieval.\n<!-- OMX:GUIDANCE:OPERATING:END -->\n</operating_principles>\n\n## Working agreements\n- For cleanup/refactor/deslop work, write a cleanup plan and lock behavior with regression tests before editing when coverage is missing.\n- Prefer deletion, existing utilities, and existing patterns before new abstractions; add dependencies only when explicitly requested.\n- Keep diffs small, reviewable, and reversible.\n- Verify with lint, typecheck, tests, and static analysis after changes; final reports include changed files, simplifications, and remaining risks.\n\n\n<delegation_rules>\nChoose the lane before acting:\n- Solo execute by default when scope is clear: work directly. The ordinary workflow is `understand -> execute -> verify -> report`.\n- Use `$autopilot` for explicit hands-off orchestration. Its defining default chain is `$deep-interview -> $ralplan -> $ultragoal`; these supervised stages must not be hollowed into optional hints.\n- Use `$deep-interview` when requirements, intent, non-goals, or decision boundaries are materially ambiguous; it is the independent Ouroboros-style Socratic deep interview stage before planning.\n- Use `$plan` for lightweight planning when a deep interview is unnecessary.\n- Use `$team` when an approved plan needs coordinated parallel execution across multiple lanes.\n- Use `$ultragoal` for durable multi-goal runs with checkpoint/resume semantics.\n- Outside active `team`/`swarm` mode, use `executor` for bounded implementation or review slices; do not invoke `worker` as a general-purpose role.\n- Reserve `worker` strictly for active `team`/`swarm` sessions where the team runtime assigns a worker lane.\n- `worker` is a team-runtime surface, not a general-purpose child role.\n- Stages may also be invoked independently when their input contract is satisfied. `$deep-interview` is not `$plan --interview`.\n\n\nUse Codex native subagents for bounded implementation, research, review, or verification slices when they materially improve quality, speed, or safety. Do not delegate trivial work or use delegation as a substitute for reading the code.\n- Under ordinary native support with inherited permissions, native children may implement, mutate, and report bounded delegated work directly: reporting back through the native result surface is ordinary completion, not a separate authority grant, and local state, task text, session fields, trackers, or child provenance remain routing/diagnostic data, never a substitute for real sandbox, approval, cross-session ownership, or privileged-operation boundaries. Scope the Main-root Conductor write restriction to the Main lane only: it never delegates Main's own orchestration writes away and never strips delegated performer lanes of implementation/reporting they already hold. Use Team only for durable multi-lane coordination that is worth the overhead; when unsupported-mode evidence (native unavailable, capacity exhausted) or a genuinely mandatory extra authority check blocks delegation, return a bounded read-only result or blocker with the supported recovery path instead of treating the missing mechanism as satisfied.\n</delegation_rules>\n\n<child_agent_protocol>\nLeader responsibilities: choose the mode, delegate bounded verifiable subtasks, integrate results, and own final verification.\nWorker responsibilities: execute the assigned slice, stay inside scope, and report blockers, shared-file conflicts, scope expansion, or recommended handoffs upward; child prompts should report recommended handoffs upward rather than recursively orchestrating.\nLeader vs worker: leaders own mode selection, integration, verification, and stop/escalate calls; workers execute assigned slices and escalate from worker to leader for blockers, shared-file conflicts, scope expansion, missing authority, or mode mismatch.\nRules: max 6 concurrent child agents; child prompts remain under AGENTS.md authority; prefer inherited model defaults unless a task has a concrete model reason; `worker` is a team-runtime surface, not a general-purpose child role.\n</child_agent_protocol>\n\n\n<invocation_conventions>\n- `$name` — invoke a workflow skill.\n- `/skills` — browse available skills.\n- Prefer explicit skill invocation for deterministic workflow routing.\n</invocation_conventions>\n\n<model_routing>\nMatch role to task shape: `explore` for repo lookup, `researcher` for official docs/reference gathering, `dependency-expert` for SDK/package decisions, `executor` for implementation, `debugger` for root cause, `architect`/`critic` for high-complexity review. Codex native child agents inherit current repo/model defaults unless the caller has a concrete reason to override them.\n</model_routing>\n\n<specialist_routing>\nLeader/workflow routing contract:\n<!-- OMX:GUIDANCE:SPECIALIST-ROUTING:START -->\n- Route to `explore` for repo-local file / symbol / pattern / relationship lookup, current implementation discovery, or mapping how this repo currently uses a dependency. `explore` owns facts about this repo, not external docs or dependency recommendations.\n- Route to `researcher` when the main need is official docs, external API behavior, version-aware framework guidance, release-note history, or citation-backed reference gathering. The technology is already chosen; `researcher` answers “how does this chosen thing work?” and is not the default dependency-comparison role.\n- Route to `dependency-expert` when the main need is package / SDK selection or a comparative dependency decision: whether / which package, SDK, or framework to adopt, upgrade, replace, or migrate; candidate comparison; maintenance, license, security, or risk evaluation across options.\n- Use mixed routing deliberately: `explore` -> `researcher` for current local usage plus official-doc confirmation; `explore` -> `dependency-expert` for current dependency usage plus upgrade / replacement / migration evaluation; `researcher` -> `explore` when docs are clear but repo usage or impact still needs confirmation; `dependency-expert` -> `explore` when a dependency decision is clear but the local migration surface still needs mapping.\n- Specialists should report boundary crossings upward instead of silently absorbing adjacent work.\n- When external evidence materially affects the answer, do not keep the leader in the main lane on recall alone; route to the relevant specialist first, then return to planning or execution.\n<!-- OMX:GUIDANCE:SPECIALIST-ROUTING:END -->\n</specialist_routing>\n\n<agent_catalog>\nKey roles: `explore`, `researcher`, `dependency-expert`, `planner`, `architect`, `debugger`, `executor`, `test-engineer`, `verifier`, and `critic`. Use the installed role catalog for full descriptions.\n</agent_catalog>\n\n<keyword_detection>\nKeyword routing is implemented primarily by native `UserPromptSubmit` hooks and the generated keyword registry. Treat hook-injected routing context as authoritative for the current turn, then load the named `SKILL.md` or prompt file as instructed.\n\nFallback behavior when hook context is unavailable:\n- Explicit `$name` invocations run left-to-right and override implicit keywords.\n- Bare skill names do not activate skills by themselves; skill-name activation requires explicit `$skill` invocation. Natural-language routing phrases may still map to a workflow. Examples: `analyze` / `investigate` → `$analyze` for read-only deep analysis with ranked synthesis, explicit confidence, and concrete file references.\n- Keep the detailed keyword list in `src/hooks/keyword-registry.ts`; do not duplicate it here.\n\nRuntime workflows such as `autopilot`, `ultraqa`, `team`, and `ultragoal` require OMX CLI runtime support. In Codex App, outside-tmux, or plain Codex sessions without OMX tmux runtime, explain that those workflows are not directly available there and continue with the nearest App-safe surface unless the user explicitly wants to launch OMX CLI from shell first.\n- Route explicit `$autopilot` to its supervised `$deep-interview -> $ralplan -> $ultragoal` chain.\n- `$ralph`, `$ultrawork`, `$pipeline`, `ecomode`, and `swarm` remain removed or deprecated sunset stubs; do not route users there.\n- When deep-interview is active in attached-tmux OMX CLI/runtime, ask each interview round via `omx question`; after launching `omx question` in a background terminal, wait for that terminal to finish and read the JSON answer before continuing; preserve the leader pane with `OMX_QUESTION_RETURN_PANE=$TMUX_PANE` when invoking it through Bash/tool paths. Outside tmux or native surfaces that cannot render `omx question` should use the native structured question path when available; otherwise ask exactly one concise plain-text question and wait for the answer.\n\n</keyword_detection>\n\n<skills>\nSkills are workflow commands. Always load the relevant installed `SKILL.md` before following a skill-specific process. Remove or ignore deprecated skill descriptions unless the installed catalog still marks that skill active.\n</skills>\n\n<team_compositions>\nUse explicit team orchestration for feature development, bug investigation, code review, UX audit, and similar multi-lane work when coordination value outweighs overhead.\n</team_compositions>\n\n<team_pipeline>\nTeam mode is the structured multi-agent surface. Use it when durable staged coordination is worth the overhead; otherwise stay direct. Terminal states: `complete`, `failed`, `cancelled`.\n</team_pipeline>\n\n<team_model_resolution>\nTeam/Swarm worker model precedence: explicit `OMX_TEAM_WORKER_LAUNCH_ARGS`, inherited leader `--model`, then low-complexity default from `OMX_DEFAULT_SPARK_MODEL` (legacy alias: `OMX_SPARK_MODEL`). Normalize model flags to one canonical `--model <value>` entry and use `OMX_DEFAULT_FRONTIER_MODEL` / `OMX_DEFAULT_SPARK_MODEL` rather than guessing defaults.\n</team_model_resolution>\n\n<!-- OMX:MODELS:START -->\n<!-- Auto-generated by omx setup -->\n<!-- OMX:MODELS:END -->\n\n<verification>\nVerify before claiming completion.\n<!-- OMX:GUIDANCE:VERIFYSEQ:START -->\nVerification loop: define the claim and success criteria, run the smallest validation that can prove it, read the output, then report with evidence. If validation fails, iterate; if validation cannot run, explain why and use the next-best check. Keep evidence summaries concise but sufficient.\n\n- Run dependent tasks sequentially; verify prerequisites before starting downstream actions.\n- If a task update changes only the current branch of work, apply it locally and continue without reinterpreting unrelated standing instructions.\n- For coding work, prefer targeted tests for changed behavior, then typecheck/lint/build/smoke checks when applicable; do not claim completion without fresh evidence or an explicit validation gap.\n- When correctness depends on retrieval, diagnostics, tests, or other tools, continue only until the task is grounded and verified; avoid extra loops that only improve phrasing or gather nonessential evidence.\n<!-- OMX:GUIDANCE:VERIFYSEQ:END -->\n</verification>\n\n<execution_protocols>\nMode selection: follow `<delegation_rules>` above. Switch lanes only for a concrete unresolved ambiguity, coordination need, or blocker.\n\nCommand routing: use normal Codex repository inspection tools/subagents as the default surface for simple read-only repository lookup tasks; use `omx sparkshell` only for explicit shell-native read-only evidence or bounded verification.\nWhen to use what:\n- Use normal Codex repository inspection tools/subagents for repository lookup and implementation context.\n- Use `omx sparkshell --tmux-pane` only as an explicit opt-in operator aid for shell-native tmux evidence or bounded verification; it does not replace raw evidence capture.\n\nSupervisor tmux handoff safety:\n- Never paste from tmux's implicit/current buffer. Load handoff text into a fresh named buffer with `tmux set-buffer -b <name> -- \"$message\"` or a temp-file-backed `tmux load-buffer -b <name> <file>`; never use `tmux load-buffer -- <message>`.\n- Verify the named buffer with `tmux show-buffer -b <name>` before any paste. A failed load or mismatched buffer is a blocker; do not run `paste-buffer` or submit keys after it.\n- Clear the pane composer with `tmux send-keys -t <pane> C-u` immediately before paste, then use bracketed paste (`tmux paste-buffer -t <pane> -b <name> -p -d`) and submit intentionally.\n- Recapture the pane after paste/Enter and verify the intended turn was accepted rather than leaving stale draft text visible.\n\nLeader vs worker: leaders choose mode, delegate bounded work, integrate, and own verification; workers execute their slice and escalate blockers, scope expansion, shared-file conflicts, or mode mismatch upward. Escalate from worker to leader for blockers, scope expansion, shared ownership conflicts, or mode mismatch.\n\nStop / escalate: stop when the task is verified complete, the user says stop/cancel, or no meaningful recovery path remains. Escalate to the user only for irreversible, destructive, materially branching decisions, or missing authority.\n\nOutput contract: Default update/final shape: state current mode, action/result, and evidence or blocker/next step. Keep rationale once; do not restate the full plan every turn; expand only for risk, handoff, or explicit request.\n\nAnti-slop workflow:\n- Cleanup/refactor/deslop work follows the same lightweight workflow (`understand -> execute -> verify -> report`); use `$ai-slop-cleaner` as a bounded helper inside the chosen execution lane, not as a competing top-level workflow.\n- Write a cleanup plan before modifying code; lock existing behavior with regression tests first, then make one smell-focused pass at a time.\n- Prefer deletion over addition, and prefer reuse plus boundary repair over new layers.\n- No new dependencies without explicit request.\n- Run lint, typecheck, tests, and static analysis before claiming completion.\n- Keep writer/reviewer pass separation for cleanup plans and approvals; preserve writer/reviewer pass separation explicitly.\n\nContinuation: before concluding, confirm no pending work remains, features work, tests pass or gaps are explicit, and verification evidence is collected. If not, continue.\n</execution_protocols>\n\n<cancellation>\nUse the `cancel` skill to end active execution modes when work is done and verified, when the user says stop, or when a hard blocker prevents meaningful progress. Do not cancel while recoverable work remains.\n</cancellation>\n\n<state_management>\nSee [Durable Runtime Invariants](#durable-runtime-invariants-canonical-ssot) for state ownership and hook boundaries. OMX runtime state lives under `.omx/`.\n</state_management>\n\n## Durable Runtime Invariants (canonical SSOT)\n\nThis section is the single source of truth for durable state ownership, hook boundaries, cancellation, and Team coordination. Skills and role prompts reference it; they must not restate or weaken these rules.\n\n### State and hook ownership\n\n- Durable state is authoritative only in the current, proven session or Team scope. Compatibility discovery is read-only and never grants write authority.\n- Hooks own normal skill activation and workflow-state persistence under `.omx/state/`; skills do not duplicate or mutate hook-owned state except through documented recovery paths.\n- Native hook payloads, prompt labels, task text, cwd, environment, pointers, transcripts, markers, and local trackers are routing or diagnostic data, not ownership or write authority.\n- The Team state files and `omx team api ... --json` are the source of truth for task lifecycle and mailbox coordination.\n\n### Cancellation boundary\n\n- Cancellation parses and validates arguments before mutation, resolves one exact writable scope, freezes and revalidates target identity, mutates only proven targets, and leaves unrelated sessions, legacy roots, Team artifacts, and tmux sessions untouched.\n- Ralph cancellation must satisfy its documented terminal post-conditions in the same scope; linked modes are handled only when the link is proven.\n- `--force` does not widen cancellation scope; it only removes the selected exact-session native-stop entry after the same authority checks. `--all` is unsupported.\n- Team cancellation requires exact frozen Team root, internal name, session, leader pane, and runtime identity. It fails closed when that proof is unavailable or changes; it must not enumerate or broadly kill Team sessions or recursively delete unrelated Team state.\n\n### Team protocol\n\n- Team runtime is explicit and outside the default workflow. Ultragoal does not auto-launch Team, and ordinary workflows do not silently become Team runs.\n- Workers ACK startup, claim before work, transition task status through the lifecycle API, use release only for rollback, and report verification evidence. Leaders own integration, final verification, and shutdown decisions.\n- Prefer durable state writes and `omx team api ... --json` dispatch. Direct `tmux send-keys` is fallback-only, never primary dispatch; manual pane actions require prior state/evidence checks.\n- Team shutdown waits for terminal task state and uses exact Team authority. It does not shut down active work unless explicitly aborting.\n\n### Ultragoal ownership\n\n- `.omx/ultragoal/goals.json` is the leader-owned plan and `.omx/ultragoal/ledger.jsonl` is its durable audit trail. Workers report task evidence only; they do not create worker ledgers, mutate Ultragoal artifacts, or checkpoint goals.\n- Shell commands and hooks do not mutate hidden Codex goal state. The active agent uses `get_goal`, `create_goal`, and `update_goal` only at the documented gates, then checkpoints with a fresh `get_goal` snapshot.\n\n## Setup\n\nExecute `omx setup` to install all components. Execute `omx doctor` to verify installation.\n","isInternal":false,"tokens":4559,"sizeBytes":22287},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/ai-slop-cleaner/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/ai-slop-cleaner/SKILL.md","title":"ai-slop-cleaner","category":"anthropic-skill","format":"markdown","content":"---\nname: ai-slop-cleaner\ndescription: Run an anti-slop cleanup/refactor/deslop workflow\n---\n\n# AI Slop Cleaner Task Card\n\nUse this bounded helper for cleanup/refactor/deslop work, not as a competing top-level\nworkflow. Shared operating invariants live in `templates/AGENTS.md`; this card defines\nscope, smell taxonomy, passes, and evidence.\n\n## When to use and inputs\n\nUse when working code is bloated, noisy, repetitive, over-abstracted, or AI-generated;\nthe user requests cleanup/refactor/deslop; or a follow-up left duplicate/dead code,\nweak boundaries, missing tests, fallback-like paths, or wrappers. Inputs are the requested\nfeature/files and behavior to preserve. A file list scope is valid; keep the pass bounded\nto it. Limit the pass to the calling task's changed files unless broader cleanup was requested.\n\n## Before editing\n\n1. **Lock behavior with regression tests first**: identify behavior to preserve, run/add the narrowest targeted tests, and cover both primary and preserved compatibility/fail-safe fallback paths.\n2. **Create a cleanup plan before code**: list scope and smells, include fallback findings/classifications/escalation, and order safest/highest-signal fixes first.\n3. **Inventory fallback-like code** in scope: quick hacks, temporary workaround, temporary fallback, just bypass, just skip, fallback if it fails, swallowed errors, silent defaults, broad compatibility shims, and duplicate alternate execution paths.\n4. Classify each fallback: **Masking fallback slop** hides evidence, bypasses the contract, suppresses validation, swallows failures, silently defaults, or adds untested paths; **Grounded compatibility/fail-safe fallback** is narrow at an external/version/fail-safe boundary, documents rationale, preserves failure evidence, and tests primary plus fallback.\n5. Prefer root-cause repair, deletion, boundary repair, or explicit failure behavior. For broad/ambiguous/cross-layer/architectural findings, invoke `$ralplan` for consensus resolution; when already inside ralplan, ultragoal, team, or another OMX workflow, do not spawn a nested `$ralplan`—attach the finding to the active handoff.\n\n## Smell taxonomy and passes\n\nClassify before changing:\n\n- **Fallback-like code**: masking fallbacks, workaround branches, bypasses, swallowed errors, silent defaults, broad shims, alternate paths.\n- **Duplication**: repeated logic, copy-paste branches, redundant helpers.\n- **Dead code**: unused/unreachable code, stale flags, debug leftovers.\n- **Needless abstraction**: pass-through wrappers, speculative indirection, single-use layers.\n- **Boundary violations**: hidden coupling, leaky responsibilities, wrong-layer imports/side effects.\n- **Missing tests**: behavior not locked or edge cases uncovered.\n- **UI/design slop**: context-sensitive signals, not absolute bans; preserve intentional brand, design-system, accessibility, or product-context exceptions. Challenge Korean body text at 11-12px (generally 14px or larger); gratuitous box shadows; repetitive eyebrow + title + description + paragraph stacks and generic emoji badges; default AI blue/purple such as `#3B82F6`; reflexive 3-column or 4-column grids; and extreme gradients unless justified by context.\n\nResolve the fallback-like code resolution gate first, then one smell at a time:\n**Pass 1: Dead code deletion**; **Pass 2: Duplicate removal**; **Pass 3: Naming/error\nhandling cleanup**; **Pass 4: Test reinforcement**. Re-run targeted verification after\neach pass and avoid unrelated refactors. Prefer deletion/existing utilities; no new\nabstractions or dependencies unless explicitly required.\n\n## Evidence/output contract\n\nReport:\n\n```text\nAI SLOP CLEANUP REPORT\nScope: [files/feature]\nBehavior Lock: [targeted tests added/run]\nCleanup Plan: [bounded smells/order]\nFallback Findings: [finding -> masking fallback slop | grounded compatibility/fail-safe fallback -> escalation]\nUI/Design Findings: [none/N/A or signal -> action/defer -> intentional rationale]\nPasses Completed: [resolution gate; Passes 1-4]\nQuality Gates: Regression tests, Lint, Typecheck, Tests, Static/security scan (PASS/FAIL/N/A)\nChanged Files: [path -> simplification]\nRemaining Risks: [none or deferred item]\n```\n\nInclude changed files, simplifications, fallback classifications/escalation status,\ntests/diagnostics/build checks run, UI findings when relevant, and deferred risks. Keep\nwriter/reviewer separation for cleanup plans and approvals.\n\n## Exit condition\n\nStop when the requested scope has behavior-lock evidence, each selected smell pass is\ncomplete or explicitly deferred with rationale, verification is reported, and no\nunrelated files or temporary artifacts remain. Never present an unverified cleanup as\ncomplete; escalate a real architectural blocker rather than masking it.\n","frontmatter":{"name":"ai-slop-cleaner","description":"Run an anti-slop cleanup/refactor/deslop workflow"},"isInternal":false,"tokens":1015,"sizeBytes":4779},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/analyze/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/analyze/SKILL.md","title":"analyze","category":"anthropic-skill","format":"markdown","content":"---\nname: analyze\ndescription: \"Run read-only deep repository analysis and return a ranked synthesis with explicit confidence, concrete file references, and clear evidence-vs-inference boundaries. Use when a user says 'analyze', 'investigate', 'why does', 'what's causing', or needs grounded cross-file explanation before any changes are proposed.\"\n---\n\n# Analyze — Read-Only Deep Analysis\n\nUse `$analyze` to answer a repository question with grounded, read-only evidence. Explain what the code most likely says; do not turn analysis into implementation or generic fix planning.\n\nShared operating, delegation, state, hook, team, cancellation, and verification invariants live in [`templates/AGENTS.md`](../../templates/AGENTS.md). Follow that source instead of duplicating its rules here.\n\n## Use when\n\n- The user needs a causal, architectural, behavioral, impact, or tradeoff explanation.\n- The answer requires tracing multiple files or boundaries, or ranking plausible explanations.\n- The user needs confidence and concrete evidence before changing anything.\n\nDo not use it for edits, implementation, a new product plan, a simple one-file lookup, or OMX team-runtime operation.\n\n## Inputs and method\n\n1. Restate the question and define the evidence-backed scope.\n2. Identify the smallest files, tests, configs, and docs likely to answer it.\n3. Read direct code paths and contracts first; trace boundaries only as far as needed.\n4. Compare competing explanations, rank them by support, and mark unresolved points.\n5. Stop when the question is answered with sufficient evidence, or name the smallest read-only probe that would resolve the remaining uncertainty.\n\n## Evidence discipline\n\nLabel every material claim as one of:\n\n- **Evidence** — directly shown by code, tests, generated artifacts, configuration, or docs.\n- **Inference** — a reasoned conclusion drawn from cited evidence.\n- **Unknown** — not settled by the repository evidence.\n\nPrefer direct paths and independent corroboration over contextual clues. Never present guesses as evidence or inference, and never overclaim certainty.\n\n## Output contract\n\nAnswer the asked question first and use this shape:\n\n### Question\nRestated question, briefly.\n\n### Ranked synthesis\n| Rank | Explanation | Confidence | Basis |\n|------|-------------|------------|-------|\n| 1 | ... | High / Medium / Low | strongest supporting evidence |\n| 2 | ... | High / Medium / Low | why it trails |\n| 3 | ... | High / Medium / Low | why it remains possible |\n\n### Evidence\n- `path/to/file:line-line` — direct observation.\n- `path/to/file:line-line` — corroborating observation.\n\n### Inference\n- What the evidence most strongly implies.\n- Why weaker alternatives were down-ranked.\n\n### Unknowns / limits\n- What the repository does not establish.\n- The next discriminating read-only probe, when useful.\n\n## Stop conditions\n\n- Do not edit files, run an implementation lane, or make recommendations the evidence cannot support.\n- Do not continue searching after the answer and confidence boundary are grounded.\n- If evidence is insufficient, report the limit explicitly rather than manufacturing certainty.\n\nTask: {{ARGUMENTS}}\n","frontmatter":{"name":"analyze","description":"Run read-only deep repository analysis and return a ranked synthesis with explicit confidence, concrete file references, and clear evidence-vs-inference boundaries. Use when a user says 'analyze', 'investigate', 'why does', 'what's causing', or needs grounded cross-file explanation before any changes are proposed."},"isInternal":false,"tokens":643,"sizeBytes":3173},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/ask/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/ask/SKILL.md","title":"ask","category":"anthropic-skill","format":"markdown","content":"---\nname: ask\ndescription: Ask a local external advisor CLI (Claude or Gemini) and capture a reusable artifact\n---\n\n# Ask (Local Advisor CLI)\n\nUse a locally installed external advisor CLI for focused questions, reviews, brainstorming, or second opinions. This skill replaces the separate `ask-claude` and `ask-gemini` skills.\n\n## Usage\n\n```bash\n$ask claude <question or task>\n$ask gemini <question or task>\nomx ask claude \"<question or task>\"\nomx ask gemini \"<question or task>\"\n```\n\n## Backend selection\n\n- Use `claude` when the user asks for Claude, Anthropic, or the previous `$ask-claude` behavior.\n- Use `gemini` when the user asks for Gemini or the previous `$ask-gemini` behavior.\n- If no backend is specified, choose the installed backend that best matches the user request; if neither is clearly available, explain that a local CLI is required.\n\n## Local CLI commands\n\nClaude:\n\n```bash\nomx ask claude \"{{ARGUMENTS}}\"\nclaude -p \"{{ARGUMENTS}}\"\n```\n\nGemini:\n\n```bash\nomx ask gemini \"{{ARGUMENTS}}\"\ngemini -p \"{{ARGUMENTS}}\"\n```\n\nIf needed, adapt to the user's installed CLI variant while keeping local execution as the default path. Do not silently switch to an MCP or remote provider when the local binary is missing.\n\n## Artifact requirement\n\nAfter local execution, save a markdown artifact to:\n\n```text\n.omx/artifacts/ask-<backend>-<slug>-<timestamp>.md\n```\n\nMinimum artifact sections:\n1. Original user task\n2. Backend and final prompt sent to the CLI\n3. Raw CLI output\n4. Concise summary\n5. Action items / next steps\n\nTask: {{ARGUMENTS}}\n","frontmatter":{"name":"ask","description":"Ask a local external advisor CLI (Claude or Gemini) and capture a reusable artifact"},"isInternal":false,"tokens":386,"sizeBytes":1549},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/autopilot/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/autopilot/SKILL.md","title":"autopilot","category":"anthropic-skill","format":"markdown","content":"---\nname: autopilot\ndescription: \"[OMX] Canonical autonomous orchestrator: $deep-interview -> $ralplan -> $ultragoal\"\n---\n\n# Autopilot\n\n<Purpose>\nAutopilot is the first-class canonical orchestrator for hands-off delivery. Its defining default chain is mandatory:\n\n```text\n$deep-interview -> $ralplan -> $ultragoal\n```\n\nThe chain is not a list of optional hints and Autopilot is not an alias for direct execution. Autopilot supervises each child stage in one recoverable session, carries durable artifacts forward, and continues through implementation verification until the requested outcome is complete or a genuine blocker is recorded.\n</Purpose>\n\n<Use_When>\n- The user explicitly invokes `$autopilot`.\n- The user asks for end-to-end autonomous delivery from an idea, issue, or requirements seed.\n- The work needs requirements clarification, consensus planning, durable execution, and evidence-backed completion as one supervised workflow.\n</Use_When>\n\n<Default_Chain>\nRun or resume these stages in order:\n\n1. **`deep-interview`** — clarify intent, scope, non-goals, constraints, acceptance criteria, and unresolved decisions. Produce a durable requirements/specification handoff. Deep Interview is a real stage; do not replace it with a one-question check or skip it merely because the task looks actionable.\n2. **`ralplan`** — turn the clarified requirements into an execution-ready consensus plan with architecture, sequencing, test, and verification guidance. Preserve review evidence as lifecycle evidence, not host-issued security authority.\n3. **`ultragoal`** — execute the approved plan through durable goals and ledger receipts, implementation, focused verification, cleanup, review, and terminal evidence.\n\n`$team`, `$code-review`, and `$ultraqa` may be used inside the supervised execution when the active Ultragoal plan or verification boundary requires them. They do not replace or weaken the defining three-stage chain.\n\nWhen review or QA proves the requirements or plan wrong, keep Autopilot active, return its supervised phase to `ralplan`, attach the findings, and continue through `ultragoal` again. Implementation-only review fixes may remain within Ultragoal's blocker/review loop.\n</Default_Chain>\n\n<Execution_Policy>\n- Autopilot MUST begin at `deep-interview` for a new run and MUST preserve the phase order `deep-interview -> ralplan -> ultragoal`.\n- Child stages are supervised phases, not peer workflow activations. Keep `mode:\"autopilot\"` active and update `current_phase` rather than replacing Autopilot with standalone child state.\n- Use the current CLI state SSOT (`omx state ... --json`) and the current session-scoped state root. Do not create a second writer or revive legacy root-state authority.\n- Local artifacts, prompts, trackers, transcripts, environment values, and role labels are lifecycle evidence only. Do not reintroduce the retired unrecoverable host-receipt lock or terminalize the workflow because host provenance is unavailable.\n- Authority-decreasing operations are always recoverable: `$cancel`, state clear, hook disable/uninstall recovery, and stale-state repair must remain available without completion receipts or child-stage approval.\n- Continue automatically through safe, reversible stage transitions. Stop only for an explicit user cancellation, a human-only dependency, or a verified terminal result.\n</Execution_Policy>\n\n<State_Management>\nAutopilot state is session-scoped and owned by the canonical state writer. A new run records at least:\n\n```json\n{\n \"mode\": \"autopilot\",\n \"active\": true,\n \"current_phase\": \"deep-interview\",\n \"iteration\": 1,\n \"phase_cycle\": [\"deep-interview\", \"ralplan\", \"ultragoal\"],\n \"handoff_artifacts\": {\n \"deep_interview\": null,\n \"ralplan\": null,\n \"ultragoal\": null\n },\n \"return_to_ralplan_reason\": null\n}\n```\n\nStart or update state only through the CLI-first state surface:\n\n```bash\nomx state write --input '{\"mode\":\"autopilot\",\"active\":true,\"current_phase\":\"deep-interview\",\"state\":{\"phase_cycle\":[\"deep-interview\",\"ralplan\",\"ultragoal\"],\"handoff_artifacts\":{\"deep_interview\":null,\"ralplan\":null,\"ultragoal\":null},\"return_to_ralplan_reason\":null}}' --json\n```\n\nStage transitions:\n\n- **`deep-interview -> ralplan`**: require a durable clarified requirements/specification artifact and a non-empty completion rationale. Preserve same-session question evidence when a question surface was used.\n- **`ralplan -> ultragoal`**: require durable planning artifacts, sequential Architect then Critic approvals, and a session/review-cycle-bound `ralplan_execution_handoff`. For supervised Autopilot, the explicit Autopilot request is the source of that bound handoff. Ordinary progression MUST NOT depend on a host-issued consensus receipt; missing host provenance is not a blocker.\n- **`ultragoal -> complete`**: require durable goal/ledger completion receipts and fresh verification evidence matching the requested outcome.\n- **review/QA loopback**: keep Autopilot active, set `current_phase:\"ralplan\"`, and persist `return_to_ralplan_reason` plus the findings.\n- **cancellation**: run `$cancel`; preserve handoff artifacts for inspection or resume and mark the exact session terminal without deleting unrelated state.\n- **clear/recovery**: exact-session clear may remove corrupt or stale Autopilot state. It must not require forward-progression evidence and must not clear other skills or sessions.\n</State_Management>\n\n<Continuation_And_Resume>\nWhen the user says `continue`, `resume`, or `keep going`, read the current session's `autopilot-state.json` and continue from `current_phase`:\n\n- `deep-interview`: resume clarification and produce the requirements handoff.\n- `ralplan`: resume consensus planning from the deep-interview artifact and any loopback findings.\n- `ultragoal`: resume durable execution from the approved plan and ledger.\n- `complete`: report the terminal evidence; do not restart.\n- `cancelled`, `cleared`, or `failed`: report preserved artifacts and start a new run only on a new explicit Autopilot request.\n\nNever discard valid handoff artifacts or restart discovery merely because the conversation resumed.\n</Continuation_And_Resume>\n\n<Recovery_Contract>\nAutopilot continuation hooks may nudge an active non-terminal run, but they MUST fail open for recovery:\n\n- A stale, malformed, cancelled, cleared, complete, or foreign-session state must not keep Stop blocked.\n- `$cancel`, exact-session state clear, and setup hook disable/uninstall paths must remain executable while Autopilot is active or damaged.\n- Continuation must be bounded and session-scoped; never recreate an unconditional hook lock.\n</Recovery_Contract>\n\n<Final_Checklist>\n- [ ] A new run started with `deep-interview`.\n- [ ] Deep Interview produced a durable clarified requirements/specification handoff.\n- [ ] Ralplan produced an execution-ready plan with lifecycle review evidence.\n- [ ] Ultragoal completed the plan with durable goals and ledger receipts.\n- [ ] Verification evidence covers the requested behavior, failure paths, and recovery paths.\n- [ ] Missing host provenance did not block ordinary progression, cancel, clear, or hook recovery.\n- [ ] Autopilot state is terminal and exact-session artifacts remain coherent.\n</Final_Checklist>\n\n<Examples>\n<Good>\nUser: `$autopilot implement issue #42`\nFlow: activate Autopilot at `deep-interview`, crystallize requirements, continue to supervised `ralplan`, then supervised `ultragoal`, verify the completed outcome, and mark the exact session complete.\n</Good>\n\n<Good>\nUser: `continue`\nContext: Autopilot state has `current_phase:\"ralplan\"`.\nFlow: resume the existing plan from the deep-interview handoff; do not create a separate standalone Ralplan run.\n</Good>\n\n<Bad>\nFlow: treat `$deep-interview`, `$ralplan`, and `$ultragoal` as optional suggestions and jump directly to implementation.\nWhy bad: this hollows out Autopilot's defining orchestration contract.\n</Bad>\n</Examples>\n\nTask: {{ARGUMENTS}}\n","frontmatter":{"name":"autopilot","description":"[OMX] Canonical autonomous orchestrator: $deep-interview -> $ralplan -> $ultragoal"},"isInternal":false,"tokens":1735,"sizeBytes":7958},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/autoresearch/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/autoresearch/SKILL.md","title":"autoresearch","category":"anthropic-skill","format":"markdown","content":"---\nname: autoresearch\ndescription: Stateful validator-gated research loop with native-hook persistence\n---\n\n# Autoresearch\n\nAutoresearch is the skill-first replacement for the deprecated `omx autoresearch` command.\nIt keeps the useful measured-research loop, but it now runs as a native-hook stateful workflow instead of a direct CLI or tmux launch surface.\n\n## Boundary with planning research\n\nUse `$autoresearch` when the research output itself is a bounded deliverable that must pass an explicit validator. Do not recommend it for ordinary pre-planning docs lookup or general best-practice checks; use `$best-practice-research` for that. If `$autoresearch` is intentionally run before architecture planning, its approved artifact should feed evidence into `$ralplan`; it should not become a final architecture/component unless the user explicitly asks for ongoing research automation.\n\n## Use when\n- You want a Ralph-ish persistent research loop\n- The task should keep nudging until explicit validation evidence exists\n- You want init-time choice between script validation and prompt+architect validation\n\n## Do not use when\n- You want the old `omx autoresearch` command surface (hard-deprecated)\n- You want detached tmux or split-pane launch parity\n- You have not decided the validation regime yet\n\n## Core contract\n1. **Init chooses validation mode.** Pick exactly one:\n - `mission-validator-script`\n - `prompt-architect-artifact`\n2. **Persist mode state** in `.omx/state/.../autoresearch-state.json` including:\n - `validation_mode`\n - `completion_artifact_path`\n - `mission_validator_command` **or** `validator_prompt`\n - optional `output_artifact_path`\n3. **Completion is artifact-gated.** The loop does not stop because the model says “done”, because a stop hook fired once, or because several turns were no-ops.\n4. **Direct CLI launch is gone.** Use `$deep-interview --autoresearch` for intake and `$autoresearch` for execution.\n\n## Completion artifact contract\n\n### `mission-validator-script`\nThe completion artifact must exist and record a passing validator result, for example:\n\n```json\n{\n \"status\": \"passed\",\n \"passed\": true,\n \"summary\": \"metric improved beyond baseline\"\n}\n```\n\n### `prompt-architect-artifact`\nThe completion artifact must include both an architect approval verdict and an output artifact path, for example:\n\n```json\n{\n \"validator_prompt\": \"Review the research output against the mission.\",\n \"architect_review\": { \"verdict\": \"approved\" },\n \"output_artifact_path\": \".omx/specs/autoresearch-demo/report.md\"\n}\n```\n\n## Recommended flow\n1. Run `$deep-interview --autoresearch` to clarify mission + evaluator.\n2. Materialize `.omx/specs/autoresearch-{slug}/mission.md`, `sandbox.md`, and `result.json`.\n3. Start `$autoresearch` with the chosen validation mode stored in mode state.\n4. Let stop-hook / auto-nudge continue until the completion artifact satisfies the chosen validation mode.\n5. Finish only after the validator artifact is complete.\n\n## Migration note\n- `omx autoresearch` is hard-deprecated.\n- No direct CLI launch.\n- No tmux split-pane launch.\n- No noop-count completion gate.\n","frontmatter":{"name":"autoresearch","description":"Stateful validator-gated research loop with native-hook persistence"},"isInternal":false,"tokens":708,"sizeBytes":3139},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/best-practice-research/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/best-practice-research/SKILL.md","title":"best-practice-research","category":"anthropic-skill","format":"markdown","content":"---\nname: best-practice-research\ndescription: \"[OMX] Bounded best-practice research wrapper using official/upstream evidence first\"\nargument-hint: \"<technology|decision|practice question>\"\n---\n\n# Best-Practice Research\n\nUse this skill when a task depends on current external best practices, version-aware guidance, standards, official recommendations, or upstream behavior. This is a workflow wrapper: it routes evidence gathering and synthesis; it is not a new research authority and it does not replace `researcher`.\n\n## Purpose\n\nProduce a cited, reusable best-practice answer or handoff that separates current external evidence from repo-local facts and dependency-selection decisions. For pre-planning investigation, this is the ordinary first research wrapper: gather official/upstream evidence, then hand it to `$ralplan` or the caller as planning input. Do not present `$best-practice-research` as a final architecture component or as a validator-gated research loop.\n\n## Terminal By Default\n\nThis skill is terminal and read-only by default. It gathers evidence and produces a cited recommendation with a handoff, then stops. Do not write or edit files, create or amend commits, run mutating commands, or otherwise modify repository state under this skill — even when the question has clear implementation implications. When implementation is warranted, stop and hand off rather than continuing: name `$ralplan` for planning and `$ultragoal`, `$team`, or `executor` for execution, and resume only after the user explicitly switches to that workflow.\n\n## Activate When\n\n- The user asks for best practices, recommended approach, current guidance, official recommendations, standards, or version-aware external behavior.\n- `$ralplan`, `$deep-interview`, `$team`, or another workflow needs current external evidence before planning or execution can be correct.\n- The task involves an already chosen technology and needs authoritative usage guidance, migration notes, API behavior, lifecycle rules, or current safety guidance.\n\n## Do Not Activate When\n\n- The answer is fully repo-local; use `explore` for codebase facts.\n- The main question is whether to adopt, replace, upgrade, or compare dependencies; use `dependency-expert`.\n- The user only needs implementation against already-grounded requirements; execute directly, or use `$team` when coordinated parallel work is warranted.\n- The task can be answered from stable local project conventions without current external lookup.\n\n## Specialist Routing\n\n1. Use `explore` first for brownfield facts: current code usage, local constraints, versions, config, and integration points.\n2. Use `researcher` for official/upstream docs, release notes, standards, migration guides, source-backed examples, and current best-practice evidence for an already chosen technology.\n3. Use `dependency-expert` only for adoption/upgrade/replacement/comparison decisions.\n4. Return to the caller with explicit evidence, uncertainty, and any implementation handoff constraints.\n\n## Source-Quality Rules\n\n- Prefer official documentation, upstream source, release notes, changelogs, standards, and maintainer guidance.\n- Include source URLs for material claims.\n- State date/version context for current best-practice claims.\n- Label third-party summaries as supplemental; do not use them before official/upstream sources.\n- Flag stale, conflicting, undocumented, or version-mismatched evidence.\n- Do not over-fetch: gather the smallest evidence set that can support the decision.\n\n## Workflow\n\n1. Classify the question: conceptual best practice, implementation guidance, migration/version guidance, standards/compliance guidance, or mixed local + external guidance.\n2. Gather repo-local facts with `explore` when local usage or constraints affect the answer.\n3. Gather external evidence with `researcher` when current or version-aware practice affects correctness.\n4. Synthesize a concise answer with source quality, version/date context, caveats, and an implementation or planning handoff.\n5. Stop when the answer is grounded enough for the caller; otherwise report the exact blocker or specialist handoff needed.\n\n## Output Contract\n\n```md\n## Best-Practice Research: <question>\n\n### Direct Recommendation\n<actionable guidance or decision support>\n\n### Evidence Used\n- Official/upstream: <source URL> — <what it establishes>\n- Supplemental, if any: <source URL> — <why it is secondary>\n\n### Version / Date Context\n<versions, dates, release channels, or unknowns>\n\n### Repo-Local Context\n<facts from explore, or \"not needed\">\n\n### Boundaries / Non-goals\n<what this research does not decide>\n\n### Handoff\n<planning/execution/test implications; name the next workflow — `$ralplan` for planning, `$ultragoal`/`$team`/`executor` for execution — and note that this skill stops here unless the user explicitly switches workflows>\n```\n\n## Stop Rules\n\n- Stop after a source-backed recommendation is reusable by the caller.\n- Stop and route upward if the task becomes dependency comparison, broad architecture, or implementation.\n- Do not continue researching when remaining work would only polish wording rather than change the recommendation.\n- This skill never implements. After delivering the recommendation and handoff, stop; do not modify repo files or repo state. Resume only when the user explicitly switches to a planning or implementation workflow named in the handoff.\n\nTask: {{ARGUMENTS}}\n","frontmatter":{"name":"best-practice-research","description":"[OMX] Bounded best-practice research wrapper using official/upstream evidence first","argument-hint":"<technology|decision|practice question>"},"isInternal":false,"tokens":1085,"sizeBytes":5433},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/cancel/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/cancel/SKILL.md","title":"cancel","category":"anthropic-skill","format":"markdown","content":"---\nname: cancel\ndescription: Cancel any active OMX mode (autopilot, ralph, ultrawork, ecomode, ultraqa, swarm, ultrapilot, pipeline, team)\n---\n\n# Cancel Skill\n\n## When to use\n\nUse `/cancel` (or `cancelomc` / `stopomc`) to stop an active OMX mode and perform its documented cleanup. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot` first; it is the invariant authority for scope, ownership, hooks, and Team cleanup.\n\n## Inputs and preconditions\n\n- Accepted forms are `/cancel` and `/cancel --force`.\n- Reject `--all`, unknown flags, repeated flags, and mixed flags before mutation.\n- Discover the current session/root with the state read surfaces before cleanup:\n ```bash\n omx state list-active --json\n omx state get-status --mode <mode> --json\n ```\n- Confirm the current session/root and exact target before cleanup; stop when the required evidence is missing.\n\n## Operational steps\n\n1. Parse and validate arguments; select one exact session/root scope.\n2. Inspect active modes in dependency order:\n `autopilot → ralph → ultrawork → ecomode → ultraqa → swarm → ultrapilot → pipeline → team → plan-consensus`.\n3. Cancel Autopilot while preserving its resumable state; clean only linked child modes it owns.\n4. For Ralph, terminalize the target state (`active:false`, `current_phase:\"cancelled\"`, `completed_at`) and terminalize a proven linked Ultrawork/Ecomode state in the same scope. Confirm the post-conditions in `docs/contracts/ralph-cancel-contract.md`.\n5. Clear standalone modes only after proving they are not linked to another active mode.\n6. For Team, inspect the runtime with `omx team status <team> --json`; use `omx team shutdown <team>` after the normal completion gate, or follow the explicit abort path.\n7. Clear only the selected mode/session state through the state API, for example:\n ```bash\n omx state clear --input '{\"mode\":\"<mode>\",\"session_id\":\"<session>\"}' --json\n ```\n8. With `--force`, perform its documented native-stop cleanup. Report rollback or cleanup failures rather than claiming success.\n\n## Exit and evidence\n\nReport one result per selected mode: mode, scope/session, terminal phase, preserved state, linked cleanup, and any refusal reason. A clean no-op reports `No active OMX modes detected.` Include Team status and shutdown evidence when Team was selected.\n","frontmatter":{"name":"cancel","description":"Cancel any active OMX mode (autopilot, ralph, ultrawork, ecomode, ultraqa, swarm, ultrapilot, pipeline, team)"},"isInternal":false,"tokens":543,"sizeBytes":2337},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/code-review/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/code-review/SKILL.md","title":"code-review","category":"anthropic-skill","format":"markdown","content":"---\nname: code-review\ndescription: Run a comprehensive code review\n---\n\n# Code Review Task Card\n\nUse this explicit opt-in for a merge-readiness review. Shared operating invariants\nlive in `templates/AGENTS.md`; this card only defines review-specific behavior.\n\n## When to use\n\n- The user asks for a code review or quality/security assessment.\n- A change is ready for review before merge, or a major feature needs an independent review.\n- Do not activate this card for implementation, broad planning, or automatic cleanup.\n\n## Inputs\n\n- Scope: the requested files, commit, PR, or whole diff.\n- Requirements/specification, acceptance criteria, and relevant test/CI evidence.\n- Existing review artifacts and known risks, if any.\n- If the user says `continue`, advance the current verified review step rather than restarting discovery.\n\nStart by recording the scope:\n\n```sh\ngit status --short\ngit diff --stat\ngit diff -- <scope>\n```\n\n## Execution\n\n1. Identify changed files and review boundaries; do not silently widen the scope.\n2. Launch the `code-reviewer` and `architect` agents in parallel. Both lanes run in parallel on a clean context with explicit scope and artifacts. If either lane cannot be launched or does not return evidence, report `independent review unavailable`; do **not** substitute the current/authoring lane, and do **not** approve or mark the review merge-ready.\n3. Respect the user's current model and reasoning/effort selection. Do not pass `model` or `reasoning_effort` overrides in review-lane calls.\n\n```text\ntask(\n agent_type=\"code-reviewer\",\n prompt=\"CODE REVIEW TASK\n\nReview the supplied scope for spec compliance, security, quality, performance, and maintainability.\nReturn files reviewed, severity-rated findings with file:line evidence and concrete fixes,\nand a recommendation: APPROVE / REQUEST CHANGES / COMMENT. Do not review architecture.\nScope: [scope and artifacts]\"\n)\n\ntask(\n agent_type=\"architect\",\n prompt=\"ARCHITECTURE / DEVIL'S-ADVOCATE REVIEW TASK\n\nReview the same scope for boundaries, interfaces, hidden coupling, long-term tradeoffs,\nand the strongest counterargument against approval. Return file:line evidence,\nrecommendations, and Architectural Status: CLEAR / WATCH / BLOCK.\nScope: [scope and artifacts]\"\n)\n```\n\n## Review taxonomy\n\n- `code-reviewer` checks **Security**, **Code Quality**, **Performance**, **Best Practices**, and **Maintainability**.\n- Rate each finding: **CRITICAL** (security or data-loss blocker), **HIGH** (bug/major smell), **MEDIUM** (important improvement), or **LOW** (style/suggestion).\n- `architect` checks explicit boundaries/interfaces, hidden coupling, long-horizon tradeoffs, and devil's-advocate concerns. Status is **CLEAR**, **WATCH** (non-blocking concern), or **BLOCK** (merge blocker).\n- Every finding names `file:line`, issue, risk, and a concrete fix; distinguish facts from suggestions.\n\n## State/HUD Phase Contract\n\n- Standalone `$code-review` relies on hook-owned `skill-active-state.json` (`skill:\"code-review\"`, `phase:\"planning\"`); do not create `code-review-state.json`.\n- Inside Autopilot, keep `mode:\"autopilot\"` active with `current_phase:\"code-review\"` / skill-active `phase:\"code-review\"`; do not activate a peer workflow.\n- On clean review, persist the artifact under Autopilot `handoff_artifacts.code_review` before moving to `ultraqa`. On non-clean review, persist findings and use `rework` or `ralplan` as appropriate.\n\n```sh\nomx state write --input '{\"mode\":\"autopilot\",\"active\":true,\"current_phase\":\"code-review\"}' --json\n```\n\n## Final Synthesis and gate\n\n### Architectural Status Contract\n\nCombine the `code-reviewer` recommendation and architect status. Approval requires explicit evidence from both independent lanes; missing or failed delegation is a blocking unavailable-review state, not an approval fallback. The final report must make architect blockers impossible to miss.\n\n- If architect status is **BLOCK**, final recommendation is **REQUEST CHANGES**.\n- Else if `code-reviewer` recommendation is **REQUEST CHANGES**, final recommendation is **REQUEST CHANGES**.\n- Else if architect status is **WATCH**, final recommendation is **COMMENT**.\n- Else final recommendation follows the `code-reviewer` lane.\n\nApproval criteria: **APPROVE** only when `code-reviewer` returns APPROVE, architect status is `CLEAR`, and both independent lanes returned evidence. **REQUEST CHANGES** for a blocker, unresolved high/critical finding, or unavailable lane. **COMMENT** may record non-blocking findings.\n\nDo not self-review as a fallback. If the `code-reviewer` or `architect` path is missing, unavailable, skipped, or fails, block approval until independent lane evidence exists. On the supported `omx ralph` CLI compatibility path, findings may trigger automatic fix follow-up without another permission prompt; plain `code-review` itself remains read-only and does **not** promise auto-fix.\n\n## Evidence/output contract\n\nReturn a concise report containing:\n\n```text\nCODE REVIEW REPORT\nFiles Reviewed: <count>\nTotal Issues: 0\nArchitectural Status: CLEAR | WATCH | BLOCK\nCRITICAL (0) | HIGH (0) | MEDIUM (0) | LOW (0)\nFindings: file:line -> issue, risk, concrete fix (or none)\nARCHITECTURE WATCHLIST: concern, status, recommendation (or none)\n- code-reviewer recommendation: COMMENT\n- architect status: WATCH\n- final recommendation: COMMENT\nRECOMMENDATION: COMMENT\n```\n\nReplace the illustrative counts and verdict with observed values. Include scope,\nlane evidence/artifact references, unresolved risks, and validation gaps.\n\n## Exit condition\n\nStop when the scoped diff has two independent lane results and a deterministic final\nrecommendation. Report `APPROVE` only under the approval criteria; otherwise leave a\nbounded `REQUEST CHANGES`, `COMMENT`, or unavailable-review result. Never claim\nmerge-ready without the required evidence.\n","frontmatter":{"name":"code-review","description":"Run a comprehensive code review"},"isInternal":false,"tokens":1289,"sizeBytes":5845},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/configure-notifications/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/configure-notifications/SKILL.md","title":"configure-notifications","category":"anthropic-skill","format":"markdown","content":"---\nname: configure-notifications\ndescription: Configure OMX notifications - unified entry point for all platforms\ntriggers:\n - \"configure notifications\"\n - \"setup notifications\"\n - \"notification settings\"\n - \"configure discord\"\n - \"configure telegram\"\n - \"configure slack\"\n - \"configure openclaw\"\n - \"setup discord\"\n - \"setup telegram\"\n - \"setup slack\"\n - \"setup openclaw\"\n - \"discord notifications\"\n - \"telegram notifications\"\n - \"slack notifications\"\n - \"openclaw notifications\"\n - \"discord webhook\"\n - \"telegram bot\"\n - \"slack webhook\"\n---\n\n# Configure OMX Notifications\n\nUse this card for Discord, Telegram, Slack, generic command aliases, or OpenClaw. Shared safety, lifecycle, hook, team, autonomy, and cancellation rules live in `templates/AGENTS.md`.\n\n## 1. Inspect and choose a path\n\n```bash\nCONFIG_FILE=\"$HOME/.codex/.omx-config.json\"\nif [ -f \"$CONFIG_FILE\" ]; then\n jq -r '{notifications_enabled:(.notifications.enabled // false), discord:(.notifications.discord.enabled // false), discord_bot:(.notifications[\"discord-bot\"].enabled // false), telegram:(.notifications.telegram.enabled // false), slack:(.notifications.slack.enabled // false), openclaw:(.notifications.openclaw.enabled // false), custom_webhook_command:(.notifications.custom_webhook_command.enabled // false), custom_cli_command:(.notifications.custom_cli_command.enabled // false), verbosity:(.notifications.verbosity // \"session\"), idleCooldownSeconds:(.notifications.idleCooldownSeconds // 60), reply_enabled:(.notifications.reply.enabled // false)}' \"$CONFIG_FILE\"\nelse\n echo \"NO_CONFIG_FILE\"\nfi\n```\n\nUse AskUserQuestion to choose: Discord native (webhook or bot), Telegram native (bot token + chat id), Slack native (incoming webhook), `custom_webhook_command`, `custom_cli_command`, cross-cutting settings, or disable all notifications.\n\n## 2. Native providers\n\nCollect and validate provider values, then write only these native keys: `notifications.discord`, `notifications[\"discord-bot\"]`, `notifications.telegram`, or `notifications.slack`. Do not represent native providers with generic aliases.\n\n## 3. Generic aliases\n\nFor `custom_webhook_command`, collect URL, optional headers, method (`POST` default or `PUT`), events (`session-end`, `ask-user-question`, `session-start`, `session-idle`, `stop`), and an instruction template:\n\n```bash\njq --arg url \"$URL\" --arg method \"${METHOD:-POST}\" --arg instruction \"${INSTRUCTION:-OMX event {{event}} for {{projectPath}}}\" --argjson headers \"${HEADERS_JSON:-{}}\" '.notifications=(.notifications//{enabled:true})|.notifications.enabled=true|.notifications.custom_webhook_command={enabled:true,url:$url,headers:$headers,method:$method,instruction:$instruction,events:[\"session-end\",\"ask-user-question\"]}' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\nFor `custom_cli_command`, collect a command template (`{{event}}`, `{{instruction}}`, `{{sessionId}}`, `{{projectPath}}`), optional events, and an instruction template:\n\n```bash\njq --arg command \"$COMMAND_TEMPLATE\" --arg instruction \"${INSTRUCTION:-OMX event {{event}} for {{projectPath}}}\" '.notifications=(.notifications//{enabled:true})|.notifications.enabled=true|.notifications.custom_cli_command={enabled:true,command:$command,instruction:$instruction,events:[\"session-end\",\"ask-user-question\"]}' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\nOpenClaw dispatch requires `OMX_OPENCLAW=1`; command gateways additionally require `OMX_OPENCLAW_COMMAND=1`; timeout precedence is `gateways.<name>.timeout` > `OMX_OPENCLAW_COMMAND_TIMEOUT_MS` > `5000` ms.\n\n## 4. OpenClaw + Clawdbot agent mode\n\nUse this only when the requested route is a `clawdbot agent` turn delivered to Discord. The `session-stop` notification intentionally maps to the OpenClaw `stop` hook. OMX shell-escapes substitutions; keep instructions short, avoid untrusted shell metacharacters, append `|| true`, and append JSONL logs with `>>`.\n\n```bash\njq --arg command \"(clawdbot agent --session-id omx-hooks --message {{instruction}} --thinking minimal --deliver --reply-channel discord --reply-to 'channel:CHANNEL_ID' --timeout 120 --json >>/tmp/omx-openclaw-agent.jsonl 2>&1 || true)\" '.notifications=(.notifications//{enabled:true})|.notifications.enabled=true|.notifications.verbosity=\"verbose\"|.notifications.openclaw={enabled:true,gateways:{local:{type:\"command\",command:$command,timeout:120000}},hooks:{\"session-start\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-start project={{projectName}} session={{sessionId}} tmux={{tmuxSession}}. 한국어로 상태를 #omc-dev에 공유하고 SOUL.md를 참고하세요.\"},\"session-idle\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-idle session={{sessionId}} tmux={{tmuxSession}}. 한국어로 팔로업을 #omc-dev에 안내하세요.\"},\"ask-user-question\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=ask-user-question session={{sessionId}} tmux={{tmuxSession}} question={{question}}. 한국어로 응답 필요를 #omc-dev에 알리세요.\"},\"stop\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-stop session={{sessionId}} tmux={{tmuxSession}}. 한국어로 중단 상태를 전달하세요.\"},\"session-end\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-end session={{sessionId}} tmux={{tmuxSession}} reason={{reason}}. 한국어로 완료 요약을 #omc-dev에 남기세요.\"}}}' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\n### Compatibility + precedence contract\n\nExplicit `notifications.openclaw` wins when valid; generic aliases are ignored with a warning.\n\nVerify this mode and inspect evidence without hiding output:\n\n```bash\nclawdbot agent --session-id omx-hooks --message \"OMX hook test via clawdbot agent path\" --thinking minimal --deliver --reply-channel discord --reply-to 'channel:CHANNEL_ID' --timeout 120 --json\ntmux list-sessions -F '#{session_name}' | rg '^omx-' || true\njq '.notifications.openclaw.hooks' \"$CONFIG_FILE\"\ntail -n 120 /tmp/omx-openclaw-agent.jsonl | jq -s '.[] | {timestamp:(.timestamp // .time),status:(.status // .error // \"ok\")}'\nrg '\"error\"|\"failed\"|\"timeout\"' /tmp/omx-openclaw-agent.jsonl | tail -20\n```\n\nFor HTTP integrations, run both a `/hooks/wake` smoke test and `/hooks/agent` delivery verification.\n\n## 5. Cross-cutting settings and disable\n\n- Verbosity: `minimal`, `session` (recommended), `agent`, or `verbose`.\n- Idle cooldown: `notifications.idleCooldownSeconds` (environment override: `OMX_IDLE_COOLDOWN_SECONDS`).\n- Profiles: `notifications.profiles` and `notifications.defaultProfile`.\n- Reply listener: `notifications.reply.enabled`; gates are `OMX_REPLY_ENABLED=true` and, for Discord, `OMX_REPLY_DISCORD_USER_IDS=...`. An authorized Discord bot operator may exact-match `status` on a tracked notification for a bounded read-only session summary.\n\nDisable all notifications:\n\n```bash\njq '.notifications.enabled=false' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\n## Exit evidence\n\nRun `jq empty \"$CONFIG_FILE\"` after edits. Report the config path, enabled native providers, enabled aliases, whether valid `notifications.openclaw` overrides aliases, verbosity, idle cooldown, reply-listener state, and smoke-test results. Stop when the JSON parses and the selected path has its required evidence; do not claim delivery from configuration alone.\n","frontmatter":{"name":"configure-notifications","description":"Configure OMX notifications - unified entry point for all platforms","triggers":["configure notifications","setup notifications","notification settings","configure discord","configure telegram","configure slack","configure openclaw","setup discord","setup telegram","setup slack","setup openclaw","discord notifications","telegram notifications","slack notifications","openclaw notifications","discord webhook","telegram bot","slack webhook"]},"isInternal":false,"tokens":1808,"sizeBytes":7423},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/deep-interview/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/deep-interview/SKILL.md","title":"deep-interview","category":"anthropic-skill","format":"markdown","content":"---\nname: deep-interview\ndescription: Socratic deep interview with mathematical ambiguity gating before execution\nargument-hint: \"[--quick|--standard|--deep] [--autoresearch] <idea or vague description>\"\n---\n\n<Purpose>\nDeep Interview is an intent-first Socratic clarification loop before planning or implementation. It turns vague ideas into execution-ready specifications by asking targeted questions about why the user wants a change, how far it should go, what should stay out of scope, and what OMX may decide without confirmation.\n</Purpose>\n\n<Use_When>\n- The request is broad, ambiguous, or missing concrete acceptance criteria\n- The user says \"deep interview\", \"interview me\", \"ask me everything\", \"don't assume\", or \"ouroboros\"\n- The user wants to avoid misaligned implementation from underspecified requirements\n- You need a requirements artifact before handing off to `ralplan`, `autopilot`, `ultragoal`, or `team`\n</Use_When>\n\n<Do_Not_Use_When>\n- The request already has concrete file/symbol targets and clear acceptance criteria\n- The user explicitly asks to skip planning/interview and execute immediately\n- The user asks for lightweight brainstorming only (use `plan` instead)\n- A complete PRD/plan already exists and execution should start\n</Do_Not_Use_When>\n\n<Why_This_Exists>\nExecution quality is usually bottlenecked by intent clarity, not just missing implementation detail. A single expansion pass often misses why the user wants a change, where the scope should stop, which tradeoffs are unacceptable, and which decisions still require user approval. This workflow applies Socratic pressure + quantitative ambiguity scoring so orchestration modes begin with an explicit, testable, intent-aligned spec.\n</Why_This_Exists>\n\n<Depth_Profiles>\n- **Quick (`--quick`)**: fast pre-PRD pass; target threshold `<= 0.30`; max rounds 5\n- **Standard (`--standard`, default)**: full requirement interview; target threshold `<= 0.20`; max rounds 12\n- **Deep (`--deep`)**: high-rigor exploration; target threshold `<= 0.15`; max rounds 20\n- **Autoresearch (`--autoresearch`)**: same interview rigor as Standard, but specialized for `$autoresearch` mission readiness and `.omx/specs/` artifact handoff\n\nProfile `max rounds` is a hard cap, not a target. Do not continue only to reach a numbered round count. Extra Socratic rigor does not override the active threshold unless the profile/config changes.\n\nIf no flag is provided, use **Standard**.\n\n<Mode_Flags>\n- **`--autoresearch`**: switch the interview into autoresearch-intake mode for `$autoresearch` handoff. In this mode, the interview should converge on a validator-ready research mission, write canonical artifacts under `.omx/specs/`, and preserve the explicit `refine further` vs `launch` boundary for downstream skill intake.\n</Mode_Flags>\n</Depth_Profiles>\n\n<Execution_Policy>\n- Ask ONE question per round (never batch multiple interview rounds into one `questions[]` form)\n- Ask about intent and boundaries before implementation detail\n- Target the weakest clarity dimension each round after applying the stage-priority rules below\n- Treat every answer as a claim to pressure-test before moving on: the next question should usually demand evidence or examples, expose a hidden assumption, force a tradeoff or boundary, or reframe root cause vs symptom\n- Do not rotate to a new clarity dimension just for coverage when the current answer is still vague; stay on the same thread until one layer deeper, one assumption clearer, or one boundary tighter\n- Before crystallizing, complete at least one explicit pressure pass that revisits an earlier answer with a deeper, assumption-focused, or tradeoff-focused follow-up\n- Gather codebase facts via `explore` before asking user about internals\n- `omx explore` is deprecated. Use normal repository inspection tools/subagents for simple read-only brownfield fact gathering; use `omx sparkshell` only for explicit shell-native read-only evidence, and keep ambiguous or non-shell-only investigation on the richer normal path.\n- Always run a preflight context intake before the first interview question\n- For brownfield work, preflight must include doc/context grounding before user-facing questions: inspect applicable `AGENTS.md` files, README/getting-started docs, relevant `docs/` contracts/plans/ADRs, existing `.omx/context/` snapshots, and any project-local glossary/context files such as `CONTEXT.md` or `CONTEXT-MAP.md` when present.\n- Treat existing repo language as evidence, not authority: if the user uses a fuzzy, overloaded, or conflicting term, surface the specific doc/code wording and ask which meaning should govern before implementation.\n- Cross-check user claims about current behavior against code or documented contracts when discoverable. If docs and code disagree, ask a confirmation question that names both sources instead of silently choosing one.\n- Use scenario-based edge-case grilling when relationships, boundaries, or handoff behavior are unclear: invent one concrete scenario that stresses the ambiguous boundary, then ask one focused question about the expected outcome.\n- Durable docs, glossary, ADR, or memory updates are opt-in and public-safe only. Deep-interview may recommend such updates in the handoff summary, but must not automatically create or dump public docs from interview transcripts unless the user explicitly chooses that as in-scope.\n- If initial context is oversized or would exceed the prompt budget, do not paste or forward the raw payload into interview prompts; request and record a prompt-safe initial-context summary first\n- The oversized initial-context summary gate is blocking: wait for the concise summary before ambiguity scoring, crystallizing artifacts, or any downstream execution handoff\n- The summary must preserve goals, constraints, success criteria, non-goals, decision boundaries, and references to any full source documents so downstream consumers receive a prompt-safe but faithful context\n- Keep total prompt payloads within a safe budget by summarizing or trimming retained history; preserve newest/highest-signal answers and never let raw oversized context crowd out the current question\n- Reduce user effort: ask only the highest-leverage unresolved question, and never ask the user for codebase facts that can be discovered directly\n- For brownfield work, prefer evidence-backed confirmation questions such as \"I found X in Y. Should this change follow that pattern?\"\n- Route facts before judgment in the Ouroboros style: before presenting a user-facing interview round, classify whether the needed information is a discoverable fact, a fact needing confirmation, or a human decision. The interview is with the human for judgment, not for facts the agent can inspect.\n- When unresolved ambiguity depends on current external best practices, official/upstream guidance, standards, or version-aware behavior, use `$best-practice-research` as the bounded evidence wrapper before crystallizing requirements or handing off to planning/execution.\n- Use these transcript/spec labels only; never use them as `omx question` `source` values, and never replace the runtime `source: \"deep-interview\"` contract for user-facing deep-interview questions:\n - `[from-code][auto-confirmed]` — exact, high-confidence codebase facts from manifests/configs or direct source evidence, with no prescription attached.\n - `[from-code]` — codebase findings that are useful but inferred, pattern-based, or low/medium confidence and therefore need a confirmation-style user-facing round before being treated as settled.\n - `[from-research]` — externally sourced facts such as API limits, compatibility, or public documentation; facts only, not decisions.\n - `[from-user]` — goals, preferences, business logic, scope, non-goals, acceptance criteria, tradeoffs, and any decision-bearing interpretation.\n- Treat `[from-code][auto-confirmed]` and other non-user fact discoveries as context/transcript updates, not interview rounds: do not call `omx question`, do not create a pending deep-interview question obligation, and do not increment the user-facing round number for facts the agent can safely establish.\n- Auto-confirm only descriptive facts. If a finding implies what the new feature should do, which pattern it should follow, which tradeoff to accept, or what should stay in/out of scope, route the entire decision-bearing question to the user as `[from-user]` even when code or research facts are available.\n- In attached-tmux Codex CLI, deep-interview uses `omx question` as the required OMX-owned structured questioning path for every interview round\n- When invoking `omx question` through attached-tmux Bash/tool paths, preserve the leader-pane return target by prefixing the command with `OMX_QUESTION_RETURN_PANE=$TMUX_PANE` (or a concrete `%pane` value)\n- If you launch `omx question` in a background terminal, immediately wait for that background terminal to finish and read its JSON answer before scoring ambiguity, asking another round, or handing off\n- Treat `answers[]` as the primary `omx question` success contract. For a single interview round, read `answers[0].answer`; use legacy top-level `answer` only as a compatibility fallback when needed.\n- If the current runtime is outside tmux and cannot render `omx question`, use the native structured question tool when available; otherwise ask exactly one concise plain-text question and wait for the answer\n- Re-score ambiguity after each answer and show progress transparently\n- Once ambiguity is at or below the active profile threshold, stop ordinary questioning. Run the practical closure audit: crystallize/handoff when readiness gates pass; otherwise ask only the final closure question needed to satisfy a named gate.\n- Treat `max_rounds` as a stop cap, not evidence that more rounds are needed.\n- Do not hand off to execution while ambiguity remains above threshold unless user explicitly opts to proceed with warning\n- Do not crystallize or hand off while `Non-goals` or `Decision Boundaries` remain unresolved, even if the weighted ambiguity threshold is met\n- Treat early exit as a safety valve, not the default success path\n- Persist mode state for resume safety only through the CLI/programmatic single-writer authority (`omx state write/read --input '<json>' --json`, backed by `src/state/operations.ts`). The MCP state server is a read-only projection and must never become a second writer.\n</Execution_Policy>\n\n<Steps>\n\n## Phase 0: Preflight Context Intake\n\n1. Parse `{{ARGUMENTS}}` and derive a short task slug.\n2. Attempt to load the latest relevant context snapshot from `.omx/context/{slug}-*.md`.\n3. Check whether the provided initial context or loaded snapshot is too large for safe prompt use. If it is oversized, the first interview round must ask for a concise prompt-safe summary instead of scoring ambiguity or continuing to downstream handoff.\n4. If no snapshot exists, create a minimum context snapshot with:\n - Task statement\n - Desired outcome\n - Stated solution (what the user asked for)\n - Probable intent hypothesis (why they likely want it)\n - Known facts/evidence\n - Constraints\n - Unknowns/open questions\n - Decision-boundary unknowns\n - Likely codebase touchpoints\n - Relevant repo docs/rules/context inspected\n - Terminology or doc/code conflicts found\n - Prompt-safe initial-context summary status (`not_needed`, `needed`, or `recorded`)\n5. For brownfield tasks, inspect the applicable documentation/rule surface before the first user-facing round. Prefer exact, nearby sources over broad scans:\n - governing `AGENTS.md` files and template/runtime instruction surfaces that apply to the touched paths\n - README/getting-started docs and relevant docs under `docs/`, especially contracts, plans, ADR-like records, and workflow docs\n - existing `.omx/context/` snapshots, `.omx/specs/`, and planning artifacts relevant to the slug\n - project-local glossary/context files such as `CONTEXT.md`, `CONTEXT-MAP.md`, or context-specific docs when they exist\n6. Save snapshot to `.omx/context/{slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`) and reference it in mode state.\n\n## Phase 1: Initialize\n\n1. Parse `{{ARGUMENTS}}` and depth profile (`--quick|--standard|--deep`).\n2. Detect project context:\n - Run `explore` to classify **brownfield** (existing codebase target) vs **greenfield**.\n - For brownfield, collect relevant codebase context before questioning.\n3. Initialize state via `omx state write --input '{\"mode\":\"deep-interview\",\"active\":true}' --json`:\n\n```json\n{\n \"active\": true,\n \"current_phase\": \"deep-interview\",\n \"state\": {\n \"interview_id\": \"<uuid>\",\n \"profile\": \"quick|standard|deep\",\n \"type\": \"greenfield|brownfield\",\n \"initial_idea\": \"<user input>\",\n \"rounds\": [],\n \"current_ambiguity\": 1.0,\n \"threshold\": 0.3,\n \"max_rounds\": 5,\n \"challenge_modes_used\": [],\n \"codebase_context\": null,\n \"current_stage\": \"intent-first\",\n \"current_focus\": \"intent\",\n \"context_snapshot_path\": \".omx/context/<slug>-<timestamp>.md\"\n }\n}\n```\n\n4. Announce kickoff with profile, threshold, and current ambiguity.\n\n## Phase 2: Socratic Interview Loop\n\nRepeat until ambiguity `<= threshold`, the pressure pass is complete, the readiness gates are explicit, the user exits with warning, or max rounds are reached. This is a stop condition: below threshold, do not open a new ordinary interview branch.\n\n### 2a) Generate next question\nIf the initial context is oversized and no prompt-safe summary has been recorded yet, the next question must be only a summary request. Do not score ambiguity, do not run readiness gates, and do not hand off to `$ultragoal`, `$ralplan`, `$autopilot`, or `$team` until that summary answer is captured.\n\nUse:\n- Original idea\n- Prior Q&A rounds\n- Current dimension scores\n- Brownfield context (if any)\n- Doc/context grounding notes, including existing terminology, governing rules, and any doc/code mismatch\n- Activated challenge mode injection (Phase 3)\n\nTarget the lowest-scoring dimension, but respect stage priority:\n- **Stage 1 — Intent-first:** Intent, Outcome, Scope, Non-goals, Decision Boundaries\n- **Stage 2 — Feasibility:** Constraints, Success Criteria\n- **Stage 3 — Brownfield grounding:** Context Clarity (brownfield only)\n\nFollow-up pressure ladder after each answer:\n1. Ask for a concrete example, counterexample, or evidence signal behind the latest claim\n2. Probe the hidden assumption, dependency, or belief that makes the claim true\n3. Force a boundary or tradeoff: what would you explicitly not do, defer, or reject?\n4. Challenge fuzzy or conflicting terms against the repo's documented language and current code behavior\n5. Stress-test the boundary with one concrete scenario or edge case when a relationship or handoff remains ambiguous\n6. If the answer still describes symptoms, reframe toward essence / root cause before moving on\n\nPrefer staying on the same thread for multiple rounds when it has the highest leverage. Breadth without pressure is not progress.\n\nMaintain a **Breadth Ledger** across independent ambiguity tracks: scope, constraints, outputs, verification, brownfield integration, and any user-mentioned deliverable tracks. The ledger is a guard, not a mandatory rotation rule: stay deep on the current thread until it has been pressure-tested, then zoom out only when another material track remains unresolved and would change execution.\n\nMaintain a **Docs/Terminology Ledger** for brownfield interviews:\n- repo docs/rules/context sources inspected, with path references\n- canonical terms already used by the repo and terms to avoid or disambiguate\n- user terms that conflict with docs or current code behavior\n- doc/code mismatches that require a human decision before implementation\n- optional durable-doc follow-ups that are safe to propose but not auto-apply\n\nDetailed dimensions:\n- Intent Clarity — why the user wants this\n- Outcome Clarity — what end state they want\n- Scope Clarity — how far the change should go\n- Constraint Clarity — technical or business limits that must hold\n- Success Criteria Clarity — how completion will be judged\n- Context Clarity — existing codebase understanding (brownfield only)\n\n`Non-goals` and `Decision Boundaries` are mandatory readiness gates. Ask about them early and keep revisiting them until they are explicit.\n\n### 2b) Ask the question\nUse the surface-appropriate structured questioning path for every interview round. In attached-tmux sessions, use OMX-owned structured questioning via `omx question` (this is the required structured-question equivalent and required `AskUserQuestion` equivalent for deep-interview). Outside tmux, use native structured input when available; otherwise ask exactly one concise plain-text question and wait for the answer. Present:\n\n```\nRound {n} | Target: {weakest_dimension} | Ambiguity: {score}%\n\n{question}\n```\n\n`omx question` payload guidance for interview rounds:\n- Deep-interview is Socratic: ask one focused round at a time. Do not use batch `questions[]` to combine multiple interview rounds, even though `omx question` supports batch forms for other workflows.\n- Use canonical `type` values instead of authoring raw `multi_select` flags by hand. `type: \"single-answerable\"` is the default for one-path decisions; `type: \"multi-answerable\"` is the canonical shape for bounded multi-select rounds. The runtime will keep `multi_select` aligned with `type`.\n- Use `single-answerable` when exactly one answer should drive the next branch, the options are mutually exclusive, or selecting more than one answer would blur the decision boundary. Typical cases: handoff lane selection, choosing the primary failure mode, or confirming which of several competing interpretations is correct.\n- Use `multi-answerable` when multiple options may all be true at once and you need to capture a bounded set of coexisting constraints, non-goals, risks, or acceptance checks in one round. Typical cases: selecting all out-of-scope items, all success metrics that must hold, or all deployment constraints that apply together.\n- If one selected option would immediately require a follow-up question to disambiguate the others, prefer a `single-answerable` round now and ask the follow-up next. Do not hide a branching interview tree inside one overloaded multi-select prompt.\n- Keep interview options bounded and concrete. If the valid answers are already known, set `allow_other: false`; only leave `allow_other: true` when the interview genuinely needs one user-supplied option that cannot be enumerated in advance.\n- Read answers structurally from the primary `answers[]` array. For a normal single-round interview response, use `answers[0].answer` as the source of truth; the top-level `answer` field is a legacy single-question projection/fallback only.\n- For `single-answerable`, expect one decisive selection in the `value` field of `answers[0].answer` plus its selected-values metadata. For `multi-answerable`, treat the selected-values field inside `answers[0].answer` as the source of truth for all chosen constraints/non-goals and preserve the full set in the transcript/spec. In legacy single-question projections, this is equivalent to: For `multi-answerable`, treat `answer.selected_values` as the source of truth.\n\nCanonical bounded single-choice payload:\n\n```json\n{\n \"question\": \"Which execution lane should own this once the interview is complete?\",\n \"type\": \"single-answerable\",\n \"options\": [\n {\n \"label\": \"Plan first\",\n \"value\": \"ralplan\",\n \"description\": \"Need architecture and test-shape review before execution\"\n },\n {\n \"label\": \"Execute directly\",\n \"value\": \"autopilot\",\n \"description\": \"Requirements are already explicit enough for planning plus execution\"\n },\n {\n \"label\": \"Refine further\",\n \"value\": \"refine\",\n \"description\": \"Clarification is still needed before any handoff\"\n }\n ],\n \"allow_other\": false,\n \"other_label\": \"Other\",\n \"source\": \"deep-interview\"\n}\n```\n\nCanonical bounded multi-select payload:\n\n```json\n{\n \"question\": \"Which non-goals must stay out of scope for the first pass?\",\n \"type\": \"multi-answerable\",\n \"options\": [\n {\n \"label\": \"No UI redesign\",\n \"value\": \"no-ui-redesign\",\n \"description\": \"Keep layout and styling unchanged\"\n },\n {\n \"label\": \"No new dependencies\",\n \"value\": \"no-new-dependencies\",\n \"description\": \"Work within the existing toolchain\"\n },\n {\n \"label\": \"No API contract changes\",\n \"value\": \"no-api-contract-changes\",\n \"description\": \"Preserve external request and response shapes\"\n }\n ],\n \"allow_other\": false,\n \"other_label\": \"Other\",\n \"source\": \"deep-interview\"\n}\n```\n\nCanonical answer-shape reminders:\n\n```json\n{\n \"answer\": {\n \"kind\": \"option\",\n \"value\": \"ralplan\",\n \"selected_labels\": [\"Plan first\"],\n \"selected_values\": [\"ralplan\"]\n }\n}\n```\n\n```json\n{\n \"answer\": {\n \"kind\": \"multi\",\n \"value\": [\"no-new-dependencies\", \"no-api-contract-changes\"],\n \"selected_labels\": [\"No new dependencies\", \"No API contract changes\"],\n \"selected_values\": [\"no-new-dependencies\", \"no-api-contract-changes\"]\n }\n}\n```\n\n### 2c) Score ambiguity\nScore each weighted dimension in `[0.0, 1.0]` with justification + gap.\n\nGreenfield: `ambiguity = 1 - (intent × 0.30 + outcome × 0.25 + scope × 0.20 + constraints × 0.15 + success × 0.10)`\n\nBrownfield: `ambiguity = 1 - (intent × 0.25 + outcome × 0.20 + scope × 0.20 + constraints × 0.15 + success × 0.10 + context × 0.10)`\n\nReadiness gate:\n- `Non-goals` must be explicit\n- `Decision Boundaries` must be explicit\n- A pressure pass must be complete: at least one earlier answer has been revisited with an evidence, assumption, or tradeoff follow-up\n- A practical closure audit must pass: another question would change execution materially, not merely polish wording or chase a narrow edge case\n- If either gate is unresolved, or the pressure pass is incomplete, continue below threshold only with a final closure question that names the unresolved gate and would materially change execution.\n- Treat a low ambiguity score as permission to audit closure, not permission to keep drilling indefinitely. If remaining uncertainty would not change implementation, crystallize the spec instead of opening a new branch.\n- If ambiguity is `<= 0.10`, another user-facing question is allowed only as that final closure question; otherwise crystallize immediately.\n\n### 2d) Report progress\nShow weighted breakdown table, readiness-gate status (`Non-goals`, `Decision Boundaries`), and the next focus dimension.\n\n### 2e) Persist state\nAppend round result and updated scores via `omx state write --input '<json>' --json`. Do not write `{mode}-state.json` directly and do not use the read-only MCP state projection as a writer.\n\n### 2f) Round controls\n- Do not offer early exit before the first explicit assumption probe and one persistent follow-up have happened\n- Apply a **Dialectic Rhythm Guard**: track consecutive non-user fact discoveries and confirmation-style answers (`[from-code][auto-confirmed]`, `[from-code]`, or `[from-research]`). After 3 consecutive non-user or confirmation answers, the next material user-facing round must solicit direct human judgment (`[from-user]`) unless the closure audit says the interview is ready to crystallize.\n- Round 4+: allow explicit early exit with risk warning\n- Soft warning at profile midpoint (e.g., round 3/6/10 depending on profile)\n- Hard cap at profile `max_rounds`; never treat this cap as a desired interview length or quota\n\n## Phase 3: Challenge Modes (assumption stress tests)\n\nUse each mode once when applicable. These are normal escalation tools, not rare rescue moves:\n\n- **Contrarian** (round 2+ or immediately when an answer rests on an untested assumption): challenge core assumptions\n- **Terminologist** (brownfield, whenever a key term is fuzzy, overloaded, or conflicts with repo docs/code): force a canonical meaning against existing project language before implementation\n- **Simplifier** (round 4+ or when scope expands faster than outcome clarity): probe minimal viable scope\n- **Ontologist** (round 5+ and ambiguity > 0.25, or when the user keeps describing symptoms): ask for essence-level reframing\n\nTrack used modes in state to prevent repetition.\n\n## Phase 4: Crystallize Artifacts\n\nWhen threshold is met (or user exits with warning / hard cap):\n\n1. Write interview transcript summary to:\n - `.omx/interviews/{slug}-{timestamp}.md`\n (kept for ralph PRD compatibility)\n2. Write execution-ready spec to:\n - `.omx/specs/deep-interview-{slug}.md`\n\nSpec should include:\n- Metadata (profile, rounds, final ambiguity, threshold, context type)\n- Context snapshot reference/path (for ralplan/team reuse)\n- Prompt-safe initial-context summary when oversized context was provided, plus references to any full source documents\n- Clarity breakdown table\n- Intent (why the user wants this)\n- Desired Outcome\n- In-Scope\n- Out-of-Scope / Non-goals\n- Decision Boundaries (what OMX may decide without confirmation)\n- Constraints\n- Testable acceptance criteria\n- Assumptions exposed + resolutions\n- Pressure-pass findings (which answer was revisited, and what changed)\n- Brownfield evidence vs inference notes for any repository-grounded confirmation questions\n- Docs/Terminology Ledger with inspected repo docs/rules/context, term conflicts, and any doc/code mismatch decisions\n- Scenario/edge-case pressure findings that materially shaped scope or acceptance criteria\n- Optional durable documentation recommendations, explicitly marked opt-in and public-safe; do not include raw private transcript dumps\n- Technical context findings\n- Full or condensed transcript\n\n### Autoresearch specialization\n\nWhen the clarified task is specifically about `$autoresearch`, or the skill is invoked with `--autoresearch`, keep the interview domain-specific and emit skill-consumable artifacts without skipping clarification.\n\n- **Accepted seed inputs:** `topic`, `evaluator`, `keep-policy`, `slug`, existing mission draft text, and prior evaluator examples/templates\n- **Required interview focus:** mission clarity, evaluator readiness, keep policy, slug/session naming, and whether the draft is ready to launch now or should refine further\n- **Canonical artifact path:** `.omx/specs/deep-interview-autoresearch-{slug}.md`\n- **Launch artifact bundle:** `.omx/specs/autoresearch-{slug}/mission.md`, `.omx/specs/autoresearch-{slug}/sandbox.md`, and `.omx/specs/autoresearch-{slug}/result.json`\n- **Launch artifact directory:** `.omx/specs/autoresearch-{slug}/`\n- **Required artifact sections:**\n - `Mission Draft`\n - `Evaluator Draft`\n - `Launch Readiness`\n - `Seed Inputs`\n - `Confirmation Bridge`\n- **Required launch artifacts under `.omx/specs/autoresearch-{slug}/`:**\n - `mission.md`\n - `sandbox.md`\n - `result.json`\n- **Launch-readiness rule:** mark the draft as **not launch-ready** while the evaluator command still contains placeholder markers such as `<...>`, `TODO`, `TBD`, `REPLACE_ME`, `CHANGEME`, or `your-command-here`\n- **Structured result contract:** `result.json` should point to the draft + mission/sandbox artifacts and carry the finalized `topic`, `evaluatorCommand`, `keepPolicy`, `slug`, `launchReady`, and `blockedReasons` fields so `$autoresearch` can consume it directly\n- **Confirmation bridge:** after artifact generation, offer at least `refine further` and `launch`; do not run direct CLI launch or detached/split tmux launch, and only hand off to `$autoresearch` after explicit confirmation\n- **Handoff rule:** downstream execution must preserve the clarified mission intent, evaluator expectations, decision boundaries, and launch-readiness status from this artifact rather than bypassing the draft review step\n\n## Phase 5: Execution Bridge\n\nPresent execution options after artifact generation using explicit handoff contracts. Treat the deep-interview spec as the current requirements source of truth and preserve intent, non-goals, decision boundaries, acceptance criteria, docs/terminology grounding, and any residual-risk warnings across the handoff.\n\n### Optional execution contract foundation\n\nWhen an Autopilot/deep-interview handoff explicitly requires a stride contract, emit it as structured data rather than prose. This is a validation foundation, not a broadness-inference feature: do not infer stride from task length, phase labels, snapshots, or freeform wording.\n\nCanonical location under Autopilot state:\n\n```json\n{\n \"handoff_artifacts\": {\n \"deep_interview\": {\n \"execution_contract_required\": true,\n \"execution_contract\": {\n \"version\": 1,\n \"execution_stride\": \"task\",\n \"source\": \"deep-interview\",\n \"selected_by\": \"user\",\n \"allow_task_shrink\": true,\n \"completion_unit\": \"One focused task\",\n \"stop_condition\": \"Stop after that task is implemented and verified\",\n \"acceptance_coverage_scope\": \"task\",\n \"shrink_policy\": \"allowed\"\n }\n }\n }\n}\n```\n\nStride meanings:\n- `task`: conservative, small-step execution; `allow_task_shrink:true`, `acceptance_coverage_scope:\"task\"`, `shrink_policy:\"allowed\"`.\n- `deliverable`: finish the named deliverable before stopping; `allow_task_shrink:false`, `acceptance_coverage_scope:\"deliverable\"`, `shrink_policy:\"ask_before_shrink\"`.\n- `milestone`: finish the larger approved milestone unless blocked; `allow_task_shrink:false`, `acceptance_coverage_scope:\"milestone\"`, `shrink_policy:\"deny_unless_blocked\"`.\n\nOnly set `execution_contract_required:true` when the selected downstream workflow needs this explicit stride/stop-condition guard. New artifacts must write the canonical snake_case schema shown above under `handoff_artifacts.deep_interview`; runtime readers may accept legacy camelCase field/marker aliases and direct/nested `execution_contract` locations only as compatibility input. If `execution_contract_required` is absent or false, downstream Autopilot compatibility behavior is unchanged.\n\n### Goal-mode follow-ups\n\nInclude these product-facing suggestions when they fit the clarified spec, without removing the existing `$ultragoal`, `$ralplan`, `$autopilot`, and `$team` handoff options:\n\n- **`$ultragoal`** — default goal-mode follow-up for implementation or general goal-oriented follow-up specs that should be converted into durable Codex/OMX goals with sequential completion tracking.\n- **`$autoresearch`** — use when the clarified context is a research project: a research question, reference/literature gathering, evaluator-backed analysis, or professor/critic-style deliverable.\n- **`$performance-goal`** — use when the clarified context is an optimization or performance project with measurable speed, latency, throughput, memory, benchmark, or evaluator criteria.\n\nRecommend `$ultragoal` as the default durable goal-mode follow-up because it supersedes Ralph for goal tracking. Preserve `$team` for coordinated parallel implementation.\n\n### 1. **`$ultragoal` (Default durable execution follow-up)**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md` (optionally accompanied by the transcript/context snapshot for traceability)\n- **Invocation:** `$ultragoal create-goals --brief-file <spec-path>` followed by `$ultragoal complete-goals` in the active execution lane\n- **Consumer Behavior:** Convert the clarified spec into durable goal-mode work. Preserve intent, non-goals, decision boundaries, acceptance criteria, docs/terminology grounding, scenario-pressure findings, and residual-risk warnings as binding story constraints.\n- **Skipped / Already-Satisfied Stages:** Requirement interview, ambiguity clarification, doc/context preflight, and early intent-boundary elicitation\n- **Expected Output:** `.omx/ultragoal/brief.md`, `.omx/ultragoal/goals.json`, `.omx/ultragoal/ledger.jsonl`, implementation evidence, verification evidence, and final cleanup/review-gate evidence\n- **Best When:** The clarified spec is execution-ready or the user explicitly wants durable goal tracking as the next step\n- **Next Recommended Step:** Run the Ultragoal completion loop; launch `$team` only inside an active Ultragoal story when parallel lanes are warranted\n\n### 2. **`$ralplan` (Recommended when architecture/test-shape review is still needed)**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md` (optionally accompanied by the transcript/context snapshot for traceability)\n- **Invocation:** `$ralplan <spec-path>`\n- **Consumer Behavior:** Treat the deep-interview spec as the requirements source of truth. Do not repeat the interview by default; refine architecture/feasibility around the clarified intent and boundaries instead.\n- **Skipped / Already-Satisfied Stages:** Requirements discovery, ambiguity clarification, and early intent-boundary elicitation\n- **Expected Output:** Canonical planning artifacts under `.omx/plans/`, especially `prd-*.md` and `test-spec-*.md`\n- **Best When:** Requirements are clear enough to stop interviewing, but architectural validation / consensus planning is still desirable\n- **Next Recommended Step:** Use the approved planning artifacts with `$ultragoal` as the default durable goal-mode follow-up (optionally with `$team` for parallel lanes); choose `$autoresearch` for research validation or `$performance-goal` for measurable optimization\n\n### 3. **`$autopilot`**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md`\n- **Invocation:** `$autopilot <spec-path>`\n- **Consumer Behavior:** Use the deep-interview spec as the clarified execution brief. Preserve intent, non-goals, decision boundaries, and acceptance criteria as binding context for planning/execution.\n- **Skipped / Already-Satisfied Stages:** Initial requirement discovery and ambiguity reduction\n- **Expected Output:** Planning/execution progress, QA evidence, and validation artifacts produced by autopilot\n- **Best When:** The clarified spec is already strong enough for direct planning + execution without an additional consensus gate\n- **Next Recommended Step:** Continue through autopilot's execution/QA/validation flow; if coordination-heavy execution emerges, prefer `$team` under a leader-owned `$ultragoal` ledger\n\n### 4. **`$team`**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md`\n- **Invocation:** `$team <spec-path>`\n- **Consumer Behavior:** Treat the spec as shared execution context for coordinated parallel work. Preserve the clarified intent, non-goals, decision boundaries, and acceptance criteria as common lane constraints.\n- **Skipped / Already-Satisfied Stages:** Requirement clarification and early ambiguity reduction\n- **Expected Output:** Coordinated multi-agent execution against the shared spec, with final verification evidence and checkpoints in an already-active Ultragoal ledger when applicable\n- **Best When:** The task is large, multi-lane, or blocker-sensitive enough to justify coordinated parallel execution instead of a single persistent loop\n- **Next Recommended Step:** Follow the team verification path when the coordinated execution phase finishes; checkpoint an already-active `$ultragoal` ledger when applicable. Do not start another execution loop solely to verify.\n\n### 5. **Refine further**\n- **Input Artifact:** Existing transcript, context snapshot, and current spec draft\n- **Invocation:** Continue the interview loop\n- **Consumer Behavior:** Re-enter questioning to resolve the highest-leverage remaining uncertainty\n- **Skipped / Already-Satisfied Stages:** None beyond already-captured context\n- **Expected Output:** A lower-ambiguity spec with tighter boundaries and fewer unresolved assumptions\n- **Best When:** Residual ambiguity is still too high, the user wants stronger clarity, or the above-threshold / early-exit warning indicates too much risk to proceed cleanly\n- **Next Recommended Step:** Return to one of the execution handoff contracts above once the spec is sufficiently clarified\n\n**Residual-Risk Rule:** If the interview ended via early exit, hard-cap completion, or above-threshold proceed-with-warning, explicitly preserve that residual-risk state in the handoff so the downstream skill knows it inherited a partially clarified brief.\n\n**IMPORTANT:** Deep-interview is a requirements mode. On handoff, invoke the selected skill using the contract above. **Do NOT implement directly** inside deep-interview.\n\n</Steps>\n\n<Tool_Usage>\n- Use `explore` for codebase fact gathering\n- Use `omx question` as the OMX-native structured user-input tool for each interview round when an attached tmux renderer is available\n- From attached-tmux Bash/tool paths, call it as `OMX_QUESTION_RETURN_PANE=$TMUX_PANE omx question ...` unless an explicit `%pane` return target is already known\n- If the current runtime is outside tmux and cannot render `omx question`, use native structured input when available; otherwise ask exactly one concise plain-text question and wait for the answer\n- After `omx question` returns JSON, prefer `answers[0].answer` / `answers[]`; use legacy `answer` only as a fallback for older records\n- Use `omx state write/read --input '<json>' --json` for resumable mode state through the sole-writer state operations path; the MCP state server is read-only and is not a fallback writer\n- If the interview cannot ask a required `omx question` round, persist the blocker as terminal state with `active: false` and `current_phase: \"blocked\"`; do not write a terminal blocked phase with `active: true`\n- Read/write context snapshots under `.omx/context/`\n- Read applicable repo docs/rules/context during preflight; write durable docs, glossary, ADR, or memory updates only when the user explicitly opts in and the content is public-safe\n- Record whether the oversized-context summary gate is not needed, pending, or satisfied before any scoring or handoff step\n- Save transcript/spec artifacts under `.omx/interviews/` and `.omx/specs/`\n</Tool_Usage>\n\n<Escalation_And_Stop_Conditions>\n- User says stop/cancel/abort -> persist state and stop\n- Ambiguity stalls for 3 rounds (+/- 0.05) -> force Ontologist mode once\n- Max rounds reached -> proceed with explicit residual-risk warning\n- All dimensions >= 0.9 -> allow early crystallization even before max rounds\n</Escalation_And_Stop_Conditions>\n\n<Final_Checklist>\n- [ ] Preflight context snapshot exists under `.omx/context/{slug}-{timestamp}.md`\n- [ ] Oversized initial context, if present, has a prompt-safe summary recorded before ambiguity scoring or downstream handoff\n- [ ] Ambiguity score shown each round\n- [ ] Intent-first stage priority used before implementation detail\n- [ ] Weakest-dimension targeting used within the active stage\n- [ ] At least one explicit assumption probe happened before crystallization\n- [ ] At least one persistent follow-up / pressure pass deepened a prior answer\n- [ ] Challenge modes triggered at thresholds (when applicable)\n- [ ] Transcript written to `.omx/interviews/{slug}-{timestamp}.md`\n- [ ] Spec written to `.omx/specs/deep-interview-{slug}.md`\n- [ ] Brownfield questions use evidence-backed confirmation when applicable\n- [ ] Brownfield preflight inspected applicable repo docs/rules/context before user-facing questions\n- [ ] Fuzzy or conflicting terminology was challenged against repo language/current code behavior when applicable\n- [ ] Scenario-based edge-case grilling was used when boundary ambiguity would materially affect implementation\n- [ ] Durable docs/ADR/memory updates, if any, were explicitly opted into and public-safe\n- [ ] Handoff options provided (`$ultragoal`, `$ralplan`, `$autopilot`, `$team`) plus context-sensitive goal-mode suggestions (`$autoresearch`, `$performance-goal`) when applicable\n- [ ] No direct implementation performed in this mode\n</Final_Checklist>\n\n<Advanced>\n## Suggested Config (optional)\n\nDeep-interview reads runtime defaults from the first existing config source in this order:\n\n1. Repository-local `.omx/config.toml`\n2. Repository-root `omx.toml`\n3. User-global `~/.omx/config.toml`\n\nThis section is currently a deep-interview-specific runtime override surface, not a general replacement for Codex `config.toml` or `.omx-config.json` model/env routing.\nMalformed config files are ignored fail-soft so `$deep-interview` activation can continue with built-in defaults.\nExplicit `--quick`, `--standard`, or `--deep` invocation flags override `defaultProfile`.\n\n```toml\n[omx.deepInterview]\ndefaultProfile = \"standard\"\nquickThreshold = 0.30\nstandardThreshold = 0.20\ndeepThreshold = 0.15\nquickMaxRounds = 5\nstandardMaxRounds = 12\ndeepMaxRounds = 20\nenableChallengeModes = true\n```\n\n## Resume\n\nIf interrupted, rerun `$deep-interview`. Resume from persisted mode state via `omx state read --input '{\"mode\":\"deep-interview\"}' --json`.\n\n## Canonical Autopilot Entry Pipeline\n\n```\nautopilot -> deep-interview -> ralplan -> ultragoal\n```\n\n- Autopilot begins with this independent deep-interview clarity gate; it must not substitute `$plan --interview`.\n- Stage 1 (deep-interview): ambiguity clearance and execution-ready requirements artifact\n- Stage 2 (ralplan): feasibility, architecture, and consensus gate\n- Stage 3 (ultragoal): durable execution, verification, and completion receipts\n</Advanced>\n","frontmatter":{"name":"deep-interview","description":"Socratic deep interview with mathematical ambiguity gating before execution","argument-hint":"[--quick|--standard|--deep] [--autoresearch] <idea or vague description>"},"isInternal":false,"tokens":9030,"sizeBytes":41261},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/design/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/design/SKILL.md","title":"design","category":"anthropic-skill","format":"markdown","content":"---\nname: design\ndescription: Canonical repo-local DESIGN.md workflow for product, UI/UX, and frontend decision source of truth\n---\n\n# Design Skill\n\nUse `$design` to discover product and UI evidence, close only design-critical context gaps, and create or refresh the repository’s durable `DESIGN.md` contract. It is a maintained design brief, not a pixel-matching loop or one-off critique.\n\nShared operating, delegation, state, hook, team, cancellation, and verification invariants live in [`templates/AGENTS.md`](../../templates/AGENTS.md). Follow that source instead of duplicating its rules here.\n\n## Use when\n\n- Product, UX, frontend, or design-system decisions need a repo-local source of truth.\n- A feature needs a design brief before a designer lane or implementation.\n- Existing UI, assets, screenshots, or constraints need an actionable design summary.\n\nDo not use it for visual-reference implementation matching (use `$visual-ralph`), screenshot comparison alone, or backend/infrastructure work without user-facing design impact.\n\n## Relationship to `$visual-ralph`\n\n`$design` owns product goals, users, information architecture, visual language, components, accessibility, constraints, and open questions in `DESIGN.md`. `$visual-ralph` owns implementation against an approved visual reference or live-URL baseline, measured verdicts, and pixel-diff evidence. Run `$design` first when both are needed; `DESIGN.md` supports but does not replace the visual verdict target.\n\n## Workflow\n\n### 1. Discover local evidence\n\nInspect and cite existing `DESIGN.md`, design/UX/frontend docs, README/specs/issues, routes/pages/layouts/components/stories, theme and token files, assets, screenshots/mockups, Storybook or Playwright baselines, and accessibility/responsive/i18n/platform constraints. Separate observations from inferences; note absent evidence.\n\n### 2. Interview only missing context\n\nAsk concise questions only for gaps the repository cannot resolve: users/jobs, goals/non-goals, brand personality and forbidden aesthetics, primary flows, accessibility/device/browser targets, or unavailable assets/references. If answers are unavailable, record explicit assumptions and open questions rather than blocking.\n\n### 3. Create or refresh `DESIGN.md`\n\nPreserve useful content, remove contradictions, mark unknowns, and keep decisions actionable. The root file must contain these sections:\n\n# Design\n## Source of truth\nStatus (Draft | Active | Needs refresh), date, product surfaces, evidence reviewed.\n## Brand\nPersonality, trust signals, avoid.\n## Product goals\nGoals, non-goals, success signals.\n## Personas and jobs\nPrimary personas, user jobs, contexts of use.\n## Information architecture\nNavigation, routes/screens, content hierarchy.\n## Design principles\nPrinciples and tradeoffs.\n## Visual language\nColor, typography, spacing, shape/elevation, motion, imagery/iconography.\n## Components\nExisting/new components, variants/states, token ownership.\n## Accessibility\nTarget standard, keyboard/focus, contrast, semantics, reduced motion/sensory concerns.\n## Responsive behavior\nBreakpoints/devices, layout adaptations, touch/hover differences.\n## Interaction states\nLoading, empty, error, success, disabled, offline/slow network where applicable.\n## Content voice\nTone, terminology, microcopy rules.\n## Implementation constraints\nFramework/styling, tokens, performance, compatibility, test/screenshot expectations.\n## Open questions\n`[ ]` question, owner, and impact.\n\n### 4. Apply the contract\n\nBefore UI decisions, cite relevant `DESIGN.md` sections, reuse documented components/tokens, and update the file or add an open question when implementation exposes a contradiction. Do not invent a parallel design-system layer.\n\n### 5. Handoff\n\nFor normal frontend work, provide the relevant sections, repo evidence, and acceptance criteria. For visual-reference, image, or live-URL matching, hand off to `$visual-ralph` with the approved baseline and identify `DESIGN.md` as supporting context only.\n\n## Evidence and completion\n\nComplete only when design docs/assets/components/screenshots were inspected or noted absent; missing context is answered, assumed, or listed; root `DESIGN.md` contains every required section; recommendations cite it; and any Visual Ralph handoff is clearly separated from design governance.\n\nTask: {{ARGUMENTS}}\n","frontmatter":{"name":"design","description":"Canonical repo-local DESIGN.md workflow for product, UI/UX, and frontend decision source of truth"},"isInternal":false,"tokens":891,"sizeBytes":4351},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/doctor/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/doctor/SKILL.md","title":"doctor","category":"anthropic-skill","format":"markdown","content":"---\nname: doctor\ndescription: Diagnose and fix oh-my-codex installation issues\n---\n\n# OMX Doctor\n\nUse this task card to diagnose installation/discovery problems. Shared safety, lifecycle, hook, team, autonomy, and cancellation rules live in `templates/AGENTS.md`. `~/.codex` means `${CODEX_HOME:-~/.codex}` when `CODEX_HOME` is set.\n\n## Run diagnostics\n\n```bash\nomx doctor\nomx doctor --team # include Team runtime checks\nomx doctor --verbose # include detailed check evidence\nomx doctor --force # repair eligible repo artifact ownership issues\nomx doctor --dry-run --force # preview eligible ownership repairs\n```\n\nFor a local source checkout, build first and invoke `node dist/cli/omx.js doctor`. Keep command output and exact paths for the report.\n\n### Plugin cache and version\n\n```bash\nPLUGIN_CACHE_ROOT=\"${CODEX_HOME:-$HOME/.codex}/plugins/cache\"\nCACHE_ENTRIES=$(find \"$PLUGIN_CACHE_ROOT\" -path \"*/oh-my-codex/*\" -mindepth 3 -maxdepth 3 -type d 2>/dev/null)\nif [[ -z \"$CACHE_ENTRIES\" ]]; then\n echo \"Installed plugin cache: none\"\nelse\n while IFS= read -r d; do\n m=$(basename \"$(dirname \"$(dirname \"$d\")\")\"); v=$(basename \"$d\")\n printf 'Installed plugin cache: marketplace=%s version=%s path=%s\\n' \"$m\" \"$v\" \"$d\"\n done <<<\"$CACHE_ENTRIES\"\nfi\nLATEST=$(npm view oh-my-codex version 2>/dev/null)\necho \"Latest npm: $LATEST\"\n```\n\nNo cache is INFO (normal for npm/setup-only installs). A non-`local` cache version differing from `LATEST`, or multiple versions for one marketplace, is WARN. Plugin discovery does not replace npm installation plus `omx setup`; native/runtime wiring remains setup-owned.\n\n### Hooks, AGENTS, and skill roots\n\n```bash\nCODEX_DIR=\"${CODEX_HOME:-$HOME/.codex}\"\nls -la \"$CODEX_DIR/config.toml\" \"$CODEX_DIR/settings.json\" 2>/dev/null\nrg 'keyword-detector|persistent-mode|session-start|stop-continuation' \"$CODEX_DIR/config.toml\" \"$CODEX_DIR/settings.json\" 2>/dev/null || true\nls -la \"$CODEX_DIR/hooks\"/*.sh 2>/dev/null\nls -la \"$CODEX_DIR/AGENTS.md\" 2>/dev/null\ngrep -q \"oh-my-codex Multi-Agent System\" \"$CODEX_DIR/AGENTS.md\" 2>/dev/null && echo \"Has OMX config\" || echo \"Missing OMX config\"\nls -la \"$CODEX_DIR/agents\" \"$CODEX_DIR/commands\" \"$CODEX_DIR/skills\" \"$HOME/.agents/skills\" 2>/dev/null\n```\n\nClassify legacy hook references as **CRITICAL** (duplicate hooks). The scripts `keyword-detector.sh`, `persistent-mode.sh`, `session-start.sh`, and `stop-continuation.sh` are **WARN**. Missing AGENTS.md is **CRITICAL**; missing the OMX marker is **WARN**. `${CODEX_HOME:-~/.codex}/skills` is the canonical user root. `~/.agents/skills` is historical and overlapping trees can duplicate skill entries. OMX files under legacy `agents/` or `commands/` are **WARN**.\n\nWith `--team`, retain any `resume_blocker`, `slow_shutdown`, `delayed_status_lag`, `stale_leader`, or `orphan_tmux_session` diagnostics; failed checks set a non-zero exit status.\n\n## Report contract\n\n```text\n## OMX Doctor Report\n### Summary\n[HEALTHY / ISSUES FOUND]\n### Checks\n| Check | Status | Details |\n| Plugin Version | OK/WARN/INFO | ... |\n| Hook Config (config.toml / legacy settings.json) | OK/CRITICAL | ... |\n| Legacy Scripts (~/.codex/hooks/) | OK/WARN | ... |\n| AGENTS.md | OK/WARN/CRITICAL | ... |\n| Plugin Cache | OK/WARN | ... |\n| Legacy Agents / Commands | OK/WARN | ... |\n| Skills (canonical / historical root) | OK/WARN | ... |\n### Issues Found\n1. ...\n### Recommended Fixes\n...\n```\n\n## Remediation (after user confirmation and confirming each target is OMX-owned)\n\nRemove only confirmed OMX legacy content; preserve unrelated user files:\n\n```bash\n# If settings.json exists, remove only its legacy \"hooks\" section.\nrm -f \"$CODEX_DIR/hooks/keyword-detector.sh\" \"$CODEX_DIR/hooks/persistent-mode.sh\" \"$CODEX_DIR/hooks/session-start.sh\" \"$CODEX_DIR/hooks/stop-continuation.sh\"\nPLUGIN_CACHE_ROOT=\"${CODEX_HOME:-$HOME/.codex}/plugins/cache\"\nfind \"$PLUGIN_CACHE_ROOT\" -path \"*/oh-my-codex\" -type d -prune -exec rm -rf {} +\n```\n\nFor older curl installs, inspect first and remove only directories containing OMX-managed files:\n\n```bash\nls -la \"$CODEX_DIR/agents\" \"$CODEX_DIR/commands\" \"$CODEX_DIR/skills\" \"$HOME/.agents/skills\" 2>/dev/null\n# Optional backups:\n# mv \"$CODEX_DIR/agents\" \"$CODEX_DIR/agents.bak\"\n# mv \"$CODEX_DIR/commands\" \"$CODEX_DIR/commands.bak\"\n# mv \"$HOME/.agents/skills\" \"$HOME/.agents/skills.bak\"\nrm -rf \"$CODEX_DIR/agents\" \"$CODEX_DIR/commands\" \"$HOME/.agents/skills\"\n```\n\nIf AGENTS.md is missing/outdated, fetch the current raw file and write it to `$CODEX_DIR/AGENTS.md`:\n\n```text\nWebFetch(url: \"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/main/docs/AGENTS.md\", prompt: \"Return the complete raw markdown content exactly as-is\")\n```\n\nTo keep only the newest cache version for a selected marketplace:\n\n```bash\nPLUGIN_CACHE_DIR=\"$PLUGIN_CACHE_ROOT/$MARKETPLACE_NAME/oh-my-codex\"\nKEEP_VERSION=$(for d in \"$PLUGIN_CACHE_DIR\"/*; do [[ -d \"$d\" ]] && basename \"$d\"; done | sort -V | tail -1)\n[[ -n \"$KEEP_VERSION\" ]] && find \"$PLUGIN_CACHE_DIR\" -mindepth 1 -maxdepth 1 -type d ! -name \"$KEEP_VERSION\" -exec rm -rf {} +\n```\n\nIf AGENTS.md is missing or stale, refresh it from the current release source, then rerun `omx doctor`. If legacy `~/.agents/skills` overlaps the canonical root, archive/remove that tree only after checking for custom skills. Restart Codex after fixes and report before/after evidence.\n\n## Exit conditions\n\nStop with **HEALTHY** only when required paths, hook/config checks, AGENTS marker, plugin cache status, and (when requested) Team checks pass. Otherwise report **ISSUES FOUND**, exact failed evidence, and the smallest confirmed remediation; do not claim a fix from a recommendation alone.\n","frontmatter":{"name":"doctor","description":"Diagnose and fix oh-my-codex installation issues"},"isInternal":false,"tokens":1530,"sizeBytes":5684},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/hud/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/hud/SKILL.md","title":"hud","category":"anthropic-skill","format":"markdown","content":"---\nname: \"hud\"\ndescription: \"Show or configure the OMX HUD (two-layer statusline)\"\nrole: \"display\"\nscope: \".omx/**\"\n---\n\n# HUD Skill\n\nThe OMX HUD uses a two-layer architecture:\n\n1. **Layer 1 - Codex built-in statusLine**: Real-time TUI footer showing model, git branch, and context usage. Configured via `[tui] status_line` in `~/.codex/config.toml`. Zero code required.\n\n2. **Layer 2 - `omx hud` CLI command**: Shows OMX-specific orchestration state (ralph, ultrawork, autopilot, team, pipeline, ecomode, turns). Reads `.omx/state/` files.\n\n## Quick Commands\n\n| Command | Description |\n|---------|-------------|\n| `omx hud` | Show current HUD (modes, turns, activity) |\n| `omx hud --watch` | Live-updating display (polls every 1s) |\n| `omx hud --json` | Raw state output for scripting |\n| `omx hud --preset=minimal` | Minimal display |\n| `omx hud --preset=focused` | Default display |\n| `omx hud --preset=full` | All elements |\n\n## Presets\n\n### minimal\n```\n[OMX] ralph:3/10 | turns:42\n```\n\n### focused (default)\n```\n[OMX] ralph:3/10 | ultrawork | team:3 workers | turns:42 | last:5s ago\n```\n\n### full\n```\n[OMX] ralph:3/10 | ultrawork | autopilot:execution | team:3 workers | pipeline:exec | turns:42 | last:5s ago | total-turns:156\n```\n\n## Setup\n\n`omx setup` automatically configures both layers:\n- Adds `[tui] status_line` to `~/.codex/config.toml` (Layer 1)\n- Writes `.omx/hud-config.json` with default preset (Layer 2)\n- Default preset is `focused`; if HUD/statusline changes do not appear, restart Codex CLI once.\n\n## Layer 1: Codex Built-in StatusLine\n\nConfigured in `~/.codex/config.toml`:\n```toml\n[tui]\nstatus_line = [\"model-with-reasoning\", \"git-branch\", \"context-remaining\"]\n```\n\nAvailable built-in items (Codex CLI v0.101.0+):\n`model-name`, `model-with-reasoning`, `current-dir`, `project-root`, `git-branch`, `context-remaining`, `context-used`, `five-hour-limit`, `weekly-limit`, `codex-version`, `context-window-size`, `used-tokens`, `total-input-tokens`, `total-output-tokens`, `session-id`\n\n## Layer 2: OMX Orchestration HUD\n\nThe `omx hud` command reads these state files:\n- `.omx/state/ralph-state.json` - Ralph loop iteration\n- `.omx/state/ultrawork-state.json` - Ultrawork mode\n- `.omx/state/autopilot-state.json` - Autopilot phase\n- `.omx/state/team-state.json` - Team workers\n- `.omx/state/pipeline-state.json` - Pipeline stage\n- `.omx/state/ecomode-state.json` - Ecomode active\n- `.omx/state/hud-state.json` - Last activity (from notify hook)\n- `.omx/metrics.json` - Turn counts\n\n## Configuration\n\nHUD config stored at `.omx/hud-config.json`:\n```json\n{\n \"preset\": \"focused\"\n}\n```\n\n## Color Coding\n\n- **Green**: Normal/healthy\n- **Yellow**: Warning (ralph >70% of max)\n- **Red**: Critical (ralph >90% of max)\n\n## Troubleshooting\n\nIf the TUI statusline is not showing:\n1. Ensure Codex CLI v0.101.0+ is installed\n2. Run `omx setup` to configure `[tui]` section\n3. Restart Codex CLI\n\nIf `omx hud` shows \"No active modes\":\n- This is expected when no workflows are running\n- Start an explicitly requested supported workflow (`$autopilot` or `$ultragoal`) and check again\n","frontmatter":{"name":"hud","description":"Show or configure the OMX HUD (two-layer statusline)","role":"display","scope":".omx/**"},"isInternal":false,"tokens":919,"sizeBytes":3089},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/omx-setup/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/omx-setup/SKILL.md","title":"omx-setup","category":"anthropic-skill","format":"markdown","content":"---\nname: omx-setup\ndescription: Setup and configure oh-my-codex using current CLI behavior\n---\n\n# OMX Setup\n\nUse this task card to install or refresh OMX for the current project and/or user scope. Shared safety, lifecycle, hook, team, autonomy, and cancellation rules live in `templates/AGENTS.md`. Do not infer new CLI behavior from this card; the implementation is authoritative.\n\n## Command and alternatives\n\n```bash\nomx setup [--force] [--merge-agents|--no-merge-agents|--clear-merge-agents-policy] [--dry-run] [--verbose] [--scope <user|project>] [--plugin|--legacy|--install-mode <legacy|plugin>] [--mcp <none|compat>] [--no-mcp|--with-mcp] [--disable-team|--enable-team|--team-mode <enabled|disabled>]\nomx agents-init [path] [--dry-run] [--force] [--verbose]\n```\n\nUse `agents-init` for lightweight AGENTS.md scaffolding only, not a full install.\n\nSupported setup options:\n- `--force`: overwrite/reinstall managed artifacts; transient, not persisted or replayed.\n- `--merge-agents`, `--no-merge-agents`, `--clear-merge-agents-policy`: exact bare selectors (no values/equals). Repeated identical selectors are idempotent; conflicting selectors fail before mutations. Set persists an explicit policy per invoking project root; clear removes it and cannot combine with a set. Merge refreshes managed sections; no-merge only suppresses that branch and is not a preserve mode.\n- `--dry-run`, `--verbose`: preview actions or show per-file/per-step detail.\n- `--scope user|project`: choose user (`~/.codex`, `~/.omx/agents`) or project (`./.codex`, `./.omx/agents`) targets.\n- `--plugin` / `--legacy`: select delivery mode; `--install-mode legacy|plugin` is the canonical scripted spelling. Conflicting mode flags fail.\n- `--mcp none|compat` (plus `--no-mcp` / `--with-mcp`): omit or enable first-party MCP compatibility and shared registry sync.\n- `--disable-team`, `--enable-team`, `--team-mode enabled|disabled`: select Team skill/context generation; conflicting selectors fail.\n\n## Resolve setup\n\n1. Scope: explicit flag, valid persisted `./.omx/setup-scope.json`, TTY choice (default `user`), or non-interactive `user`. Legacy `project-local` migrates to `project`.\n2. Mode: explicit flag, persisted mode when retained, discovered `${CODEX_HOME:-~/.codex}/plugins/cache/**/.codex-plugin/plugin.json` with `name: oh-my-codex` (plugin default), otherwise legacy. TTY reruns summarize saved choices and offer keep/review/reset; non-interactive runs do not block.\n3. Create required directories and atomically persist preferences only after successful setup.\n\n## What setup changes\n\n- Legacy mode installs prompts/native agents/skills and merges full config.toml.\n- Plugin mode archives/removes legacy OMX-managed prompts/skills, refreshes installable native agent TOMLs and stale generated non-installable agents, and keeps setup-owned runtime hooks.\n- Both modes verify Team CLI interop markers in built `dist/cli/team.js`, generate AGENTS defaults only when selected/allowed, and write `./.omx/hud-config.json`; notification hook references are setup-owned outside plugin skill delivery.\n- `AGENTS.md` is `./AGENTS.md`. Without `--force` or `--merge-agents`, interactive runs ask before overwrite and non-interactive runs preserve it. Active-session safeguards may skip writes. Plugin mode may separately prompt for AGENTS and `developer_instructions` defaults; non-interactive runs preserve existing files.\n- Plugin mode enables setup-owned runtime flags (`plugin_hooks`, `goals`, or legacy `hooks`/`codex_hooks` fallback). Project scope uses `CODEX_HOME=./.codex` unless explicitly overridden.\n\n## Verify\n\n```bash\nomx setup --force --verbose\nomx doctor\n```\n\nExpect doctor evidence for prompts and skills in the selected scope, project-root AGENTS.md, `.omx/state`, and CLI-first config in the scope target `config.toml`. First-party MCP and shared registry sync are omitted unless setup used `--mcp compat` (if supported by the installed CLI).\n\nIf using local source, run `npm run build` before `node dist/cli/omx.js setup --force --verbose` and `node dist/cli/omx.js doctor`. If AGENTS was not overwritten or merged, stop the active OMX session and rerun with `--force` or `--merge-agents`; do not edit lifecycle state manually.\n\n## Discovery troubleshooting\n\nIf `$omx-setup` is absent/stale: run `omx setup --verbose`, then `omx doctor`; verify `./.codex/skills/omx-setup/SKILL.md` for project scope or `${CODEX_HOME:-~/.codex}/skills/omx-setup/SKILL.md` for legacy user scope. In plugin mode verify the oh-my-codex plugin is installed/discovered. For duplicates, inspect historical `~/.agents/skills` overlap and follow doctor/setup cleanup guidance.\n\n## Exit contract\n\nReport selected scope/mode, dry-run versus mutation, AGENTS policy, affected roots, and doctor indicators. Stop only after setup completes successfully and verification identifies the expected files/config; on failure preserve the exact command output and rerun the smallest corrective command. Do not claim installation from a dry-run alone.\n","frontmatter":{"name":"omx-setup","description":"Setup and configure oh-my-codex using current CLI behavior"},"isInternal":false,"tokens":1174,"sizeBytes":5022},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/performance-goal/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/performance-goal/SKILL.md","title":"performance-goal","category":"anthropic-skill","format":"markdown","content":"---\nname: performance-goal\ndescription: \"Run an evaluator-gated performance optimization workflow over Codex goal mode with durable OMX artifacts and safe goal handoffs.\"\n---\n\n# Performance Goal Workflow\n\nUse this skill when a user asks OMX to optimize performance and wants a goal-oriented loop rather than a one-off review.\n\n## Contract\n\n- OMX owns durable workflow state under `.omx/goals/performance/<slug>/`.\n- Codex goal mode owns only the active-thread focus/accounting primitive.\n- Shell commands do **not** mutate hidden Codex goal state. They write artifacts and emit model-facing handoff text.\n- No optimization work may start until an evaluator command and pass/fail contract exist.\n- Do not call `update_goal({status: \"complete\"})` until the evaluator has a passing checkpoint and a completion audit proves the objective is done; then call `get_goal` again and pass that fresh snapshot to `omx performance-goal complete --codex-goal-json`.\n\n## CLI\n\nCreate the workflow and evaluator contract:\n\n```sh\nomx performance-goal create \\\n --objective \"Reduce CLI startup latency by 20%\" \\\n --evaluator-command \"npm run perf:startup\" \\\n --evaluator-contract \"PASS when p95 latency improves by 20% and regression tests pass\" \\\n --slug startup-latency\n```\n\nEmit the Codex goal handoff:\n\n```sh\nomx performance-goal start --slug startup-latency\n```\n\nRecord evaluator evidence:\n\n```sh\nomx performance-goal checkpoint --slug startup-latency --status pass --evidence \"benchmark + tests passed\"\nomx performance-goal checkpoint --slug startup-latency --status fail --evidence \"benchmark regressed\"\nomx performance-goal checkpoint --slug startup-latency --status blocked --evidence \"missing fixture\"\n```\n\nComplete only after a passing checkpoint:\n\n```sh\nomx performance-goal complete --slug startup-latency --evidence \"final evaluator evidence\" --codex-goal-json <get_goal-json-or-path>\n```\n\n## Agent Loop\n\n1. Run `omx performance-goal create` if no workflow exists.\n2. Run `omx performance-goal start` and follow the handoff:\n - call `get_goal`;\n - call `create_goal` only when no active goal exists and the objective is explicit;\n - work only against the evaluator contract;\n - after evaluator pass and completion audit, call `update_goal({status: \"complete\"})`, call `get_goal` again, and pass that snapshot to `omx performance-goal complete --codex-goal-json`;\n - after `omx performance-goal complete` succeeds, run `/goal clear` in the Codex UI before starting another goal in this same thread/session; OMX prints this terminal cleanup step but does not invoke hidden clear routes;\n3. Optimize in small reversible patches.\n4. Run the evaluator and related regression tests.\n5. Record each pass/fail/blocker with `checkpoint`.\n6. Complete only when the pass artifact exists and no required work remains.\n\n## Completion Gate\n\nA performance goal is incomplete unless `.omx/goals/performance/<slug>/state.json` contains a `lastValidation.status` of `pass` and `omx performance-goal complete` receives a matching complete Codex `get_goal` snapshot via `--codex-goal-json`. Passing ordinary tests alone is not sufficient unless they are the declared evaluator contract.\n\nLifecycle: `create_goal` starts the Codex thread goal, `update_goal({status: \"complete\"})` marks terminal success after the evaluator and audit pass, and `/goal clear` removes the completed thread goal when another same-thread goal is needed. OMX shell commands and hooks reconcile snapshots and print the cleanup instruction; they must not mutate hidden Codex goal state.\n","frontmatter":{"name":"performance-goal","description":"Run an evaluator-gated performance optimization workflow over Codex goal mode with durable OMX artifacts and safe goal handoffs."},"isInternal":false,"tokens":769,"sizeBytes":3551},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/plan/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/plan/SKILL.md","title":"plan","category":"anthropic-skill","format":"markdown","content":"---\nname: plan\ndescription: Lightweight planning with optional interview\n---\n\n<Purpose>\nPlan creates concise, actionable work plans. Auto-detects interview vs direct, supports `--interview` for Socratic clarification and `--review` for evaluation.\n</Purpose>\n\n<Use_When>\n- Planning before implementation — \"plan this\", \"let's plan\"\n- Requirements are vague and need scoping — use `--interview`\n- Reviewing an existing plan — `--review`\n</Use_When>\n\n<Do_Not_Use_When>\n- Want direct execution — execute the scoped task directly; use `ultragoal` only for durable goals or `team` for coordinated parallel work\n- Simple focused fix with obvious scope — skip planning\n</Do_Not_Use_When>\n\n<Execution_Policy>\n- Auto-detect interview vs direct; `--interview` forces Socratic mode, `--direct` skips it\n- Ask one question at a time; gather codebase facts first\n- `omx explore` is deprecated. Use normal repository inspection for codebase facts; `omx sparkshell` only for explicit shell-native evidence\n- Plans must be evidence-backed: 80%+ claims cite file/line, 90%+ criteria testable\n- Right-size steps to scope; save to `.omx/plans/`\n</Execution_Policy>\n\n<Steps>\n\n### Mode Selection\n| Mode | Trigger | Behavior |\n|------|---------|----------|\n| Interview | `--interview` or broad request | Socratic requirements gathering |\n| Direct | `--direct` or detailed request | Generate plan immediately |\n| Review | `--review` | Critic evaluation of existing plan |\n\n### Interview (`--interview`)\n1. Classify request; ask one focused question via `omx question`\n2. Gather codebase facts first, then ask informed follow-ups\n3. Build on answers; consult Analyst for hidden requirements\n4. Create plan when user signals readiness\n\n### Direct\n1. Quick analysis (optional Analyst)\n2. Generate plan immediately\n3. Optional Critic review if requested\n\n### Review (`--review`)\n1. Read plan from `.omx/plans/`\n2. Evaluate via Critic; verdict APPROVED/REVISE/REJECT\n3. If author == reviewer, hand off to `$code-review`\n\n### Output\nEvery plan includes: Requirements Summary, Acceptance Criteria (testable), Implementation Steps (with file refs, adaptive count), Risks/Mitigations, Verification. Saved to `.omx/plans/`.\n\nOutcome-first framing: apply outcome-first framing, concise visible updates for multi-step planning. Local overrides for the active workflow branch apply via newer user task updates. If the user says `continue`, continue the current branch instead of restarting.\n\n</Steps>\n\n<Tool_Usage>\n- `omx explore` is deprecated. Use normal repository inspection; `omx sparkshell` only for explicit shell-native evidence\n- Use `omx question` for interview questions; plain text only as fallback\n- Use `ask_codex` with `planner`/`analyst`/`critic` as needed\n</Tool_Usage>\n\n<Escalation_And_Stop_Conditions>\n- Stop interviewing when requirements are clear — do not over-interview\n- Escalate on irreconcilable trade-offs requiring business decision\n- \"just do it\" / \"skip planning\" → hand off to `$ultragoal`\n</Escalation_And_Stop_Conditions>\n\n<Final_Checklist>\n- [ ] Acceptance criteria testable (90%+ concrete)\n- [ ] Claims cite file/line (80%+)\n- [ ] Risks have mitigations, no vague terms\n- [ ] Plan saved to `.omx/plans/`\n</Final_Checklist>\n\n<Advanced>\n## Question Classification\n| Type | Examples | Action |\n|------|----------|--------|\n| Codebase Fact | \"Where is X?\" | Explore first, do not ask |\n| User Preference | \"Priority?\" | Ask via `omx question` |\n| Scope Decision | \"Include Y?\" | Ask user |\n\n## Review Quality Criteria\n| Criterion | Standard |\n|-----------|----------|\n| Clarity | 80%+ claims cite file/line |\n| Testability | 90%+ criteria concrete |\n| Verification | File refs exist |\n</Advanced>\n","frontmatter":{"name":"plan","description":"Lightweight planning with optional interview"},"isInternal":false,"tokens":906,"sizeBytes":3706},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/ralplan/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/ralplan/SKILL.md","title":"ralplan","category":"anthropic-skill","format":"markdown","content":"---\nname: ralplan\ndescription: Consensus planning stage for Planner -> Architect -> Critic handoff to $ultragoal\n---\n\n# Ralplan (Consensus Planning Alias)\n\nRalplan is the canonical consensus-planning stage used by Autopilot between `$deep-interview` and `$ultragoal`. It drives Planner, Architect, and Critic planning and records their review lifecycle with **RALPLAN-DR structured deliberation** (short mode by default, deliberate mode for high-risk work). Local lifecycle evidence is not host-issued security authority, but ordinary progression to Ultragoal must remain reachable after the execution-ready plan and sequential review evidence are durable; missing host provenance must not terminalize Ralplan or block cancel, clear, or recovery.\n\n## Usage\n\n```\n$ralplan \"task description\"\n```\n\nStandalone advisory planning is explicitly opt-in:\n\n```text\n$ralplan --advisory \"task description\"\n```\n\nAdvisory runs the same sequential Planner → Architect → Critic review lifecycle, binds the plan and both review artifacts to exact bytes and one tracker-backed iteration, then returns to the caller with `active:false`. It is a cooperative workflow pause, not a security fence or permission system. It never emits a `PreToolUse` allow/block decision, never completes the host consensus gate, never authorizes execution, and never suppresses unrelated host behavior. Terminal state must carry explicit `false` values for the consensus gate, host verification, and execution handoff rather than omitting them. A later concrete affirmative execution request may produce non-authoritative routing context, but it does not persist a permission, rewrite terminal evidence, or create an automatic handoff; quotations, code, examples, documentation, questions, modal requests, negations, and vague approval remain classifier negatives. `approved+proven` requires complete lifecycle digests plus post-write revalidation. Administrative abandonment is append-only, idempotent for prepared or committed journals, and records a separate byte-bound admin event without rewriting the original closeout journal. Real enforcement requires an explicit host-issued, host-verified receipt or capability on a non-user-mintable surface; local Advisory files, prompts, session/thread fields, tracker records, and HERDR observability cannot substitute for it. On Darwin, each Advisory evidence artifact is limited to 128 KiB by the pinned-directory reader; other supported platforms allow up to 8 MiB.\n\n## Flags\n\n- `--interactive`: Enables user prompts at key decision points (draft review in step 2 and final approval in step 6). Without this flag the workflow runs fully automated — Planner → Architect → Critic loop — and outputs the final plan without asking for confirmation.\n- `--deliberate`: Forces deliberate mode for high-risk work. Adds pre-mortem (3 scenarios) and expanded test planning (unit/integration/e2e/observability). Without this flag, deliberate mode can still auto-enable when the request explicitly signals high risk (auth/security, migrations, destructive changes, production incidents, compliance/PII, public API breakage).\n- `--advisory`: Standalone only. It cannot be combined with Autopilot, Pipeline, Team, Ralph, Ultragoal, execution flags, or unknown flags. Activation requires canonical session, root thread, and turn identity.\n\n## Ontology-heavy review\n\nFor requirements semantics, taxonomy, prompt/spec design, policy distinctions, or category-risk architecture, cite the `architect` role agent's read-only review as advisory evidence. Its findings can inform the plan or follow-up evidence when explicitly used, but `$ralplan` itself records Architect→Critic lifecycle evidence only, and advisory review is never a durable execution authorization.\n\n## Usage with interactive mode\n\n```\n$ralplan --interactive \"task description\"\n```\n\n## Behavior\n\n## GPT-5.6 Guidance Alignment\n\nUse the shared workflow guidance pattern: outcome-first framing, concise visible updates for multi-step planning, local overrides for the active workflow branch, evidence-backed planning and validation expectations, explicit stop rules, right-sized implementation/PRD shape, and automatic continuation for safe reversible steps. Ask only for material, destructive, credentialed, external-production, or preference-dependent branches.\n\nThis skill runs its own consensus runtime; it does not delegate to a nonexistent Plan consensus mode:\n\n```\nomx ralplan run --task <arguments> [--session <id>]\n```\n\nThe consensus workflow:\n1. **Planner** creates an adaptive plan (right-sized to task scope; do not default to exactly five steps) and a compact **RALPLAN-DR summary** before review. Current `[main]` vs `[planner]` behavior: standalone `$ralplan` may be authored by the active main planning lane unless the caller/runtime supplies a dedicated planner routing record; inside `$autopilot`, state field `planning_routing.owner:\"planner\"` means the initial Planner draft/decomposition must use dedicated `[planner]`. Set `.omx-config.json` `agentModels.planner` to opt into a specific planner model and force dedicated planner ownership for complex Autopilot planning even when `[main]` is not cheap/mini. The RALPLAN-DR summary includes:\n - Principles (3-5)\n - Decision Drivers (top 3)\n - Viable Options (>=2) with bounded pros/cons\n - If only one viable option remains, explicit invalidation rationale for alternatives\n - Deliberate mode only: pre-mortem (3 scenarios) + expanded test plan (unit/integration/e2e/observability)\n2. **User feedback** *(--interactive only)*: If `--interactive` is set, use the structured question UI (`omx question` in attached tmux; native structured input outside tmux when available) to present the draft plan **plus the Principles / Drivers / Options summary** before review (Proceed to review / Request changes / Skip review). Otherwise, automatically proceed to review.\n**Native role-routing preflight:** Keyword routing may already have selected Ralplan, but it is not authority. Run `omx ralplan preflight --json` only when the native task surface reports `role_routing_unavailable` and this workflow attempts adapted Ralplan Planner, Architect, or Critic authority, adapted role-intent, or adapted consensus authority. On `unsupported_documented_leader_proof`, stop before that adapted authority and use a Codex surface with documented root proof or a reviewed alternative workflow. Do not infer root identity from `session_id`, undocumented `thread_id`, session/pointer/transcript/cwd state, absence of child data, or a prompt label. Ordinary native planning, lifecycle, state, status, health, HUD, runtime, setup, install, sync, and unrelated delegation are outside this preflight boundary and remain governed by existing controls.\n\n**Native role-routing rule:** When the native surface exposes `agent_type` role routing, set `agent_type` to an installed OMX role and never omit it for OMX work. When it does not (`role_routing_unavailable`), do not fabricate `agent_type`. On the exact reviewed Codex releases 0.144.5, 0.145.0, 0.146.1, and 0.148.0-alpha.5, adapted Ralplan Planner, Architect, Critic, role-intent, and consensus authority are unavailable because they lack documented root proof; every other version remains unknown and fails closed. Do not silently weaken routing with a prompt role label or inferred carrier. Use a Codex surface with documented root proof or a reviewed alternative workflow for that authority. A direct `omx ralplan role-intent write` attempt is denied with machine reason `unsupported_documented_leader_proof`.\n\n3. **Architect** reviews for architectural soundness and must provide the strongest steelman antithesis, at least one real tradeoff tension, and (when possible) synthesis — **await completion before step 4**. Launch this as a subsequent role-specific `Architect` subagent and pass the full task statement, context snapshot, PRD/test-spec paths, and relevant prior findings; do not substitute an unvalidated reviewer identity or a short improvised reviewer prompt. In deliberate mode, Architect should explicitly flag principle violations.\n4. **Critic** evaluates against quality criteria — run only after step 3 completes. Launch this as a subsequent role-specific `Critic` subagent with the full task statement, context snapshot, PRD/test-spec paths, and the completed Architect review; do not ask the Architect subagent to perform the Critic gate and do not substitute an unvalidated reviewer identity or a short improvised reviewer prompt. Critic must enforce principle-option consistency, fair alternatives, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. In deliberate mode, Critic must reject missing/weak pre-mortem or expanded test plan.\n5. **Re-review loop** (max 5 iterations): Any non-`APPROVE` Critic verdict (`ITERATE` or `REJECT`) MUST run the same full closed loop:\n a. Collect Architect and Critic feedback\n b. Revise the plan with Planner\n c. Return to Architect review\n d. Return to Critic evaluation\n e. Repeat this loop until Critic returns `APPROVE` or 5 iterations are reached\n f. If 5 iterations are reached without `APPROVE`, present the best version to the user\n6. On Critic approval, persist the execution-ready planning artifacts and sequential Architect→Critic evidence. In standalone interactive Ralplan, present the requested future execution lane. Inside Autopilot, the existing explicit `$autopilot` invocation authorizes the supervised transition to its defining next stage, `$ultragoal`; persist an Autopilot-owned `ralplan_execution_handoff` bound to the same session and review cycle.\n7. Record `ralplan_execution_handoff` with `{authorized: true, reason, authorized_at, session_id, review_cycle, source: \"autopilot\"|\"user\"}`. `source:\"autopilot\"` is valid only for a supervised active Autopilot run whose current phase is `ralplan`; it does not claim host-consensus authority.\n8. Transition to `$ultragoal` after the durable plan, sequential approvals, and bound execution handoff exist. Do not implement directly inside Ralplan.\n\n> **Important:** Steps 3 and 4 MUST run sequentially as role-specific subagents. Do NOT issue both agent calls in the same parallel batch. Always await the subsequent `Architect` result before invoking the subsequent `Critic`; their completed approvals establish local lifecycle evidence only and cannot satisfy the durable execution gate.\n\n## Planning/Execution Boundary\n\n`$ralplan` is a planning mode. While ralplan is active and no explicit execution handoff is active, implementation-focused write tools are out of scope. Ralplan may inspect the repository and may write only planning artifacts such as `.omx/context/`, `.omx/plans/`, `.omx/specs/`, and required `.omx/state/` records.\n\nThe canonical flow is:\n\n```\n$ralplan -> local Architect→Critic lifecycle evidence -> bound execution handoff -> $ultragoal\n```\n\nBefore any execution lane begins, ralplan must emit terminal planning state (complete, paused, failed, or waiting for input) and the durable handoff record below. Do not continue from consensus planning into direct code edits in the same ralplan session.\n\n## Durable Consensus Handoff Contract\n\nRalplan is not complete, skippable, or ready for execution merely because `.omx/plans/prd-*.md` and `.omx/plans/test-spec-*.md` exist. Those files are planning artifacts, not consensus evidence.\n\nBefore any Autopilot, Ultragoal, Team, or implementation handoff, persist a durable handoff record that distinguishes:\n\n- `planning_artifacts`: PRD/test-spec paths.\n- `ralplan_architect_review`: the completed Architect review with an approving verdict.\n- `ralplan_critic_review`: the completed Critic review with an approving verdict, recorded only after the Architect review.\n- `ralplan_execution_handoff`: persist `{authorized: true, reason: \"<rationale>\", authorized_at: \"<ISO timestamp>\", session_id: \"<current session>\", review_cycle: <matching lifecycle cycle>, source: \"autopilot\"|\"user\"}`. Autopilot may issue this only for its own supervised `ralplan` phase; standalone Ralplan uses `source:\"user\"`.\n- `ralplan_consensus_gate.complete` records lifecycle completion after the sequential Architect and Critic approvals. It is not a host-security claim. Locally authored JSON/env/prompt/tracker/transcript/receipt-shaped evidence must never be described as host-issued authority.\n\nIf Architect is missing/blocked, keep the workflow in Architect review or report that blocker. If Critic is missing/blocked/non-approving, keep the workflow in Critic/re-review or report the max-iteration outcome. After both reviews approve, execution begins only when the matching `ralplan_execution_handoff` is durable. Existing plan/test-spec files alone are never permission to skip Ralplan or execute.\n\nFollow the Plan skill's full documentation for consensus mode details.\n\n## Goal-Mode Follow-up Suggestions\n\nWhen a bound `ralplan_execution_handoff` permits execution, include product-facing goal-mode suggestions alongside coordinated Team execution. Record the requested lane and persist the handoff without claiming host-issued authority.\n\n- `$ultragoal` — **default goal-mode follow-up** for implementation or general goal-oriented follow-up plans that should become durable Codex/OMX goals with sequential completion tracking.\n- `$autoresearch` — research-project follow-up when the plan centers on a question, literature/reference gathering, evaluator-backed research, or a professor/critic-style research deliverable. (`$autoresearch-goal` was retired to a sunset stub in OMX 0.21.)\n- `$performance-goal` — optimization/performance follow-up when the plan centers on speed, latency, throughput, memory, benchmark, or other measurable performance work.\n\nUse `$ultragoal` for durable goal tracking and `$team` for coordinated parallel implementation. When combined, Ultragoal owns the ledger and Team returns checkpoint-ready execution evidence.\nUse the available-agent-types roster to produce explicit role/staffing allocation, reasoning-by-lane guidance, concrete launch hints (including `omx team` when parallel delivery is justified), and team verification responsibilities for any future receipt-authorized execution path.\n\n## Pre-context Intake\n\nBefore consensus planning or execution handoff, ensure a grounded context snapshot exists:\n\n1. Derive a task slug from the request.\n2. Reuse the latest relevant snapshot in `.omx/context/{slug}-*.md` when available.\n3. If none exists, create `.omx/context/{slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`) with:\n - task statement\n - desired outcome\n - known facts/evidence\n - constraints\n - unknowns/open questions\n - likely codebase touchpoints\n4. If ambiguity remains high, gather brownfield facts first. `omx explore` is deprecated; use normal repository inspection tools/subagents for simple read-only repository lookups and `omx sparkshell` only for explicit shell-native read-only evidence. Then run `$deep-interview --quick <task>` before continuing.\n5. If the plan depends on official docs, version-aware framework guidance, best practices, or external dependency behavior, use `$best-practice-research` as the bounded evidence wrapper and auto-delegate `researcher` for the official/upstream lookup before finalizing the planning handoff so execution does not start from repo-local recall alone.\n6. If a prior `$autoresearch` run exists, treat its approved artifact as evidence for the plan. Read historical artifacts from `$autoresearch-goal` only as compatibility input. Do not include Autoresearch as a final architecture or runtime component unless the user explicitly requested ongoing research automation; otherwise synthesize the evidence into the `$ralplan` ADR, risks, and verification steps.\n\nDo not hand off to execution modes until this intake is complete; if urgency forces progress, explicitly document the risk tradeoffs.\n\n## Routing boundary\n\nOrdinary scoped tasks stay in the direct execution lane described by `templates/AGENTS.md`.\nExplicit workflow requests follow the keyword registry (`src/hooks/keyword-registry.ts`) and their owning skill contracts; this card does not define a second activation table.\nOnce Ralplan is active, preserve the planning/execution and consensus handoff requirements above. A conversational “just do it” is not a substitute for the required review evidence.\n\n## Scenario Examples\n\n**Good:** The user says `continue` after the workflow already has a clear next step. Continue the current branch of work instead of restarting or re-asking the same question.\n\n**Good:** The user changes only the output shape or downstream delivery step (for example `make a PR`). Preserve earlier non-conflicting workflow constraints and apply the update locally.\n\n**Bad:** The user says `continue`, and the workflow restarts discovery or stops before the missing verification/evidence is gathered.\n","frontmatter":{"name":"ralplan","description":"Consensus planning stage for Planner -> Architect -> Critic handoff to $ultragoal"},"isInternal":false,"tokens":3558,"sizeBytes":16945},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/skill/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/skill/SKILL.md","title":"skill","category":"anthropic-skill","format":"markdown","content":"---\nname: skill\ndescription: Manage local skills - list, add, remove, search, edit, setup wizard\nargument-hint: \"<command> [args]\"\n---\n\n# Skill Management\n\nManage local `SKILL.md` files with `/skill` commands. Shared execution, delegation,\nstate, hook, team, cancellation, verification, and escalation invariants live in\n`templates/AGENTS.md`; follow that contract instead of repeating it here.\n\n<Purpose>\nCreate, inspect, validate, update, and organize user- or project-scoped skills.\nKeep each skill specific, actionable, evidence-based, and useful to this codebase.\n</Purpose>\n\n<Use_When>\n- The user asks to list, add, edit, remove, search, inspect, sync, set up, scan, or validate skills.\n- A durable, codebase-specific solution or workflow should be captured as a skill.\n</Use_When>\n\n<Do_Not_Use_When>\n- Use `/learner` to extract a skill from a conversation and `/note` for a short note.\n- Do not use this prompt to change runtime code, catalogs, hooks, or installation logic.\n</Do_Not_Use_When>\n\n## Scopes and commands\n\nCanonical roots are `${CODEX_HOME:-$HOME/.codex}/skills/` (user) and `.codex/skills/`\n(project). A skill lives at `<root>/<name>/SKILL.md`.\n\n| Command | Contract |\n|---|---|\n| `/skill list` | Scan both roots, parse frontmatter, and show name, description, triggers, scope, and quality/usage (`N/A` when unavailable). |\n| `/skill add [name]` | Run the authoring wizard, validate the name, choose scope, create `SKILL.md`, and report its path. |\n| `/skill edit <name>` | Find one scope, show metadata, then update description, triggers, argument hint, body, or rename and report the change. |\n| `/skill remove <name>` | Find the skill, show scope and metadata, confirm explicitly, then remove its directory. |\n| `/skill search <query>` | Case-insensitively search name, description, triggers, and body; rank name/trigger matches first and show context. |\n| `/skill info <name>` | Show parsed metadata, scope, path, and full body; suggest `/skill search` when absent. |\n| `/skill sync` | Compare user/project skills, show user-only/project-only/common entries, and confirm every copy or overwrite. |\n| `/skill setup` | Ensure both roots exist, scan them, then offer add, list, pattern scan, import, or done. |\n| `/skill scan` | Run setup's scan/inventory without its interactive menu. |\n| `/skill validate` | Validate every skill in both roots and report each path's pass/fail result; never rewrite files. |\n\nWith an argument, use direct command mode; without one, use the guided setup menu.\n\n## Authoring contract\n\nAsk for any missing values:\n1. `name`: lowercase letters/digits separated by single hyphens (`[a-z0-9]+(?:-[a-z0-9]+)*`).\n2. `description`: a concise, non-empty one-line purpose.\n3. `triggers`: comma-separated recognition terms.\n4. `argument-hint`: optional invocation arguments.\n5. `scope`: `user` or `project`.\n\nWrite this frontmatter at the start of every skill; optional metadata may add `id`,\n`source`, and `quality` without replacing required fields:\n\n```yaml\n---\nname: <name>\ndescription: <one-line purpose>\ntriggers: [<trigger1>, <trigger2>]\nargument-hint: \"<args>\"\n# optional: id, source, quality\n---\n```\n\nUse an actionable body. The minimum recommended shape is:\n\n```markdown\n# <Skill title>\n\n## Purpose\nWhat durable, codebase-specific outcome does this skill provide?\n\n## When to Activate\nRecognition signals, scope, and explicit non-goals.\n\n## Workflow\n1. Inspect the named files or inputs.\n2. Apply the precise approach and record important assumptions.\n3. Verify observable behavior and report evidence.\n\n## Examples / Gotchas\nConcrete invocation, edge cases, and failure recovery.\n```\n\nPrefer hard-won, non-obvious knowledge over generic programming advice. Include\nexact paths, commands, error text, and expected evidence when they materially help.\n\n## Validation and errors\n\nBefore reporting success, check that the file exists, starts with `---` frontmatter,\nhas non-empty `name` and `description`, uses a valid name, and has a non-empty body.\nReject malformed or unterminated YAML, multiline required scalar values, duplicate\nnames in one scope, missing directories/files, permission failures, and invalid\narguments. Report errors consistently:\n\n```text\n✗ Error: <clear message>\n→ Suggestion: <specific next step>\n```\n\n## Exit contract\n\nEvery command ends with one concise result: `✓` plus the affected skill/path and\nnext action, or `✗` plus the error and suggestion. Preserve files on cancel or\nvalidation-only runs. For add/edit/sync, report changed scope and metadata; for\nlist/search/info/scan/validate, report counts or matched paths and any failures.\n","frontmatter":{"name":"skill","description":"Manage local skills - list, add, remove, search, edit, setup wizard","argument-hint":"<command> [args]"},"isInternal":false,"tokens":1098,"sizeBytes":4624},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/team/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/team/SKILL.md","title":"team","category":"anthropic-skill","format":"markdown","content":"---\nname: team\ndescription: N coordinated agents on shared task list using tmux-based orchestration\n---\n\n# Team Skill\n\n## When to use\n\nUse only for an explicit `$team` request or `omx team ...` launch that benefits from durable tmux workers, shared task state, mailbox coordination, or worktree isolation. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot`; do not copy its durable rules into this card.\n\n## Inputs and preconditions\n\n- Launch shape: `omx team [N:agent-type] \"<task>\"` (for example `omx team 3:executor \"implement X\"`).\n- Require `tmux -V`, a leader session with `$TMUX`, and the intended `omx` executable. In Codex App/plain non-tmux sessions, explain the runtime boundary instead of pretending Team is available.\n- Before launch, ground the task in a recent `.omx/context/{slug}-*.md`; create a concise snapshot when none exists. Include target, evidence, constraints, unknowns, and likely touchpoints.\n- Do not launch nested Team runs. Pick worker roles deliberately; use `OMX_TEAM_WORKER_CLI=codex|claude|auto` or `OMX_TEAM_WORKER_CLI_MAP=...` only when needed.\n- Per-agent reasoning is set by `agentReasoning`; accepted values are `low`, `medium`, `high`, `xhigh`, and `max`. `max` is passed unchanged and remains capability-dependent. `ultra` is unsupported and is not an alias for `max`.\n- Invalid configured values use the built-in role-default fallback. An explicit raw `-c model_reasoning_effort=...` is opaque and wins. When both sources are present, explicit raw reasoning wins over inherited Team reasoning and environment reasoning. Do not downgrade or retry `max` as `xhigh`; built-in role defaults remain unchanged.\n\n## Operational steps\n\n1. Start the runtime and capture startup evidence: `Team started: <name>`, tmux target, worker panes, and the leader ACK mailbox.\n2. **Current Runtime Behavior:** runtime-owned task files and APIs are the operational interface; the durable ownership and safety rules remain in `templates/AGENTS.md`.\n3. Runtime creates `.omx/state/team/<name>/config.json`, `manifest.v2.json`, `tasks/task-<id>.json`, worker identities/inboxes, mailbox files, and a dispatch queue. Workers receive `OMX_TEAM_WORKER`, `OMX_TEAM_STATE_ROOT`, and `OMX_TEAM_LEADER_CWD`.\n4. Deliver assignments through durable inbox/task state and the CLI API. The worker card defines ACK, claim, transition, mailbox, and idle-status commands.\n5. Prefer these machine-readable operations:\n ```bash\n omx team api send-message --input '{\"team_name\":\"<name>\",\"from_worker\":\"leader-fixed\",\"to_worker\":\"worker-1\",\"body\":\"<short trigger>\"}' --json\n omx team api read-task --input '{\"team_name\":\"<name>\",\"task_id\":\"<id>\"}' --json\n omx team api transition-task-status --input '{\"team_name\":\"<name>\",\"task_id\":\"<id>\",\"from\":\"in_progress\",\"to\":\"completed\",\"claim_token\":\"<token>\"}' --json\n ```\n6. Monitor with `omx team status <name> --json` or `omx team await <name> --timeout-ms 30000 --json`; inspect mailbox/state files when a worker is blocked or stale.\n7. Keep the team running until `pending=0`, `in_progress=0`, and `failed=0` (or an explicitly acknowledged failure path). Run `omx team shutdown <name>` only then, unless the user explicitly aborts.\n8. Verify shutdown evidence and state cleanup. Do not claim completion while workers are still writing.\n\n## Team and Ultragoal\n\nWhen a leader-owned `.omx/ultragoal/goals.json` exists, workers return task evidence only. The leader checkpoints with a fresh Codex `get_goal` snapshot:\n```bash\nomx ultragoal checkpoint --goal-id <id> --status complete --evidence \"<Team evidence>\" --codex-goal-json <fresh-get-goal-json-or-path>\n```\nTeam launch remains an explicit separate action; it does not create hidden Codex goals.\n\n## Dispatch and recovery\n\n- If dispatch reports `worker_notify_failed:<worker>`, inspect `tmux list-panes`, capture the pane, then send one concise trigger and re-check mailbox/state.\n- For Claude panes, do not spam Enter while work is active. Confirm runtime status first.\n- If a worker reports `omx team api ... ENOENT`, check whether shutdown or state deletion happened too early; preserve state until all transitions finish.\n- For a clean retry, kill only known stale worker panes, remove only the exact stale Team root, and relaunch; never kill the leader/HUD pane accidentally.\n\n## Exit and evidence\n\nReport team name, launch command, pane/ACK evidence, task counts, worker verification, failures or blockers, shutdown result, and cleaned state paths. Include any worktree or CLI-map choices and keep final integration/verification in the leader lane.\n","frontmatter":{"name":"team","description":"N coordinated agents on shared task list using tmux-based orchestration"},"isInternal":false,"tokens":1092,"sizeBytes":4575},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/ultragoal/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/ultragoal/SKILL.md","title":"ultragoal","category":"anthropic-skill","format":"markdown","content":"---\nname: ultragoal\ndescription: Create and execute durable repo-native multi-goal plans over Codex goal mode artifacts.\n---\n\n# Ultragoal Workflow\n\n## When to use\n\nUse for `ultragoal`, `create-goals`, `complete-goals`, durable multi-goal planning, or sequential execution over Codex `/goal`. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot` for state ownership and goal-tool boundaries.\n\n## Inputs and preconditions\n\n- Durable artifacts are `.omx/ultragoal/brief.md`, `.omx/ultragoal/goals.json`, and `.omx/ultragoal/ledger.jsonl`.\n- New plans use aggregate Codex goal mode by default: one stable pointer objective for the plan while OMX tracks individual stories. Use `--codex-goal-mode per-story` only when explicitly requested.\n- Do not call `/goal clear` from shell or this skill. After a completed run, the operator may clear the interactive Codex goal in the Codex UI before another same-thread run.\n\n## Operational steps: create\n\nRun one command, then inspect the generated plan:\n```bash\nomx ultragoal create-goals --brief \"<brief>\"\nomx ultragoal create-goals --brief-file <path>\ncat <brief> | omx ultragoal create-goals --from-stdin\nomx ultragoal create-goals --codex-goal-mode per-story --brief \"<brief>\"\n```\nIf refinement is needed, use explicit supported steering rather than editing durable artifacts by hand.\n\n## Operational steps: execute\n\nRepeat until `omx ultragoal status` reports all goals complete:\n\n1. Run `omx ultragoal complete-goals` and read its handoff.\n2. Call `get_goal`. Call `create_goal` with the printed payload only when no active Codex goal exists; otherwise continue the matching aggregate objective.\n3. Complete one OMX story and audit its objective against real artifacts and verification evidence.\n4. For intermediate aggregate stories, keep the Codex goal active and checkpoint:\n ```bash\n omx ultragoal checkpoint --goal-id <id> --status complete --evidence \"<evidence>\" --codex-goal-json <fresh-get-goal-json-or-path>\n ```\n5. For a blocked/failed story, use `--status blocked|failed` with evidence; resume failed work with `omx ultragoal complete-goals --retry-failed`.\n6. On the final story, complete the final gate below before `update_goal({status: \"complete\"})`; then call `get_goal` again and checkpoint the fresh complete snapshot.\n\n## Explicit steering\n\nUse evidence-backed directives only when the decomposition must change:\n```bash\nomx ultragoal steer --kind add_subgoal --title \"<title>\" --objective \"<objective>\" --evidence \"<evidence>\" --rationale \"<reason>\" --json\nomx ultragoal steer --directive-json ./steering.json --json\n```\nSupported kinds: `add_subgoal`, `split_subgoal`, `reorder_pending`, `revise_pending_wording`, `annotate_ledger`, and `mark_blocked_superseded`. Ordinary prose does not mutate the plan; repeated structured directives dedupe.\n\n## Phase/HUD handoff\n\nAt standalone activation, declare the smallest accurate phase (`planning`, `executing`, `verifying`, `reviewing`, `checkpointing`, or `blocked`):\n```bash\nomx state write --input '{\"mode\":\"ultragoal\",\"active\":true,\"current_phase\":\"planning\"}' --json\n```\nInside Autopilot, keep the parent mode active and set `current_phase:\"ultragoal\"`; persist Ultragoal evidence under `handoff_artifacts.ultragoal` before a code-review handoff. Mark standalone Ultragoal complete only when every durable goal is complete.\n\n## Optional Team bridge\n\nFor parallel story execution, use the separate Team command. The leader records the Ultragoal checkpoint with a fresh `get_goal` snapshot; see the Team skill for the bridge details.\n\n## Final gate and exit evidence\n\nBefore final completion:\n\n1. Run targeted story verification.\n2. Run `ai-slop-cleaner` on changed files, then rerun verification.\n3. Audit every architecture/domain invariant from the brief/spec/accepted steering against implementation, test, and review evidence.\n4. Run `$code-review` through independent `code-reviewer` and `architect` lanes. If review or invariant proof is not clean, do not update the Codex goal; record durable blockers:\n ```bash\n omx ultragoal record-review-blockers --goal-id <id> --title \"Resolve final code-review blockers\" --objective \"<objective>\" --evidence \"<findings>\" --codex-goal-json <active-get-goal-json-or-path>\n ```\n5. If clean, call `update_goal({status: \"complete\"})`, call `get_goal`, and checkpoint with `--quality-gate-json` containing cleaner, verification, review, and architecture-invariant evidence.\n\nReport goal ids/statuses, ledger/checkpoint paths, fresh goal snapshot evidence, review verdicts, and any blocker. Never claim completion from OMX state alone.\n","frontmatter":{"name":"ultragoal","description":"Create and execute durable repo-native multi-goal plans over Codex goal mode artifacts."},"isInternal":false,"tokens":1081,"sizeBytes":4606},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/ultraqa/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/ultraqa/SKILL.md","title":"ultraqa","category":"anthropic-skill","format":"markdown","content":"---\nname: ultraqa\ndescription: Adversarial dynamic e2e QA workflow - generate hostile scenarios, test, verify, fix, report, and clean up\n---\n\n# UltraQA Task Card\n\nUse this explicit opt-in when a runnable behavior needs adversarial dynamic end-to-end\nQA. Shared operating invariants live in `templates/AGENTS.md`; this card defines the\nQA matrix, evidence contract, and bounded cycling only.\n\n## When to use and inputs\n\n- Use `/ultraqa --tests|--build|--lint|--typecheck|--interactive` or `/ultraqa --custom \"pattern\"` for the corresponding goal; without a structured goal, derive a runnable behavior goal.\n- Inputs: goal, changed scope, acceptance criteria, runnable command/service, existing tests, and relevant state/cleanup paths.\n- Keep outcome-first framing, local overrides for the active workflow branch, and `continue` on the current verified next step.\n- If the user says `continue`, advance the current verified QA step rather than restarting discovery.\n- UltraQA is not satisfied by a shallow build/lint/typecheck/test checklist: exercise requested behavior through adversarial dynamic e2e scenarios whenever it can be run, simulated, or harnessed safely.\n\n## Plan and scenario matrix\n\nBefore commands, record a matrix with scenario id, intent, user/attacker model, setup,\ncommand or harness, expected signal, actual result, fixes, evidence, and cleanup.\nInclude a normal path and relevant hostile classes:\n\n1. **Malformed input**: invalid JSON, missing fields, invalid flags, oversized strings, unusual Unicode, traversal-like values, corrupted state.\n2. **Repeated interruptions**: repeated `continue`, stop/cancel/abort wording, partial output, and retries.\n3. **Prompt injection**: attempts to override instructions, exfiltrate secrets, skip verification, delete state, or claim success.\n4. **Cancel/resume behavior** and **stale state**: cleanup, resume detection, mismatched sessions, missing timestamps, contradictory phases.\n5. **Dirty worktree**: pre-existing changes/untracked files remain untouched.\n6. **Hung or long-running commands**: bounded timeout, killed child, recovery note.\n7. **Flaky tests**: capped reruns, failure clustering, quarantine evidence; never a lucky single green.\n8. **Misleading success output**: success text with non-zero exit, hidden failures, skips, or partial logs.\n\n## Cycle (maximum 5)\n\n1. **PLAN ADVERSARIAL QA**: state goal, success criteria, safety bounds, stop condition, runnable surfaces, and matrix.\n2. **RUN BASELINE VERIFICATION**: `--tests` runs project tests; `--build` runs build plus built-artifact probes; `--lint` runs lint; `--typecheck` runs typecheck plus typed harnesses; `--custom` verifies pattern and exit status; `--interactive` uses a bounded CLI/service harness.\n3. **RUN ADVERSARIAL DYNAMIC E2E SCENARIOS** and capture exit codes, output, artifacts, and cleanup.\n4. **CHECK RESULT**: pass only when baseline, adversarial scenarios, evidence, and cleanup all pass. Otherwise diagnose and fix, then repeat.\n5. **ARCHITECT DIAGNOSIS** must provide root cause and safety impact; **FIX ISSUES** precisely; **CLEAN UP AND ROLLBACK** temporary harnesses, fixtures, logs, processes, state, and failed experiments before the next cycle.\n\nGenerate temporary tests, scripts, fixtures, or harnesses only when useful. Use bounded runtimes,\nproject-native tools, and safe substitutes when a safety boundary blocks a scenario.\nUse absolute repo imports and `pathToFileURL(join(repoRoot, \"dist\", ...)).href`; Never rely on `./dist` from `/tmp`.\nUse a safe file writer with a non-interpolating file-write mechanism; do not use interpolating heredocs for JavaScript assertions.\nSanitize OMX runtime env for isolated probes: keep `OMX_ROOT` and `OMX_STATE_ROOT` unset and run `env -u OMX_ROOT -u OMX_STATE_ROOT`.\nClassify harness setup failures separately: record it as harness debris, fix the harness, and rerun the scenario before declaring a product defect.\n\n## Safety, state, and exit\n\nNo destructive commands, secret exfiltration, credential dumping, production writes, or unbounded process spawning. Use no unbounded waits; preserve unrelated dirty work. If a scenario is unsafe, record it blocked and the safe substitute. Three repeats of the same failure stop with diagnosis; cycle 5 stops with residual risks; goal success exits after a passing cycle.\n\nUse CLI-first lifecycle state and exact commands:\n\n```sh\nomx state write --input '{\"mode\":\"ultraqa\",\"active\":true,\"current_phase\":\"planning\",\"iteration\":1,\"started_at\":\"<now>\",\"scenario_matrix\":[]}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"current_phase\":\"qa\",\"iteration\":<cycle>,\"scenario_matrix\":\"<updated matrix path or summary>\"}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"current_phase\":\"adversarial-e2e\"}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"current_phase\":\"diagnose\"}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"current_phase\":\"fix\"}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"current_phase\":\"cleanup\"}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"active\":false,\"current_phase\":\"complete\",\"completed_at\":\"<now>\"}' --json\nomx state read --input '{\"mode\":\"ultraqa\"}' --json\nomx state clear --input '{\"mode\":\"ultraqa\"}' --json\n```\n\nOn completion, max cycles, same failure, safety boundary, or environment error, clean\nstate and temporary artifacts. Report cleanup status and clean temporary e2e harnesses.\nNever claim complete without current evidence.\n\n## Evidence/output contract\n\nReturn `# UltraQA Report` with: **Goal and success criteria** (including stop condition\nand safety bounds); **Scenario matrix** (all columns above); **Commands run** (exit code,\npurpose, timeout, key output); **Failures found** (root/user/safety impact); **Fixes\napplied** / **Fixes applied** (files, rationale, scenarios, regression evidence); **Cleanup and rollback**\n(artifacts/processes/worktree before/after); **Residual risks**; and **Evidence**\n(logs, harness output, screenshots/transcripts where relevant, rerun/flake evidence).\n\n## Exit condition\n\n`ULTRAQA COMPLETE: Goal met after N cycles` only follows a passing baseline plus\nadversarial matrix, clean artifacts, and complete evidence. Otherwise return the exact\nbounded status: `ULTRAQA STOPPED: Max cycles`, `ULTRAQA STOPPED: Same failure detected 3 times`,\n`ULTRAQA BLOCKED: ...`, or `ULTRAQA ERROR: ...` with owner and next safe step.\n","frontmatter":{"name":"ultraqa","description":"Adversarial dynamic e2e QA workflow - generate hostile scenarios, test, verify, fix, report, and clean up"},"isInternal":false,"tokens":1472,"sizeBytes":6370},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/visual-ralph/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/visual-ralph/SKILL.md","title":"visual-ralph","category":"anthropic-skill","format":"markdown","content":"---\nname: visual-ralph\ndescription: \"Visual Ralph orchestration for frontend UI from generated references, static references, or live URL targets, using $ultragoal with built-in visual verdict and pixel-diff evidence until the implementation matches and leaves a reproducible design system.\"\n---\n\n# Visual Ralph Skill\n\nUse `$visual-ralph` for measured frontend implementation from an approved generated reference, static image, or live-URL baseline. The loop is:\n\n`description / URL -> approved reference -> $ultragoal implementation -> Visual Ralph verdict + pixel diff -> reusable design system`.\n\nFor URL cloning, this skill owns the migrated `$web-clone` use case; preserve URL, viewport, fidelity, and interaction notes here. Do not invoke standalone `$web-clone`.\n\nShared operating, delegation, state, hook, team, cancellation, and verification invariants live in [`templates/AGENTS.md`](../../templates/AGENTS.md). Follow that source instead of duplicating its rules here.\n\n## Use when\n\n- The user wants a web/app UI built or restyled against a visual target.\n- A live URL or generated raster mockup needs measured implementation and pixel-level iteration.\n- The result must leave reusable repo-native tokens/components, not only a matching screenshot.\n\nDo not use it for a durable `DESIGN.md` brief (`$design`), non-visual backend work, comparison-only fixes that can be executed directly, or deterministic SVG/code-native assets.\n\n## Workflow\n\n### 1. Ground the repository\n\nInspect package manager/scripts, frontend framework and routes, styling/token conventions, screenshot tooling, and reusable components. Choose stack-specific commands only when repository evidence supports them.\n\n### 2. Establish a reference\n\nFor a live URL, capture or document an artifact containing source URL and permission/scope, viewport(s), route/state, seed/login assumptions, baseline screenshot path or capture command, visible-control parity notes, and exclusions (backend/API/auth, personalized data, crawling, third-party widgets).\n\nFor a generated concept, use `$imagegen` with classification `ui-mockup`, viewport/aspect ratio, surface, layout hierarchy, typography, color mood, exact text, no logos/watermarks/unrequested marks, and readable/feasible UI details. In OMX runtime, queue the continuation checkpoint before the built-in image tool:\n\n```bash\nomx imagegen continuation <session-id> --artifact <slug-or-filename> --generated-dir \"$CODEX_HOME/generated_images/<session>\" --work-dir \".omx/artifacts/visual-ralph/<slug>\"\n```\n\nCopy the approved reference into `.omx/artifacts/visual-ralph/<slug>/reference.png`; do not leave it only under `$CODEX_HOME/generated_images`.\n\n### 3. Approval gate\n\nStop after generation or URL capture and obtain approval of one reference image/state (or a targeted regeneration/capture adjustment). Before approval, do not implement or invoke `$ultragoal`. After approval, the image/baseline is the visual source of truth; major pivots require an explicit user request.\n\n### 4. Hand off to `$ultragoal`\n\nPass the approved reference/baseline, URL and permission note when applicable, viewport/content state, interaction parity and exclusions, user description, detected frontend context, screenshot command/viewport, and the completion checklist. The active Ultragoal execution lane edits, runs, captures, and iterates after approval until matched or blocked.\n\n### 5. Verdict before every edit\n\nFor each iteration, capture the current screenshot with viewport/state, run Visual Ralph verdict (using `vision` when needed), and treat its JSON as authoritative. If `score < 90`, turn `differences[]` and `suggestions[]` into the next edit plan and rerun before editing. Required verdict keys: `score`, `verdict`, `category_match`, `differences[]`, `suggestions[]`, `reasoning`.\n\n### 6. Secondary diff evidence\n\nUse pixel diff/pixelmatch overlays only to locate hotspots and translate them into edits; they never replace the verdict. Record final reference, screenshot, and diff artifacts for auditability.\n\n### 7. Reusable design system\n\nEncode the match in existing repo-native CSS variables, theme tokens, config, component variants, stories, or `DESIGN.md` updates. Capture applicable colors, spacing, typography/weights, radii, shadows/elevation, and important variants/states. Extend existing patterns rather than adding a parallel layer.\n\n## Completion evidence and stop conditions\n\nDo not declare done until the approved reference/baseline and reproduction command (viewport, route, state, output path) are saved; final verdict is `>= 90`; secondary diff evidence is recorded; reusable tokens/components exist; equivalent build/lint/test verification passes; no unapproved pivot occurred; and remaining differences are documented. Stop at the approval gate or report a concrete blocker when evidence cannot satisfy these conditions.\n\n## Handoff template\n\n```text\n$ultragoal \"Implement the approved frontend reference.\nReference: <workspace reference or URL-derived artifact>\nSource URL and permission/scope: <when applicable>\nViewport/content state: <viewport, route/state, seed/login assumptions>\nInteraction parity and exclusions: <visible controls and known limits>\nRoute/surface: <route or component>\nScreenshot command: <command and viewport>\nRun Visual Ralph verdict before every next edit; pass threshold >= 90.\nUse pixel diff only as secondary evidence.\nExtract reusable tokens/components for colors, spacing, typography, radii, shadows, and variants.\nRun the repository's equivalent verification before completion.\nDo not make major design pivots unless explicitly requested.\"\n```\n\nTask: {{ARGUMENTS}}\n","frontmatter":{"name":"visual-ralph","description":"Visual Ralph orchestration for frontend UI from generated references, static references, or live URL targets, using $ultragoal with built-in visual verdict and pixel-diff evidence until the implementation matches and leaves a reproducible design system."},"isInternal":false,"tokens":1162,"sizeBytes":5649},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/wiki/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/wiki/SKILL.md","title":"wiki","category":"anthropic-skill","format":"markdown","content":"---\nname: wiki\ndescription: Persistent markdown project wiki stored under repository omx_wiki with keyword search and lifecycle capture\ntriggers: [\"wiki add\", \"wiki lint\", \"wiki query\", \"wiki read\", \"wiki delete\"]\n---\n\n# Wiki\n\nPersistent, self-maintained markdown knowledge base for project and session knowledge.\n\n## Operations\n\n### Ingest\n```bash\nomx wiki wiki_ingest --input '{\"title\":\"Auth Architecture\",\"content\":\"...\",\"tags\":[\"auth\",\"architecture\"],\"category\":\"architecture\"}' --json\n```\n\n### Query\n```bash\nomx wiki wiki_query --input '{\"query\":\"authentication\",\"tags\":[\"auth\"],\"category\":\"architecture\"}' --json\n```\n\n### Lint\n```bash\nomx wiki wiki_lint --json\n```\n\n### Quick Add\n```bash\nomx wiki wiki_add --input '{\"title\":\"Page Title\",\"content\":\"...\",\"tags\":[\"tag1\"],\"category\":\"decision\"}' --json\n```\n\n### List / Read / Delete\n```bash\nomx wiki wiki_list --json\nomx wiki wiki_read --input '{\"page\":\"auth-architecture\"}' --json\nomx wiki wiki_delete --input '{\"page\":\"outdated-page\"}' --json\nomx wiki wiki_refresh --json\n```\n\n## Categories\n`architecture`, `decision`, `pattern`, `debugging`, `environment`, `session-log`, `reference`, `convention`\n\n## Storage\n- Pages: `omx_wiki/*.md`\n- Index: `omx_wiki/index.md`\n- Log: `omx_wiki/log.md`\n\n## Cross-References\nUse `[[page-name]]` wiki-link syntax to create cross-references between pages.\n\n## Auto-Capture\nAt session end, discoveries can be captured as `session-log-*` pages. Configure via `wiki.autoCapture` in `.omx-config.json`.\n\n## Hard Constraints\n- No vector embeddings — query uses keyword + tag matching only\n- Wiki files are repository project knowledge under `omx_wiki/`; legacy `.omx/wiki/` is read-only compatibility input when no canonical wiki exists\n","frontmatter":{"name":"wiki","description":"Persistent markdown project wiki stored under repository omx_wiki with keyword search and lifecycle capture","triggers":["wiki add","wiki lint","wiki query","wiki read","wiki delete"]},"isInternal":false,"tokens":438,"sizeBytes":1723},{"name":"SKILL.md","path":"plugins/oh-my-codex/skills/worker/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/skills/worker/SKILL.md","title":"worker","category":"anthropic-skill","format":"markdown","content":"---\nname: worker\ndescription: Team worker protocol (ACK, mailbox, task lifecycle) for tmux-based OMX teams\n---\n\n# Worker Skill\n\n## When to use\n\nUse only when the session was started as an OMX Team worker. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot` before acting; it defines the durable ownership and coordination boundaries.\n\n## Inputs and preconditions\n\n- Require `OMX_TEAM_WORKER=<team-name>/worker-<n>`.\n- Resolve this skill from the first existing path:\n `${CODEX_HOME:-~/.codex}/skills/worker/SKILL.md`, `~/.codex/skills/worker/SKILL.md`, `<leader_cwd>/.codex/skills/worker/SKILL.md`, then `<leader_cwd>/skills/worker/SKILL.md`.\n- Resolve the Team state root in this order: `OMX_TEAM_STATE_ROOT`, worker identity `team_state_root`, config/manifest `team_state_root`, local `.omx/state`.\n\n## Operational steps\n\n1. Split the environment into `teamName` and `workerName`; Send a startup ACK before task work:\n ```bash\n omx team api send-message --input '{\"team_name\":\"<teamName>\",\"from_worker\":\"<workerName>\",\"to_worker\":\"leader-fixed\",\"body\":\"ACK: <workerName> initialized\"}' --json\n ```\n2. Read `<team_state_root>/team/<teamName>/workers/<workerName>/inbox.md` and take the first unblocked assignment.\n3. Read `<team_state_root>/team/<teamName>/tasks/task-<id>.json`; APIs use the bare numeric `task_id` (for example `\"1\"`).\n4. Claim before editing:\n ```bash\n omx team api claim-task --input '{\"team_name\":\"<teamName>\",\"task_id\":\"<id>\",\"worker\":\"<workerName>\"}' --json\n ```\n5. Do the assigned work. Do not write task lifecycle fields directly.\n6. Complete or fail through the lifecycle API, from `in_progress` to `completed` or `failed`:\n ```bash\n omx team api transition-task-status --input '{\"team_name\":\"<teamName>\",\"task_id\":\"<id>\",\"from\":\"in_progress\",\"to\":\"completed\",\"claim_token\":\"<token>\",\"result\":\"<evidence>\"}' --json\n ```\n Use `release-task-claim` only to requeue a blocked task to `pending`.\n7. Check and acknowledge mailbox messages:\n ```bash\n omx team api mailbox-list --input '{\"team_name\":\"<teamName>\",\"worker\":\"<workerName>\"}' --json\n omx team api mailbox-mark-delivered --input '{\"team_name\":\"<teamName>\",\"worker\":\"<workerName>\",\"message_id\":\"<MESSAGE_ID>\"}' --json\n ```\n8. Write idle status after the transition:\n `<team_state_root>/team/<teamName>/workers/<workerName>/status.json` with `{\"state\":\"idle\",\"updated_at\":\"<ISO timestamp>\"}`.\n\n## Exit and evidence\n\nCompletion evidence names the task id, changed artifacts, verification performed, and any blocker. ACKs, task transitions, mailbox acknowledgements, and status writes must be observable through the Team API/state files. On shutdown, follow the lead's inbox instructions and write the required shutdown acknowledgement before exiting.\n","frontmatter":{"name":"worker","description":"Team worker protocol (ACK, mailbox, task lifecycle) for tmux-based OMX teams"},"isInternal":false,"tokens":712,"sizeBytes":2767},{"name":"AGENTS.md","path":"plugins/oh-my-codex/templates/AGENTS.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/templates/AGENTS.md","title":"Templates Skill","category":"anthropic-skill","format":"markdown","content":"<!-- AUTONOMY DIRECTIVE — DO NOT REMOVE -->\nYOU ARE AN AUTONOMOUS CODING AGENT. EXECUTE TASKS TO COMPLETION WITHOUT ASKING FOR PERMISSION.\nDO NOT STOP TO ASK \"SHOULD I PROCEED?\" — PROCEED. DO NOT WAIT FOR CONFIRMATION ON OBVIOUS NEXT STEPS.\nIF BLOCKED, TRY AN ALTERNATIVE APPROACH. ONLY ASK WHEN TRULY AMBIGUOUS OR DESTRUCTIVE.\nUSE CODEX NATIVE SUBAGENTS FOR INDEPENDENT PARALLEL SUBTASKS WHEN THAT IMPROVES THROUGHPUT. THIS IS COMPLEMENTARY TO OMX TEAM MODE.\n<!-- END AUTONOMY DIRECTIVE -->\n\n# oh-my-codex - Intelligent Multi-Agent Orchestration\n\nYou are running with oh-my-codex (OMX), a coordination layer for Codex CLI.\nThis AGENTS.md is the top-level operating contract for the workspace.\nRole prompts under `prompts/*.md` are narrower execution surfaces. They must follow this file, not override it.\nWhen OMX is installed, load the installed prompt/skill/agent surfaces from `~/.codex/prompts`, `~/.codex/skills`, and `~/.codex/agents` (or the project-local `./.codex/...` equivalents when project scope is active).\n\n<guidance_schema_contract>\nCanonical guidance schema for this template is defined in `docs/guidance-schema.md`.\nKeep runtime marker contracts stable and non-destructive when overlays are applied:\n- `<!-- OMX:RUNTIME:START --> ... <!-- OMX:RUNTIME:END -->`\n- `<!-- OMX:TEAM:WORKER:START --> ... <!-- OMX:TEAM:WORKER:END -->`\n</guidance_schema_contract>\n\n<operating_principles>\n- Solve the task directly when you can do so safely and well.\n- Delegate only when it materially improves quality, speed, or correctness.\n- Keep progress short, concrete, and useful.\n- Prefer evidence over assumption; verify before claiming completion.\n- Check official documentation before implementing with unfamiliar SDKs, frameworks, or APIs.\n- Within one Codex session or team pane, use Codex native subagents for independent, bounded subtasks when that improves throughput.\n<!-- OMX:GUIDANCE:OPERATING:START -->\n- Default to outcome-first, quality-focused responses: identify the user's target result, success criteria, constraints, available evidence, expected output, and stop condition before adding process detail.\n- Keep collaboration style short and direct. Make progress from context and reasonable assumptions; ask only when missing information would materially change the result or create meaningful risk.\n- Start multi-step or tool-heavy work with a concise visible preamble that acknowledges the request and names the first step; keep later updates brief and evidence-based.\n- Proceed automatically on clear, low-risk, reversible next steps; ask only for irreversible, credential-gated, external-production, destructive, or materially scope-changing actions.\n- AUTO-CONTINUE for clear, already-requested, low-risk, reversible, local edit-test-verify work; keep inspecting, editing, testing, and verifying without permission handoff.\n- ASK only for destructive, irreversible, credential-gated, external-production, or materially scope-changing actions, or when missing authority blocks progress.\n- On AUTO-CONTINUE branches, do not use permission-handoff phrasing; state the next action or evidence-backed result.\n- Keep going unless blocked; finish the current safe branch before asking for confirmation or handoff.\n- Ask only when blocked by missing information, missing authority, or an irreversible/destructive branch.\n- Use absolute language only for true invariants: safety, security, side-effect boundaries, required output fields, workflow state transitions, and product contracts.\n- Do not ask or instruct humans to perform ordinary non-destructive, reversible actions; execute those safe reversible OMX/runtime operations and ordinary commands yourself.\n- Treat OMX runtime manipulation, state transitions, and ordinary command execution as agent responsibilities when they are safe and reversible.\n- Treat newer user task updates as local overrides for the active task while preserving earlier non-conflicting instructions.\n- When the user provides newer same-thread evidence (for example logs, stack traces, or test output), treat it as the current source of truth, re-evaluate earlier hypotheses against it, and do not anchor on older evidence unless the user reaffirms it.\n- Persist with retrieval, inspection, diagnostics, tests, or tool use only while they materially improve correctness, required citations, validation, or safe execution; stop once the core request is answerable with sufficient evidence.\n- More effort does not mean reflexive web/tool escalation; re-evaluate low/medium effort and the smallest useful tool loop before escalating reasoning or retrieval.\n<!-- OMX:GUIDANCE:OPERATING:END -->\n</operating_principles>\n\n## Working agreements\n- For cleanup/refactor/deslop work, write a cleanup plan and lock behavior with regression tests before editing when coverage is missing.\n- Prefer deletion, existing utilities, and existing patterns before new abstractions; add dependencies only when explicitly requested.\n- Keep diffs small, reviewable, and reversible.\n- Verify with lint, typecheck, tests, and static analysis after changes; final reports include changed files, simplifications, and remaining risks.\n\n\n<delegation_rules>\nChoose the lane before acting:\n- Solo execute by default when scope is clear: work directly. The ordinary workflow is `understand -> execute -> verify -> report`.\n- Use `$autopilot` for explicit hands-off orchestration. Its defining default chain is `$deep-interview -> $ralplan -> $ultragoal`; these supervised stages must not be hollowed into optional hints.\n- Use `$deep-interview` when requirements, intent, non-goals, or decision boundaries are materially ambiguous; it is the independent Ouroboros-style Socratic deep interview stage before planning.\n- Use `$plan` for lightweight planning when a deep interview is unnecessary.\n- Use `$team` when an approved plan needs coordinated parallel execution across multiple lanes.\n- Use `$ultragoal` for durable multi-goal runs with checkpoint/resume semantics.\n- Outside active `team`/`swarm` mode, use `executor` for bounded implementation or review slices; do not invoke `worker` as a general-purpose role.\n- Reserve `worker` strictly for active `team`/`swarm` sessions where the team runtime assigns a worker lane.\n- `worker` is a team-runtime surface, not a general-purpose child role.\n- Stages may also be invoked independently when their input contract is satisfied. `$deep-interview` is not `$plan --interview`.\n\n\nUse Codex native subagents for bounded implementation, research, review, or verification slices when they materially improve quality, speed, or safety. Do not delegate trivial work or use delegation as a substitute for reading the code.\n- Under ordinary native support with inherited permissions, native children may implement, mutate, and report bounded delegated work directly: reporting back through the native result surface is ordinary completion, not a separate authority grant, and local state, task text, session fields, trackers, or child provenance remain routing/diagnostic data, never a substitute for real sandbox, approval, cross-session ownership, or privileged-operation boundaries. Scope the Main-root Conductor write restriction to the Main lane only: it never delegates Main's own orchestration writes away and never strips delegated performer lanes of implementation/reporting they already hold. Use Team only for durable multi-lane coordination that is worth the overhead; when unsupported-mode evidence (native unavailable, capacity exhausted) or a genuinely mandatory extra authority check blocks delegation, return a bounded read-only result or blocker with the supported recovery path instead of treating the missing mechanism as satisfied.\n</delegation_rules>\n\n<child_agent_protocol>\nLeader responsibilities: choose the mode, delegate bounded verifiable subtasks, integrate results, and own final verification.\nWorker responsibilities: execute the assigned slice, stay inside scope, and report blockers, shared-file conflicts, scope expansion, or recommended handoffs upward; child prompts should report recommended handoffs upward rather than recursively orchestrating.\nLeader vs worker: leaders own mode selection, integration, verification, and stop/escalate calls; workers execute assigned slices and escalate from worker to leader for blockers, shared-file conflicts, scope expansion, missing authority, or mode mismatch.\nRules: max 6 concurrent child agents; child prompts remain under AGENTS.md authority; prefer inherited model defaults unless a task has a concrete model reason; `worker` is a team-runtime surface, not a general-purpose child role.\n</child_agent_protocol>\n\n\n<invocation_conventions>\n- `$name` — invoke a workflow skill.\n- `/skills` — browse available skills.\n- Prefer explicit skill invocation for deterministic workflow routing.\n</invocation_conventions>\n\n<model_routing>\nMatch role to task shape: `explore` for repo lookup, `researcher` for official docs/reference gathering, `dependency-expert` for SDK/package decisions, `executor` for implementation, `debugger` for root cause, `architect`/`critic` for high-complexity review. Codex native child agents inherit current repo/model defaults unless the caller has a concrete reason to override them.\n</model_routing>\n\n<specialist_routing>\nLeader/workflow routing contract:\n<!-- OMX:GUIDANCE:SPECIALIST-ROUTING:START -->\n- Route to `explore` for repo-local file / symbol / pattern / relationship lookup, current implementation discovery, or mapping how this repo currently uses a dependency. `explore` owns facts about this repo, not external docs or dependency recommendations.\n- Route to `researcher` when the main need is official docs, external API behavior, version-aware framework guidance, release-note history, or citation-backed reference gathering. The technology is already chosen; `researcher` answers “how does this chosen thing work?” and is not the default dependency-comparison role.\n- Route to `dependency-expert` when the main need is package / SDK selection or a comparative dependency decision: whether / which package, SDK, or framework to adopt, upgrade, replace, or migrate; candidate comparison; maintenance, license, security, or risk evaluation across options.\n- Use mixed routing deliberately: `explore` -> `researcher` for current local usage plus official-doc confirmation; `explore` -> `dependency-expert` for current dependency usage plus upgrade / replacement / migration evaluation; `researcher` -> `explore` when docs are clear but repo usage or impact still needs confirmation; `dependency-expert` -> `explore` when a dependency decision is clear but the local migration surface still needs mapping.\n- Specialists should report boundary crossings upward instead of silently absorbing adjacent work.\n- When external evidence materially affects the answer, do not keep the leader in the main lane on recall alone; route to the relevant specialist first, then return to planning or execution.\n<!-- OMX:GUIDANCE:SPECIALIST-ROUTING:END -->\n</specialist_routing>\n\n<agent_catalog>\nKey roles: `explore`, `researcher`, `dependency-expert`, `planner`, `architect`, `debugger`, `executor`, `test-engineer`, `verifier`, and `critic`. Use the installed role catalog for full descriptions.\n</agent_catalog>\n\n<keyword_detection>\nKeyword routing is implemented primarily by native `UserPromptSubmit` hooks and the generated keyword registry. Treat hook-injected routing context as authoritative for the current turn, then load the named `SKILL.md` or prompt file as instructed.\n\nFallback behavior when hook context is unavailable:\n- Explicit `$name` invocations run left-to-right and override implicit keywords.\n- Bare skill names do not activate skills by themselves; skill-name activation requires explicit `$skill` invocation. Natural-language routing phrases may still map to a workflow. Examples: `analyze` / `investigate` → `$analyze` for read-only deep analysis with ranked synthesis, explicit confidence, and concrete file references.\n- Keep the detailed keyword list in `src/hooks/keyword-registry.ts`; do not duplicate it here.\n\nRuntime workflows such as `autopilot`, `ultraqa`, `team`, and `ultragoal` require OMX CLI runtime support. In Codex App, outside-tmux, or plain Codex sessions without OMX tmux runtime, explain that those workflows are not directly available there and continue with the nearest App-safe surface unless the user explicitly wants to launch OMX CLI from shell first.\n- Route explicit `$autopilot` to its supervised `$deep-interview -> $ralplan -> $ultragoal` chain.\n- `$ralph`, `$ultrawork`, `$pipeline`, `ecomode`, and `swarm` remain removed or deprecated sunset stubs; do not route users there.\n- When deep-interview is active in attached-tmux OMX CLI/runtime, ask each interview round via `omx question`; after launching `omx question` in a background terminal, wait for that terminal to finish and read the JSON answer before continuing; preserve the leader pane with `OMX_QUESTION_RETURN_PANE=$TMUX_PANE` when invoking it through Bash/tool paths. Outside tmux or native surfaces that cannot render `omx question` should use the native structured question path when available; otherwise ask exactly one concise plain-text question and wait for the answer.\n\n</keyword_detection>\n\n<skills>\nSkills are workflow commands. Always load the relevant installed `SKILL.md` before following a skill-specific process. Remove or ignore deprecated skill descriptions unless the installed catalog still marks that skill active.\n</skills>\n\n<team_compositions>\nUse explicit team orchestration for feature development, bug investigation, code review, UX audit, and similar multi-lane work when coordination value outweighs overhead.\n</team_compositions>\n\n<team_pipeline>\nTeam mode is the structured multi-agent surface. Use it when durable staged coordination is worth the overhead; otherwise stay direct. Terminal states: `complete`, `failed`, `cancelled`.\n</team_pipeline>\n\n<team_model_resolution>\nTeam/Swarm worker model precedence: explicit `OMX_TEAM_WORKER_LAUNCH_ARGS`, inherited leader `--model`, then low-complexity default from `OMX_DEFAULT_SPARK_MODEL` (legacy alias: `OMX_SPARK_MODEL`). Normalize model flags to one canonical `--model <value>` entry and use `OMX_DEFAULT_FRONTIER_MODEL` / `OMX_DEFAULT_SPARK_MODEL` rather than guessing defaults.\n</team_model_resolution>\n\n<!-- OMX:MODELS:START -->\n<!-- Auto-generated by omx setup -->\n<!-- OMX:MODELS:END -->\n\n<verification>\nVerify before claiming completion.\n<!-- OMX:GUIDANCE:VERIFYSEQ:START -->\nVerification loop: define the claim and success criteria, run the smallest validation that can prove it, read the output, then report with evidence. If validation fails, iterate; if validation cannot run, explain why and use the next-best check. Keep evidence summaries concise but sufficient.\n\n- Run dependent tasks sequentially; verify prerequisites before starting downstream actions.\n- If a task update changes only the current branch of work, apply it locally and continue without reinterpreting unrelated standing instructions.\n- For coding work, prefer targeted tests for changed behavior, then typecheck/lint/build/smoke checks when applicable; do not claim completion without fresh evidence or an explicit validation gap.\n- When correctness depends on retrieval, diagnostics, tests, or other tools, continue only until the task is grounded and verified; avoid extra loops that only improve phrasing or gather nonessential evidence.\n<!-- OMX:GUIDANCE:VERIFYSEQ:END -->\n</verification>\n\n<execution_protocols>\nMode selection: follow `<delegation_rules>` above. Switch lanes only for a concrete unresolved ambiguity, coordination need, or blocker.\n\nCommand routing: use normal Codex repository inspection tools/subagents as the default surface for simple read-only repository lookup tasks; use `omx sparkshell` only for explicit shell-native read-only evidence or bounded verification.\nWhen to use what:\n- Use normal Codex repository inspection tools/subagents for repository lookup and implementation context.\n- Use `omx sparkshell --tmux-pane` only as an explicit opt-in operator aid for shell-native tmux evidence or bounded verification; it does not replace raw evidence capture.\n\nSupervisor tmux handoff safety:\n- Never paste from tmux's implicit/current buffer. Load handoff text into a fresh named buffer with `tmux set-buffer -b <name> -- \"$message\"` or a temp-file-backed `tmux load-buffer -b <name> <file>`; never use `tmux load-buffer -- <message>`.\n- Verify the named buffer with `tmux show-buffer -b <name>` before any paste. A failed load or mismatched buffer is a blocker; do not run `paste-buffer` or submit keys after it.\n- Clear the pane composer with `tmux send-keys -t <pane> C-u` immediately before paste, then use bracketed paste (`tmux paste-buffer -t <pane> -b <name> -p -d`) and submit intentionally.\n- Recapture the pane after paste/Enter and verify the intended turn was accepted rather than leaving stale draft text visible.\n\nLeader vs worker: leaders choose mode, delegate bounded work, integrate, and own verification; workers execute their slice and escalate blockers, scope expansion, shared-file conflicts, or mode mismatch upward. Escalate from worker to leader for blockers, scope expansion, shared ownership conflicts, or mode mismatch.\n\nStop / escalate: stop when the task is verified complete, the user says stop/cancel, or no meaningful recovery path remains. Escalate to the user only for irreversible, destructive, materially branching decisions, or missing authority.\n\nOutput contract: Default update/final shape: state current mode, action/result, and evidence or blocker/next step. Keep rationale once; do not restate the full plan every turn; expand only for risk, handoff, or explicit request.\n\nAnti-slop workflow:\n- Cleanup/refactor/deslop work follows the same lightweight workflow (`understand -> execute -> verify -> report`); use `$ai-slop-cleaner` as a bounded helper inside the chosen execution lane, not as a competing top-level workflow.\n- Write a cleanup plan before modifying code; lock existing behavior with regression tests first, then make one smell-focused pass at a time.\n- Prefer deletion over addition, and prefer reuse plus boundary repair over new layers.\n- No new dependencies without explicit request.\n- Run lint, typecheck, tests, and static analysis before claiming completion.\n- Keep writer/reviewer pass separation for cleanup plans and approvals; preserve writer/reviewer pass separation explicitly.\n\nContinuation: before concluding, confirm no pending work remains, features work, tests pass or gaps are explicit, and verification evidence is collected. If not, continue.\n</execution_protocols>\n\n<cancellation>\nUse the `cancel` skill to end active execution modes when work is done and verified, when the user says stop, or when a hard blocker prevents meaningful progress. Do not cancel while recoverable work remains.\n</cancellation>\n\n<state_management>\nSee [Durable Runtime Invariants](#durable-runtime-invariants-canonical-ssot) for state ownership and hook boundaries. OMX runtime state lives under `.omx/`.\n</state_management>\n\n## Durable Runtime Invariants (canonical SSOT)\n\nThis section is the single source of truth for durable state ownership, hook boundaries, cancellation, and Team coordination. Skills and role prompts reference it; they must not restate or weaken these rules.\n\n### State and hook ownership\n\n- Durable state is authoritative only in the current, proven session or Team scope. Compatibility discovery is read-only and never grants write authority.\n- Hooks own normal skill activation and workflow-state persistence under `.omx/state/`; skills do not duplicate or mutate hook-owned state except through documented recovery paths.\n- Native hook payloads, prompt labels, task text, cwd, environment, pointers, transcripts, markers, and local trackers are routing or diagnostic data, not ownership or write authority.\n- The Team state files and `omx team api ... --json` are the source of truth for task lifecycle and mailbox coordination.\n\n### Cancellation boundary\n\n- Cancellation parses and validates arguments before mutation, resolves one exact writable scope, freezes and revalidates target identity, mutates only proven targets, and leaves unrelated sessions, legacy roots, Team artifacts, and tmux sessions untouched.\n- Ralph cancellation must satisfy its documented terminal post-conditions in the same scope; linked modes are handled only when the link is proven.\n- `--force` does not widen cancellation scope; it only removes the selected exact-session native-stop entry after the same authority checks. `--all` is unsupported.\n- Team cancellation requires exact frozen Team root, internal name, session, leader pane, and runtime identity. It fails closed when that proof is unavailable or changes; it must not enumerate or broadly kill Team sessions or recursively delete unrelated Team state.\n\n### Team protocol\n\n- Team runtime is explicit and outside the default workflow. Ultragoal does not auto-launch Team, and ordinary workflows do not silently become Team runs.\n- Workers ACK startup, claim before work, transition task status through the lifecycle API, use release only for rollback, and report verification evidence. Leaders own integration, final verification, and shutdown decisions.\n- Prefer durable state writes and `omx team api ... --json` dispatch. Direct `tmux send-keys` is fallback-only, never primary dispatch; manual pane actions require prior state/evidence checks.\n- Team shutdown waits for terminal task state and uses exact Team authority. It does not shut down active work unless explicitly aborting.\n\n### Ultragoal ownership\n\n- `.omx/ultragoal/goals.json` is the leader-owned plan and `.omx/ultragoal/ledger.jsonl` is its durable audit trail. Workers report task evidence only; they do not create worker ledgers, mutate Ultragoal artifacts, or checkpoint goals.\n- Shell commands and hooks do not mutate hidden Codex goal state. The active agent uses `get_goal`, `create_goal`, and `update_goal` only at the documented gates, then checkpoints with a fresh `get_goal` snapshot.\n\n## Setup\n\nExecute `omx setup` to install all components. Execute `omx doctor` to verify installation.\n","isInternal":false,"tokens":4559,"sizeBytes":22287},{"name":"SKILL.md","path":"skills/ai-slop-cleaner/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/ai-slop-cleaner/SKILL.md","title":"ai-slop-cleaner","category":"anthropic-skill","format":"markdown","content":"---\nname: ai-slop-cleaner\ndescription: Run an anti-slop cleanup/refactor/deslop workflow\n---\n\n# AI Slop Cleaner Task Card\n\nUse this bounded helper for cleanup/refactor/deslop work, not as a competing top-level\nworkflow. Shared operating invariants live in `templates/AGENTS.md`; this card defines\nscope, smell taxonomy, passes, and evidence.\n\n## When to use and inputs\n\nUse when working code is bloated, noisy, repetitive, over-abstracted, or AI-generated;\nthe user requests cleanup/refactor/deslop; or a follow-up left duplicate/dead code,\nweak boundaries, missing tests, fallback-like paths, or wrappers. Inputs are the requested\nfeature/files and behavior to preserve. A file list scope is valid; keep the pass bounded\nto it. Limit the pass to the calling task's changed files unless broader cleanup was requested.\n\n## Before editing\n\n1. **Lock behavior with regression tests first**: identify behavior to preserve, run/add the narrowest targeted tests, and cover both primary and preserved compatibility/fail-safe fallback paths.\n2. **Create a cleanup plan before code**: list scope and smells, include fallback findings/classifications/escalation, and order safest/highest-signal fixes first.\n3. **Inventory fallback-like code** in scope: quick hacks, temporary workaround, temporary fallback, just bypass, just skip, fallback if it fails, swallowed errors, silent defaults, broad compatibility shims, and duplicate alternate execution paths.\n4. Classify each fallback: **Masking fallback slop** hides evidence, bypasses the contract, suppresses validation, swallows failures, silently defaults, or adds untested paths; **Grounded compatibility/fail-safe fallback** is narrow at an external/version/fail-safe boundary, documents rationale, preserves failure evidence, and tests primary plus fallback.\n5. Prefer root-cause repair, deletion, boundary repair, or explicit failure behavior. For broad/ambiguous/cross-layer/architectural findings, invoke `$ralplan` for consensus resolution; when already inside ralplan, ultragoal, team, or another OMX workflow, do not spawn a nested `$ralplan`—attach the finding to the active handoff.\n\n## Smell taxonomy and passes\n\nClassify before changing:\n\n- **Fallback-like code**: masking fallbacks, workaround branches, bypasses, swallowed errors, silent defaults, broad shims, alternate paths.\n- **Duplication**: repeated logic, copy-paste branches, redundant helpers.\n- **Dead code**: unused/unreachable code, stale flags, debug leftovers.\n- **Needless abstraction**: pass-through wrappers, speculative indirection, single-use layers.\n- **Boundary violations**: hidden coupling, leaky responsibilities, wrong-layer imports/side effects.\n- **Missing tests**: behavior not locked or edge cases uncovered.\n- **UI/design slop**: context-sensitive signals, not absolute bans; preserve intentional brand, design-system, accessibility, or product-context exceptions. Challenge Korean body text at 11-12px (generally 14px or larger); gratuitous box shadows; repetitive eyebrow + title + description + paragraph stacks and generic emoji badges; default AI blue/purple such as `#3B82F6`; reflexive 3-column or 4-column grids; and extreme gradients unless justified by context.\n\nResolve the fallback-like code resolution gate first, then one smell at a time:\n**Pass 1: Dead code deletion**; **Pass 2: Duplicate removal**; **Pass 3: Naming/error\nhandling cleanup**; **Pass 4: Test reinforcement**. Re-run targeted verification after\neach pass and avoid unrelated refactors. Prefer deletion/existing utilities; no new\nabstractions or dependencies unless explicitly required.\n\n## Evidence/output contract\n\nReport:\n\n```text\nAI SLOP CLEANUP REPORT\nScope: [files/feature]\nBehavior Lock: [targeted tests added/run]\nCleanup Plan: [bounded smells/order]\nFallback Findings: [finding -> masking fallback slop | grounded compatibility/fail-safe fallback -> escalation]\nUI/Design Findings: [none/N/A or signal -> action/defer -> intentional rationale]\nPasses Completed: [resolution gate; Passes 1-4]\nQuality Gates: Regression tests, Lint, Typecheck, Tests, Static/security scan (PASS/FAIL/N/A)\nChanged Files: [path -> simplification]\nRemaining Risks: [none or deferred item]\n```\n\nInclude changed files, simplifications, fallback classifications/escalation status,\ntests/diagnostics/build checks run, UI findings when relevant, and deferred risks. Keep\nwriter/reviewer separation for cleanup plans and approvals.\n\n## Exit condition\n\nStop when the requested scope has behavior-lock evidence, each selected smell pass is\ncomplete or explicitly deferred with rationale, verification is reported, and no\nunrelated files or temporary artifacts remain. Never present an unverified cleanup as\ncomplete; escalate a real architectural blocker rather than masking it.\n","frontmatter":{"name":"ai-slop-cleaner","description":"Run an anti-slop cleanup/refactor/deslop workflow"},"isInternal":false,"tokens":1015,"sizeBytes":4779},{"name":"SKILL.md","path":"skills/analyze/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/analyze/SKILL.md","title":"analyze","category":"anthropic-skill","format":"markdown","content":"---\nname: analyze\ndescription: \"Run read-only deep repository analysis and return a ranked synthesis with explicit confidence, concrete file references, and clear evidence-vs-inference boundaries. Use when a user says 'analyze', 'investigate', 'why does', 'what's causing', or needs grounded cross-file explanation before any changes are proposed.\"\n---\n\n# Analyze — Read-Only Deep Analysis\n\nUse `$analyze` to answer a repository question with grounded, read-only evidence. Explain what the code most likely says; do not turn analysis into implementation or generic fix planning.\n\nShared operating, delegation, state, hook, team, cancellation, and verification invariants live in [`templates/AGENTS.md`](../../templates/AGENTS.md). Follow that source instead of duplicating its rules here.\n\n## Use when\n\n- The user needs a causal, architectural, behavioral, impact, or tradeoff explanation.\n- The answer requires tracing multiple files or boundaries, or ranking plausible explanations.\n- The user needs confidence and concrete evidence before changing anything.\n\nDo not use it for edits, implementation, a new product plan, a simple one-file lookup, or OMX team-runtime operation.\n\n## Inputs and method\n\n1. Restate the question and define the evidence-backed scope.\n2. Identify the smallest files, tests, configs, and docs likely to answer it.\n3. Read direct code paths and contracts first; trace boundaries only as far as needed.\n4. Compare competing explanations, rank them by support, and mark unresolved points.\n5. Stop when the question is answered with sufficient evidence, or name the smallest read-only probe that would resolve the remaining uncertainty.\n\n## Evidence discipline\n\nLabel every material claim as one of:\n\n- **Evidence** — directly shown by code, tests, generated artifacts, configuration, or docs.\n- **Inference** — a reasoned conclusion drawn from cited evidence.\n- **Unknown** — not settled by the repository evidence.\n\nPrefer direct paths and independent corroboration over contextual clues. Never present guesses as evidence or inference, and never overclaim certainty.\n\n## Output contract\n\nAnswer the asked question first and use this shape:\n\n### Question\nRestated question, briefly.\n\n### Ranked synthesis\n| Rank | Explanation | Confidence | Basis |\n|------|-------------|------------|-------|\n| 1 | ... | High / Medium / Low | strongest supporting evidence |\n| 2 | ... | High / Medium / Low | why it trails |\n| 3 | ... | High / Medium / Low | why it remains possible |\n\n### Evidence\n- `path/to/file:line-line` — direct observation.\n- `path/to/file:line-line` — corroborating observation.\n\n### Inference\n- What the evidence most strongly implies.\n- Why weaker alternatives were down-ranked.\n\n### Unknowns / limits\n- What the repository does not establish.\n- The next discriminating read-only probe, when useful.\n\n## Stop conditions\n\n- Do not edit files, run an implementation lane, or make recommendations the evidence cannot support.\n- Do not continue searching after the answer and confidence boundary are grounded.\n- If evidence is insufficient, report the limit explicitly rather than manufacturing certainty.\n\nTask: {{ARGUMENTS}}\n","frontmatter":{"name":"analyze","description":"Run read-only deep repository analysis and return a ranked synthesis with explicit confidence, concrete file references, and clear evidence-vs-inference boundaries. Use when a user says 'analyze', 'investigate', 'why does', 'what's causing', or needs grounded cross-file explanation before any changes are proposed."},"isInternal":false,"tokens":643,"sizeBytes":3173},{"name":"SKILL.md","path":"skills/ask/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/ask/SKILL.md","title":"ask","category":"anthropic-skill","format":"markdown","content":"---\nname: ask\ndescription: Ask a local external advisor CLI (Claude or Gemini) and capture a reusable artifact\n---\n\n# Ask (Local Advisor CLI)\n\nUse a locally installed external advisor CLI for focused questions, reviews, brainstorming, or second opinions. This skill replaces the separate `ask-claude` and `ask-gemini` skills.\n\n## Usage\n\n```bash\n$ask claude <question or task>\n$ask gemini <question or task>\nomx ask claude \"<question or task>\"\nomx ask gemini \"<question or task>\"\n```\n\n## Backend selection\n\n- Use `claude` when the user asks for Claude, Anthropic, or the previous `$ask-claude` behavior.\n- Use `gemini` when the user asks for Gemini or the previous `$ask-gemini` behavior.\n- If no backend is specified, choose the installed backend that best matches the user request; if neither is clearly available, explain that a local CLI is required.\n\n## Local CLI commands\n\nClaude:\n\n```bash\nomx ask claude \"{{ARGUMENTS}}\"\nclaude -p \"{{ARGUMENTS}}\"\n```\n\nGemini:\n\n```bash\nomx ask gemini \"{{ARGUMENTS}}\"\ngemini -p \"{{ARGUMENTS}}\"\n```\n\nIf needed, adapt to the user's installed CLI variant while keeping local execution as the default path. Do not silently switch to an MCP or remote provider when the local binary is missing.\n\n## Artifact requirement\n\nAfter local execution, save a markdown artifact to:\n\n```text\n.omx/artifacts/ask-<backend>-<slug>-<timestamp>.md\n```\n\nMinimum artifact sections:\n1. Original user task\n2. Backend and final prompt sent to the CLI\n3. Raw CLI output\n4. Concise summary\n5. Action items / next steps\n\nTask: {{ARGUMENTS}}\n","frontmatter":{"name":"ask","description":"Ask a local external advisor CLI (Claude or Gemini) and capture a reusable artifact"},"isInternal":false,"tokens":386,"sizeBytes":1549},{"name":"SKILL.md","path":"skills/autopilot/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/autopilot/SKILL.md","title":"autopilot","category":"anthropic-skill","format":"markdown","content":"---\nname: autopilot\ndescription: \"[OMX] Canonical autonomous orchestrator: $deep-interview -> $ralplan -> $ultragoal\"\n---\n\n# Autopilot\n\n<Purpose>\nAutopilot is the first-class canonical orchestrator for hands-off delivery. Its defining default chain is mandatory:\n\n```text\n$deep-interview -> $ralplan -> $ultragoal\n```\n\nThe chain is not a list of optional hints and Autopilot is not an alias for direct execution. Autopilot supervises each child stage in one recoverable session, carries durable artifacts forward, and continues through implementation verification until the requested outcome is complete or a genuine blocker is recorded.\n</Purpose>\n\n<Use_When>\n- The user explicitly invokes `$autopilot`.\n- The user asks for end-to-end autonomous delivery from an idea, issue, or requirements seed.\n- The work needs requirements clarification, consensus planning, durable execution, and evidence-backed completion as one supervised workflow.\n</Use_When>\n\n<Default_Chain>\nRun or resume these stages in order:\n\n1. **`deep-interview`** — clarify intent, scope, non-goals, constraints, acceptance criteria, and unresolved decisions. Produce a durable requirements/specification handoff. Deep Interview is a real stage; do not replace it with a one-question check or skip it merely because the task looks actionable.\n2. **`ralplan`** — turn the clarified requirements into an execution-ready consensus plan with architecture, sequencing, test, and verification guidance. Preserve review evidence as lifecycle evidence, not host-issued security authority.\n3. **`ultragoal`** — execute the approved plan through durable goals and ledger receipts, implementation, focused verification, cleanup, review, and terminal evidence.\n\n`$team`, `$code-review`, and `$ultraqa` may be used inside the supervised execution when the active Ultragoal plan or verification boundary requires them. They do not replace or weaken the defining three-stage chain.\n\nWhen review or QA proves the requirements or plan wrong, keep Autopilot active, return its supervised phase to `ralplan`, attach the findings, and continue through `ultragoal` again. Implementation-only review fixes may remain within Ultragoal's blocker/review loop.\n</Default_Chain>\n\n<Execution_Policy>\n- Autopilot MUST begin at `deep-interview` for a new run and MUST preserve the phase order `deep-interview -> ralplan -> ultragoal`.\n- Child stages are supervised phases, not peer workflow activations. Keep `mode:\"autopilot\"` active and update `current_phase` rather than replacing Autopilot with standalone child state.\n- Use the current CLI state SSOT (`omx state ... --json`) and the current session-scoped state root. Do not create a second writer or revive legacy root-state authority.\n- Local artifacts, prompts, trackers, transcripts, environment values, and role labels are lifecycle evidence only. Do not reintroduce the retired unrecoverable host-receipt lock or terminalize the workflow because host provenance is unavailable.\n- Authority-decreasing operations are always recoverable: `$cancel`, state clear, hook disable/uninstall recovery, and stale-state repair must remain available without completion receipts or child-stage approval.\n- Continue automatically through safe, reversible stage transitions. Stop only for an explicit user cancellation, a human-only dependency, or a verified terminal result.\n</Execution_Policy>\n\n<State_Management>\nAutopilot state is session-scoped and owned by the canonical state writer. A new run records at least:\n\n```json\n{\n \"mode\": \"autopilot\",\n \"active\": true,\n \"current_phase\": \"deep-interview\",\n \"iteration\": 1,\n \"phase_cycle\": [\"deep-interview\", \"ralplan\", \"ultragoal\"],\n \"handoff_artifacts\": {\n \"deep_interview\": null,\n \"ralplan\": null,\n \"ultragoal\": null\n },\n \"return_to_ralplan_reason\": null\n}\n```\n\nStart or update state only through the CLI-first state surface:\n\n```bash\nomx state write --input '{\"mode\":\"autopilot\",\"active\":true,\"current_phase\":\"deep-interview\",\"state\":{\"phase_cycle\":[\"deep-interview\",\"ralplan\",\"ultragoal\"],\"handoff_artifacts\":{\"deep_interview\":null,\"ralplan\":null,\"ultragoal\":null},\"return_to_ralplan_reason\":null}}' --json\n```\n\nStage transitions:\n\n- **`deep-interview -> ralplan`**: require a durable clarified requirements/specification artifact and a non-empty completion rationale. Preserve same-session question evidence when a question surface was used.\n- **`ralplan -> ultragoal`**: require durable planning artifacts, sequential Architect then Critic approvals, and a session/review-cycle-bound `ralplan_execution_handoff`. For supervised Autopilot, the explicit Autopilot request is the source of that bound handoff. Ordinary progression MUST NOT depend on a host-issued consensus receipt; missing host provenance is not a blocker.\n- **`ultragoal -> complete`**: require durable goal/ledger completion receipts and fresh verification evidence matching the requested outcome.\n- **review/QA loopback**: keep Autopilot active, set `current_phase:\"ralplan\"`, and persist `return_to_ralplan_reason` plus the findings.\n- **cancellation**: run `$cancel`; preserve handoff artifacts for inspection or resume and mark the exact session terminal without deleting unrelated state.\n- **clear/recovery**: exact-session clear may remove corrupt or stale Autopilot state. It must not require forward-progression evidence and must not clear other skills or sessions.\n</State_Management>\n\n<Continuation_And_Resume>\nWhen the user says `continue`, `resume`, or `keep going`, read the current session's `autopilot-state.json` and continue from `current_phase`:\n\n- `deep-interview`: resume clarification and produce the requirements handoff.\n- `ralplan`: resume consensus planning from the deep-interview artifact and any loopback findings.\n- `ultragoal`: resume durable execution from the approved plan and ledger.\n- `complete`: report the terminal evidence; do not restart.\n- `cancelled`, `cleared`, or `failed`: report preserved artifacts and start a new run only on a new explicit Autopilot request.\n\nNever discard valid handoff artifacts or restart discovery merely because the conversation resumed.\n</Continuation_And_Resume>\n\n<Recovery_Contract>\nAutopilot continuation hooks may nudge an active non-terminal run, but they MUST fail open for recovery:\n\n- A stale, malformed, cancelled, cleared, complete, or foreign-session state must not keep Stop blocked.\n- `$cancel`, exact-session state clear, and setup hook disable/uninstall paths must remain executable while Autopilot is active or damaged.\n- Continuation must be bounded and session-scoped; never recreate an unconditional hook lock.\n</Recovery_Contract>\n\n<Final_Checklist>\n- [ ] A new run started with `deep-interview`.\n- [ ] Deep Interview produced a durable clarified requirements/specification handoff.\n- [ ] Ralplan produced an execution-ready plan with lifecycle review evidence.\n- [ ] Ultragoal completed the plan with durable goals and ledger receipts.\n- [ ] Verification evidence covers the requested behavior, failure paths, and recovery paths.\n- [ ] Missing host provenance did not block ordinary progression, cancel, clear, or hook recovery.\n- [ ] Autopilot state is terminal and exact-session artifacts remain coherent.\n</Final_Checklist>\n\n<Examples>\n<Good>\nUser: `$autopilot implement issue #42`\nFlow: activate Autopilot at `deep-interview`, crystallize requirements, continue to supervised `ralplan`, then supervised `ultragoal`, verify the completed outcome, and mark the exact session complete.\n</Good>\n\n<Good>\nUser: `continue`\nContext: Autopilot state has `current_phase:\"ralplan\"`.\nFlow: resume the existing plan from the deep-interview handoff; do not create a separate standalone Ralplan run.\n</Good>\n\n<Bad>\nFlow: treat `$deep-interview`, `$ralplan`, and `$ultragoal` as optional suggestions and jump directly to implementation.\nWhy bad: this hollows out Autopilot's defining orchestration contract.\n</Bad>\n</Examples>\n\nTask: {{ARGUMENTS}}\n","frontmatter":{"name":"autopilot","description":"[OMX] Canonical autonomous orchestrator: $deep-interview -> $ralplan -> $ultragoal"},"isInternal":false,"tokens":1735,"sizeBytes":7958},{"name":"SKILL.md","path":"skills/autoresearch-goal/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/autoresearch-goal/SKILL.md","title":"autoresearch-goal","category":"anthropic-skill","format":"markdown","content":"---\nname: autoresearch-goal\ndescription: Sunset stub — use $autoresearch instead\n---\n\n# Autoresearch-goal — removed\n\n`$autoresearch-goal` was removed in OMX 0.21; use `$autoresearch` instead.\n\nAutoresearch-goal was a duplicate research-over-goal-mode entry point. `$autoresearch` is the single canonical validator-gated research loop; it owns the research mission lifecycle that autoresearch-goal duplicated.\n\nMigration: replace `$autoresearch-goal` with `$autoresearch`.\n\nTask: {{ARGUMENTS}}\n","frontmatter":{"name":"autoresearch-goal","description":"Sunset stub — use $autoresearch instead"},"isInternal":false,"tokens":117,"sizeBytes":497},{"name":"SKILL.md","path":"skills/autoresearch/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/autoresearch/SKILL.md","title":"autoresearch","category":"anthropic-skill","format":"markdown","content":"---\nname: autoresearch\ndescription: Stateful validator-gated research loop with native-hook persistence\n---\n\n# Autoresearch\n\nAutoresearch is the skill-first replacement for the deprecated `omx autoresearch` command.\nIt keeps the useful measured-research loop, but it now runs as a native-hook stateful workflow instead of a direct CLI or tmux launch surface.\n\n## Boundary with planning research\n\nUse `$autoresearch` when the research output itself is a bounded deliverable that must pass an explicit validator. Do not recommend it for ordinary pre-planning docs lookup or general best-practice checks; use `$best-practice-research` for that. If `$autoresearch` is intentionally run before architecture planning, its approved artifact should feed evidence into `$ralplan`; it should not become a final architecture/component unless the user explicitly asks for ongoing research automation.\n\n## Use when\n- You want a Ralph-ish persistent research loop\n- The task should keep nudging until explicit validation evidence exists\n- You want init-time choice between script validation and prompt+architect validation\n\n## Do not use when\n- You want the old `omx autoresearch` command surface (hard-deprecated)\n- You want detached tmux or split-pane launch parity\n- You have not decided the validation regime yet\n\n## Core contract\n1. **Init chooses validation mode.** Pick exactly one:\n - `mission-validator-script`\n - `prompt-architect-artifact`\n2. **Persist mode state** in `.omx/state/.../autoresearch-state.json` including:\n - `validation_mode`\n - `completion_artifact_path`\n - `mission_validator_command` **or** `validator_prompt`\n - optional `output_artifact_path`\n3. **Completion is artifact-gated.** The loop does not stop because the model says “done”, because a stop hook fired once, or because several turns were no-ops.\n4. **Direct CLI launch is gone.** Use `$deep-interview --autoresearch` for intake and `$autoresearch` for execution.\n\n## Completion artifact contract\n\n### `mission-validator-script`\nThe completion artifact must exist and record a passing validator result, for example:\n\n```json\n{\n \"status\": \"passed\",\n \"passed\": true,\n \"summary\": \"metric improved beyond baseline\"\n}\n```\n\n### `prompt-architect-artifact`\nThe completion artifact must include both an architect approval verdict and an output artifact path, for example:\n\n```json\n{\n \"validator_prompt\": \"Review the research output against the mission.\",\n \"architect_review\": { \"verdict\": \"approved\" },\n \"output_artifact_path\": \".omx/specs/autoresearch-demo/report.md\"\n}\n```\n\n## Recommended flow\n1. Run `$deep-interview --autoresearch` to clarify mission + evaluator.\n2. Materialize `.omx/specs/autoresearch-{slug}/mission.md`, `sandbox.md`, and `result.json`.\n3. Start `$autoresearch` with the chosen validation mode stored in mode state.\n4. Let stop-hook / auto-nudge continue until the completion artifact satisfies the chosen validation mode.\n5. Finish only after the validator artifact is complete.\n\n## Migration note\n- `omx autoresearch` is hard-deprecated.\n- No direct CLI launch.\n- No tmux split-pane launch.\n- No noop-count completion gate.\n","frontmatter":{"name":"autoresearch","description":"Stateful validator-gated research loop with native-hook persistence"},"isInternal":false,"tokens":708,"sizeBytes":3139},{"name":"SKILL.md","path":"skills/best-practice-research/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/best-practice-research/SKILL.md","title":"best-practice-research","category":"anthropic-skill","format":"markdown","content":"---\nname: best-practice-research\ndescription: \"[OMX] Bounded best-practice research wrapper using official/upstream evidence first\"\nargument-hint: \"<technology|decision|practice question>\"\n---\n\n# Best-Practice Research\n\nUse this skill when a task depends on current external best practices, version-aware guidance, standards, official recommendations, or upstream behavior. This is a workflow wrapper: it routes evidence gathering and synthesis; it is not a new research authority and it does not replace `researcher`.\n\n## Purpose\n\nProduce a cited, reusable best-practice answer or handoff that separates current external evidence from repo-local facts and dependency-selection decisions. For pre-planning investigation, this is the ordinary first research wrapper: gather official/upstream evidence, then hand it to `$ralplan` or the caller as planning input. Do not present `$best-practice-research` as a final architecture component or as a validator-gated research loop.\n\n## Terminal By Default\n\nThis skill is terminal and read-only by default. It gathers evidence and produces a cited recommendation with a handoff, then stops. Do not write or edit files, create or amend commits, run mutating commands, or otherwise modify repository state under this skill — even when the question has clear implementation implications. When implementation is warranted, stop and hand off rather than continuing: name `$ralplan` for planning and `$ultragoal`, `$team`, or `executor` for execution, and resume only after the user explicitly switches to that workflow.\n\n## Activate When\n\n- The user asks for best practices, recommended approach, current guidance, official recommendations, standards, or version-aware external behavior.\n- `$ralplan`, `$deep-interview`, `$team`, or another workflow needs current external evidence before planning or execution can be correct.\n- The task involves an already chosen technology and needs authoritative usage guidance, migration notes, API behavior, lifecycle rules, or current safety guidance.\n\n## Do Not Activate When\n\n- The answer is fully repo-local; use `explore` for codebase facts.\n- The main question is whether to adopt, replace, upgrade, or compare dependencies; use `dependency-expert`.\n- The user only needs implementation against already-grounded requirements; execute directly, or use `$team` when coordinated parallel work is warranted.\n- The task can be answered from stable local project conventions without current external lookup.\n\n## Specialist Routing\n\n1. Use `explore` first for brownfield facts: current code usage, local constraints, versions, config, and integration points.\n2. Use `researcher` for official/upstream docs, release notes, standards, migration guides, source-backed examples, and current best-practice evidence for an already chosen technology.\n3. Use `dependency-expert` only for adoption/upgrade/replacement/comparison decisions.\n4. Return to the caller with explicit evidence, uncertainty, and any implementation handoff constraints.\n\n## Source-Quality Rules\n\n- Prefer official documentation, upstream source, release notes, changelogs, standards, and maintainer guidance.\n- Include source URLs for material claims.\n- State date/version context for current best-practice claims.\n- Label third-party summaries as supplemental; do not use them before official/upstream sources.\n- Flag stale, conflicting, undocumented, or version-mismatched evidence.\n- Do not over-fetch: gather the smallest evidence set that can support the decision.\n\n## Workflow\n\n1. Classify the question: conceptual best practice, implementation guidance, migration/version guidance, standards/compliance guidance, or mixed local + external guidance.\n2. Gather repo-local facts with `explore` when local usage or constraints affect the answer.\n3. Gather external evidence with `researcher` when current or version-aware practice affects correctness.\n4. Synthesize a concise answer with source quality, version/date context, caveats, and an implementation or planning handoff.\n5. Stop when the answer is grounded enough for the caller; otherwise report the exact blocker or specialist handoff needed.\n\n## Output Contract\n\n```md\n## Best-Practice Research: <question>\n\n### Direct Recommendation\n<actionable guidance or decision support>\n\n### Evidence Used\n- Official/upstream: <source URL> — <what it establishes>\n- Supplemental, if any: <source URL> — <why it is secondary>\n\n### Version / Date Context\n<versions, dates, release channels, or unknowns>\n\n### Repo-Local Context\n<facts from explore, or \"not needed\">\n\n### Boundaries / Non-goals\n<what this research does not decide>\n\n### Handoff\n<planning/execution/test implications; name the next workflow — `$ralplan` for planning, `$ultragoal`/`$team`/`executor` for execution — and note that this skill stops here unless the user explicitly switches workflows>\n```\n\n## Stop Rules\n\n- Stop after a source-backed recommendation is reusable by the caller.\n- Stop and route upward if the task becomes dependency comparison, broad architecture, or implementation.\n- Do not continue researching when remaining work would only polish wording rather than change the recommendation.\n- This skill never implements. After delivering the recommendation and handoff, stop; do not modify repo files or repo state. Resume only when the user explicitly switches to a planning or implementation workflow named in the handoff.\n\nTask: {{ARGUMENTS}}\n","frontmatter":{"name":"best-practice-research","description":"[OMX] Bounded best-practice research wrapper using official/upstream evidence first","argument-hint":"<technology|decision|practice question>"},"isInternal":false,"tokens":1085,"sizeBytes":5433},{"name":"SKILL.md","path":"skills/cancel/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/cancel/SKILL.md","title":"cancel","category":"anthropic-skill","format":"markdown","content":"---\nname: cancel\ndescription: Cancel any active OMX mode (autopilot, ralph, ultrawork, ecomode, ultraqa, swarm, ultrapilot, pipeline, team)\n---\n\n# Cancel Skill\n\n## When to use\n\nUse `/cancel` (or `cancelomc` / `stopomc`) to stop an active OMX mode and perform its documented cleanup. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot` first; it is the invariant authority for scope, ownership, hooks, and Team cleanup.\n\n## Inputs and preconditions\n\n- Accepted forms are `/cancel` and `/cancel --force`.\n- Reject `--all`, unknown flags, repeated flags, and mixed flags before mutation.\n- Discover the current session/root with the state read surfaces before cleanup:\n ```bash\n omx state list-active --json\n omx state get-status --mode <mode> --json\n ```\n- Confirm the current session/root and exact target before cleanup; stop when the required evidence is missing.\n\n## Operational steps\n\n1. Parse and validate arguments; select one exact session/root scope.\n2. Inspect active modes in dependency order:\n `autopilot → ralph → ultrawork → ecomode → ultraqa → swarm → ultrapilot → pipeline → team → plan-consensus`.\n3. Cancel Autopilot while preserving its resumable state; clean only linked child modes it owns.\n4. For Ralph, terminalize the target state (`active:false`, `current_phase:\"cancelled\"`, `completed_at`) and terminalize a proven linked Ultrawork/Ecomode state in the same scope. Confirm the post-conditions in `docs/contracts/ralph-cancel-contract.md`.\n5. Clear standalone modes only after proving they are not linked to another active mode.\n6. For Team, inspect the runtime with `omx team status <team> --json`; use `omx team shutdown <team>` after the normal completion gate, or follow the explicit abort path.\n7. Clear only the selected mode/session state through the state API, for example:\n ```bash\n omx state clear --input '{\"mode\":\"<mode>\",\"session_id\":\"<session>\"}' --json\n ```\n8. With `--force`, perform its documented native-stop cleanup. Report rollback or cleanup failures rather than claiming success.\n\n## Exit and evidence\n\nReport one result per selected mode: mode, scope/session, terminal phase, preserved state, linked cleanup, and any refusal reason. A clean no-op reports `No active OMX modes detected.` Include Team status and shutdown evidence when Team was selected.\n","frontmatter":{"name":"cancel","description":"Cancel any active OMX mode (autopilot, ralph, ultrawork, ecomode, ultraqa, swarm, ultrapilot, pipeline, team)"},"isInternal":false,"tokens":543,"sizeBytes":2337},{"name":"SKILL.md","path":"skills/code-review/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/code-review/SKILL.md","title":"code-review","category":"anthropic-skill","format":"markdown","content":"---\nname: code-review\ndescription: Run a comprehensive code review\n---\n\n# Code Review Task Card\n\nUse this explicit opt-in for a merge-readiness review. Shared operating invariants\nlive in `templates/AGENTS.md`; this card only defines review-specific behavior.\n\n## When to use\n\n- The user asks for a code review or quality/security assessment.\n- A change is ready for review before merge, or a major feature needs an independent review.\n- Do not activate this card for implementation, broad planning, or automatic cleanup.\n\n## Inputs\n\n- Scope: the requested files, commit, PR, or whole diff.\n- Requirements/specification, acceptance criteria, and relevant test/CI evidence.\n- Existing review artifacts and known risks, if any.\n- If the user says `continue`, advance the current verified review step rather than restarting discovery.\n\nStart by recording the scope:\n\n```sh\ngit status --short\ngit diff --stat\ngit diff -- <scope>\n```\n\n## Execution\n\n1. Identify changed files and review boundaries; do not silently widen the scope.\n2. Launch the `code-reviewer` and `architect` agents in parallel. Both lanes run in parallel on a clean context with explicit scope and artifacts. If either lane cannot be launched or does not return evidence, report `independent review unavailable`; do **not** substitute the current/authoring lane, and do **not** approve or mark the review merge-ready.\n3. Respect the user's current model and reasoning/effort selection. Do not pass `model` or `reasoning_effort` overrides in review-lane calls.\n\n```text\ntask(\n agent_type=\"code-reviewer\",\n prompt=\"CODE REVIEW TASK\n\nReview the supplied scope for spec compliance, security, quality, performance, and maintainability.\nReturn files reviewed, severity-rated findings with file:line evidence and concrete fixes,\nand a recommendation: APPROVE / REQUEST CHANGES / COMMENT. Do not review architecture.\nScope: [scope and artifacts]\"\n)\n\ntask(\n agent_type=\"architect\",\n prompt=\"ARCHITECTURE / DEVIL'S-ADVOCATE REVIEW TASK\n\nReview the same scope for boundaries, interfaces, hidden coupling, long-term tradeoffs,\nand the strongest counterargument against approval. Return file:line evidence,\nrecommendations, and Architectural Status: CLEAR / WATCH / BLOCK.\nScope: [scope and artifacts]\"\n)\n```\n\n## Review taxonomy\n\n- `code-reviewer` checks **Security**, **Code Quality**, **Performance**, **Best Practices**, and **Maintainability**.\n- Rate each finding: **CRITICAL** (security or data-loss blocker), **HIGH** (bug/major smell), **MEDIUM** (important improvement), or **LOW** (style/suggestion).\n- `architect` checks explicit boundaries/interfaces, hidden coupling, long-horizon tradeoffs, and devil's-advocate concerns. Status is **CLEAR**, **WATCH** (non-blocking concern), or **BLOCK** (merge blocker).\n- Every finding names `file:line`, issue, risk, and a concrete fix; distinguish facts from suggestions.\n\n## State/HUD Phase Contract\n\n- Standalone `$code-review` relies on hook-owned `skill-active-state.json` (`skill:\"code-review\"`, `phase:\"planning\"`); do not create `code-review-state.json`.\n- Inside Autopilot, keep `mode:\"autopilot\"` active with `current_phase:\"code-review\"` / skill-active `phase:\"code-review\"`; do not activate a peer workflow.\n- On clean review, persist the artifact under Autopilot `handoff_artifacts.code_review` before moving to `ultraqa`. On non-clean review, persist findings and use `rework` or `ralplan` as appropriate.\n\n```sh\nomx state write --input '{\"mode\":\"autopilot\",\"active\":true,\"current_phase\":\"code-review\"}' --json\n```\n\n## Final Synthesis and gate\n\n### Architectural Status Contract\n\nCombine the `code-reviewer` recommendation and architect status. Approval requires explicit evidence from both independent lanes; missing or failed delegation is a blocking unavailable-review state, not an approval fallback. The final report must make architect blockers impossible to miss.\n\n- If architect status is **BLOCK**, final recommendation is **REQUEST CHANGES**.\n- Else if `code-reviewer` recommendation is **REQUEST CHANGES**, final recommendation is **REQUEST CHANGES**.\n- Else if architect status is **WATCH**, final recommendation is **COMMENT**.\n- Else final recommendation follows the `code-reviewer` lane.\n\nApproval criteria: **APPROVE** only when `code-reviewer` returns APPROVE, architect status is `CLEAR`, and both independent lanes returned evidence. **REQUEST CHANGES** for a blocker, unresolved high/critical finding, or unavailable lane. **COMMENT** may record non-blocking findings.\n\nDo not self-review as a fallback. If the `code-reviewer` or `architect` path is missing, unavailable, skipped, or fails, block approval until independent lane evidence exists. On the supported `omx ralph` CLI compatibility path, findings may trigger automatic fix follow-up without another permission prompt; plain `code-review` itself remains read-only and does **not** promise auto-fix.\n\n## Evidence/output contract\n\nReturn a concise report containing:\n\n```text\nCODE REVIEW REPORT\nFiles Reviewed: <count>\nTotal Issues: 0\nArchitectural Status: CLEAR | WATCH | BLOCK\nCRITICAL (0) | HIGH (0) | MEDIUM (0) | LOW (0)\nFindings: file:line -> issue, risk, concrete fix (or none)\nARCHITECTURE WATCHLIST: concern, status, recommendation (or none)\n- code-reviewer recommendation: COMMENT\n- architect status: WATCH\n- final recommendation: COMMENT\nRECOMMENDATION: COMMENT\n```\n\nReplace the illustrative counts and verdict with observed values. Include scope,\nlane evidence/artifact references, unresolved risks, and validation gaps.\n\n## Exit condition\n\nStop when the scoped diff has two independent lane results and a deterministic final\nrecommendation. Report `APPROVE` only under the approval criteria; otherwise leave a\nbounded `REQUEST CHANGES`, `COMMENT`, or unavailable-review result. Never claim\nmerge-ready without the required evidence.\n","frontmatter":{"name":"code-review","description":"Run a comprehensive code review"},"isInternal":false,"tokens":1289,"sizeBytes":5845},{"name":"SKILL.md","path":"skills/configure-notifications/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/configure-notifications/SKILL.md","title":"configure-notifications","category":"anthropic-skill","format":"markdown","content":"---\nname: configure-notifications\ndescription: Configure OMX notifications - unified entry point for all platforms\ntriggers:\n - \"configure notifications\"\n - \"setup notifications\"\n - \"notification settings\"\n - \"configure discord\"\n - \"configure telegram\"\n - \"configure slack\"\n - \"configure openclaw\"\n - \"setup discord\"\n - \"setup telegram\"\n - \"setup slack\"\n - \"setup openclaw\"\n - \"discord notifications\"\n - \"telegram notifications\"\n - \"slack notifications\"\n - \"openclaw notifications\"\n - \"discord webhook\"\n - \"telegram bot\"\n - \"slack webhook\"\n---\n\n# Configure OMX Notifications\n\nUse this card for Discord, Telegram, Slack, generic command aliases, or OpenClaw. Shared safety, lifecycle, hook, team, autonomy, and cancellation rules live in `templates/AGENTS.md`.\n\n## 1. Inspect and choose a path\n\n```bash\nCONFIG_FILE=\"$HOME/.codex/.omx-config.json\"\nif [ -f \"$CONFIG_FILE\" ]; then\n jq -r '{notifications_enabled:(.notifications.enabled // false), discord:(.notifications.discord.enabled // false), discord_bot:(.notifications[\"discord-bot\"].enabled // false), telegram:(.notifications.telegram.enabled // false), slack:(.notifications.slack.enabled // false), openclaw:(.notifications.openclaw.enabled // false), custom_webhook_command:(.notifications.custom_webhook_command.enabled // false), custom_cli_command:(.notifications.custom_cli_command.enabled // false), verbosity:(.notifications.verbosity // \"session\"), idleCooldownSeconds:(.notifications.idleCooldownSeconds // 60), reply_enabled:(.notifications.reply.enabled // false)}' \"$CONFIG_FILE\"\nelse\n echo \"NO_CONFIG_FILE\"\nfi\n```\n\nUse AskUserQuestion to choose: Discord native (webhook or bot), Telegram native (bot token + chat id), Slack native (incoming webhook), `custom_webhook_command`, `custom_cli_command`, cross-cutting settings, or disable all notifications.\n\n## 2. Native providers\n\nCollect and validate provider values, then write only these native keys: `notifications.discord`, `notifications[\"discord-bot\"]`, `notifications.telegram`, or `notifications.slack`. Do not represent native providers with generic aliases.\n\n## 3. Generic aliases\n\nFor `custom_webhook_command`, collect URL, optional headers, method (`POST` default or `PUT`), events (`session-end`, `ask-user-question`, `session-start`, `session-idle`, `stop`), and an instruction template:\n\n```bash\njq --arg url \"$URL\" --arg method \"${METHOD:-POST}\" --arg instruction \"${INSTRUCTION:-OMX event {{event}} for {{projectPath}}}\" --argjson headers \"${HEADERS_JSON:-{}}\" '.notifications=(.notifications//{enabled:true})|.notifications.enabled=true|.notifications.custom_webhook_command={enabled:true,url:$url,headers:$headers,method:$method,instruction:$instruction,events:[\"session-end\",\"ask-user-question\"]}' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\nFor `custom_cli_command`, collect a command template (`{{event}}`, `{{instruction}}`, `{{sessionId}}`, `{{projectPath}}`), optional events, and an instruction template:\n\n```bash\njq --arg command \"$COMMAND_TEMPLATE\" --arg instruction \"${INSTRUCTION:-OMX event {{event}} for {{projectPath}}}\" '.notifications=(.notifications//{enabled:true})|.notifications.enabled=true|.notifications.custom_cli_command={enabled:true,command:$command,instruction:$instruction,events:[\"session-end\",\"ask-user-question\"]}' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\nOpenClaw dispatch requires `OMX_OPENCLAW=1`; command gateways additionally require `OMX_OPENCLAW_COMMAND=1`; timeout precedence is `gateways.<name>.timeout` > `OMX_OPENCLAW_COMMAND_TIMEOUT_MS` > `5000` ms.\n\n## 4. OpenClaw + Clawdbot agent mode\n\nUse this only when the requested route is a `clawdbot agent` turn delivered to Discord. The `session-stop` notification intentionally maps to the OpenClaw `stop` hook. OMX shell-escapes substitutions; keep instructions short, avoid untrusted shell metacharacters, append `|| true`, and append JSONL logs with `>>`.\n\n```bash\njq --arg command \"(clawdbot agent --session-id omx-hooks --message {{instruction}} --thinking minimal --deliver --reply-channel discord --reply-to 'channel:CHANNEL_ID' --timeout 120 --json >>/tmp/omx-openclaw-agent.jsonl 2>&1 || true)\" '.notifications=(.notifications//{enabled:true})|.notifications.enabled=true|.notifications.verbosity=\"verbose\"|.notifications.openclaw={enabled:true,gateways:{local:{type:\"command\",command:$command,timeout:120000}},hooks:{\"session-start\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-start project={{projectName}} session={{sessionId}} tmux={{tmuxSession}}. 한국어로 상태를 #omc-dev에 공유하고 SOUL.md를 참고하세요.\"},\"session-idle\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-idle session={{sessionId}} tmux={{tmuxSession}}. 한국어로 팔로업을 #omc-dev에 안내하세요.\"},\"ask-user-question\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=ask-user-question session={{sessionId}} tmux={{tmuxSession}} question={{question}}. 한국어로 응답 필요를 #omc-dev에 알리세요.\"},\"stop\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-stop session={{sessionId}} tmux={{tmuxSession}}. 한국어로 중단 상태를 전달하세요.\"},\"session-end\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-end session={{sessionId}} tmux={{tmuxSession}} reason={{reason}}. 한국어로 완료 요약을 #omc-dev에 남기세요.\"}}}' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\n### Compatibility + precedence contract\n\nExplicit `notifications.openclaw` wins when valid; generic aliases are ignored with a warning.\n\nVerify this mode and inspect evidence without hiding output:\n\n```bash\nclawdbot agent --session-id omx-hooks --message \"OMX hook test via clawdbot agent path\" --thinking minimal --deliver --reply-channel discord --reply-to 'channel:CHANNEL_ID' --timeout 120 --json\ntmux list-sessions -F '#{session_name}' | rg '^omx-' || true\njq '.notifications.openclaw.hooks' \"$CONFIG_FILE\"\ntail -n 120 /tmp/omx-openclaw-agent.jsonl | jq -s '.[] | {timestamp:(.timestamp // .time),status:(.status // .error // \"ok\")}'\nrg '\"error\"|\"failed\"|\"timeout\"' /tmp/omx-openclaw-agent.jsonl | tail -20\n```\n\nFor HTTP integrations, run both a `/hooks/wake` smoke test and `/hooks/agent` delivery verification.\n\n## 5. Cross-cutting settings and disable\n\n- Verbosity: `minimal`, `session` (recommended), `agent`, or `verbose`.\n- Idle cooldown: `notifications.idleCooldownSeconds` (environment override: `OMX_IDLE_COOLDOWN_SECONDS`).\n- Profiles: `notifications.profiles` and `notifications.defaultProfile`.\n- Reply listener: `notifications.reply.enabled`; gates are `OMX_REPLY_ENABLED=true` and, for Discord, `OMX_REPLY_DISCORD_USER_IDS=...`. An authorized Discord bot operator may exact-match `status` on a tracked notification for a bounded read-only session summary.\n\nDisable all notifications:\n\n```bash\njq '.notifications.enabled=false' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\n## Exit evidence\n\nRun `jq empty \"$CONFIG_FILE\"` after edits. Report the config path, enabled native providers, enabled aliases, whether valid `notifications.openclaw` overrides aliases, verbosity, idle cooldown, reply-listener state, and smoke-test results. Stop when the JSON parses and the selected path has its required evidence; do not claim delivery from configuration alone.\n","frontmatter":{"name":"configure-notifications","description":"Configure OMX notifications - unified entry point for all platforms","triggers":["configure notifications","setup notifications","notification settings","configure discord","configure telegram","configure slack","configure openclaw","setup discord","setup telegram","setup slack","setup openclaw","discord notifications","telegram notifications","slack notifications","openclaw notifications","discord webhook","telegram bot","slack webhook"]},"isInternal":false,"tokens":1808,"sizeBytes":7423},{"name":"SKILL.md","path":"skills/deep-interview/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/deep-interview/SKILL.md","title":"deep-interview","category":"anthropic-skill","format":"markdown","content":"---\nname: deep-interview\ndescription: Socratic deep interview with mathematical ambiguity gating before execution\nargument-hint: \"[--quick|--standard|--deep] [--autoresearch] <idea or vague description>\"\n---\n\n<Purpose>\nDeep Interview is an intent-first Socratic clarification loop before planning or implementation. It turns vague ideas into execution-ready specifications by asking targeted questions about why the user wants a change, how far it should go, what should stay out of scope, and what OMX may decide without confirmation.\n</Purpose>\n\n<Use_When>\n- The request is broad, ambiguous, or missing concrete acceptance criteria\n- The user says \"deep interview\", \"interview me\", \"ask me everything\", \"don't assume\", or \"ouroboros\"\n- The user wants to avoid misaligned implementation from underspecified requirements\n- You need a requirements artifact before handing off to `ralplan`, `autopilot`, `ultragoal`, or `team`\n</Use_When>\n\n<Do_Not_Use_When>\n- The request already has concrete file/symbol targets and clear acceptance criteria\n- The user explicitly asks to skip planning/interview and execute immediately\n- The user asks for lightweight brainstorming only (use `plan` instead)\n- A complete PRD/plan already exists and execution should start\n</Do_Not_Use_When>\n\n<Why_This_Exists>\nExecution quality is usually bottlenecked by intent clarity, not just missing implementation detail. A single expansion pass often misses why the user wants a change, where the scope should stop, which tradeoffs are unacceptable, and which decisions still require user approval. This workflow applies Socratic pressure + quantitative ambiguity scoring so orchestration modes begin with an explicit, testable, intent-aligned spec.\n</Why_This_Exists>\n\n<Depth_Profiles>\n- **Quick (`--quick`)**: fast pre-PRD pass; target threshold `<= 0.30`; max rounds 5\n- **Standard (`--standard`, default)**: full requirement interview; target threshold `<= 0.20`; max rounds 12\n- **Deep (`--deep`)**: high-rigor exploration; target threshold `<= 0.15`; max rounds 20\n- **Autoresearch (`--autoresearch`)**: same interview rigor as Standard, but specialized for `$autoresearch` mission readiness and `.omx/specs/` artifact handoff\n\nProfile `max rounds` is a hard cap, not a target. Do not continue only to reach a numbered round count. Extra Socratic rigor does not override the active threshold unless the profile/config changes.\n\nIf no flag is provided, use **Standard**.\n\n<Mode_Flags>\n- **`--autoresearch`**: switch the interview into autoresearch-intake mode for `$autoresearch` handoff. In this mode, the interview should converge on a validator-ready research mission, write canonical artifacts under `.omx/specs/`, and preserve the explicit `refine further` vs `launch` boundary for downstream skill intake.\n</Mode_Flags>\n</Depth_Profiles>\n\n<Execution_Policy>\n- Ask ONE question per round (never batch multiple interview rounds into one `questions[]` form)\n- Ask about intent and boundaries before implementation detail\n- Target the weakest clarity dimension each round after applying the stage-priority rules below\n- Treat every answer as a claim to pressure-test before moving on: the next question should usually demand evidence or examples, expose a hidden assumption, force a tradeoff or boundary, or reframe root cause vs symptom\n- Do not rotate to a new clarity dimension just for coverage when the current answer is still vague; stay on the same thread until one layer deeper, one assumption clearer, or one boundary tighter\n- Before crystallizing, complete at least one explicit pressure pass that revisits an earlier answer with a deeper, assumption-focused, or tradeoff-focused follow-up\n- Gather codebase facts via `explore` before asking user about internals\n- `omx explore` is deprecated. Use normal repository inspection tools/subagents for simple read-only brownfield fact gathering; use `omx sparkshell` only for explicit shell-native read-only evidence, and keep ambiguous or non-shell-only investigation on the richer normal path.\n- Always run a preflight context intake before the first interview question\n- For brownfield work, preflight must include doc/context grounding before user-facing questions: inspect applicable `AGENTS.md` files, README/getting-started docs, relevant `docs/` contracts/plans/ADRs, existing `.omx/context/` snapshots, and any project-local glossary/context files such as `CONTEXT.md` or `CONTEXT-MAP.md` when present.\n- Treat existing repo language as evidence, not authority: if the user uses a fuzzy, overloaded, or conflicting term, surface the specific doc/code wording and ask which meaning should govern before implementation.\n- Cross-check user claims about current behavior against code or documented contracts when discoverable. If docs and code disagree, ask a confirmation question that names both sources instead of silently choosing one.\n- Use scenario-based edge-case grilling when relationships, boundaries, or handoff behavior are unclear: invent one concrete scenario that stresses the ambiguous boundary, then ask one focused question about the expected outcome.\n- Durable docs, glossary, ADR, or memory updates are opt-in and public-safe only. Deep-interview may recommend such updates in the handoff summary, but must not automatically create or dump public docs from interview transcripts unless the user explicitly chooses that as in-scope.\n- If initial context is oversized or would exceed the prompt budget, do not paste or forward the raw payload into interview prompts; request and record a prompt-safe initial-context summary first\n- The oversized initial-context summary gate is blocking: wait for the concise summary before ambiguity scoring, crystallizing artifacts, or any downstream execution handoff\n- The summary must preserve goals, constraints, success criteria, non-goals, decision boundaries, and references to any full source documents so downstream consumers receive a prompt-safe but faithful context\n- Keep total prompt payloads within a safe budget by summarizing or trimming retained history; preserve newest/highest-signal answers and never let raw oversized context crowd out the current question\n- Reduce user effort: ask only the highest-leverage unresolved question, and never ask the user for codebase facts that can be discovered directly\n- For brownfield work, prefer evidence-backed confirmation questions such as \"I found X in Y. Should this change follow that pattern?\"\n- Route facts before judgment in the Ouroboros style: before presenting a user-facing interview round, classify whether the needed information is a discoverable fact, a fact needing confirmation, or a human decision. The interview is with the human for judgment, not for facts the agent can inspect.\n- When unresolved ambiguity depends on current external best practices, official/upstream guidance, standards, or version-aware behavior, use `$best-practice-research` as the bounded evidence wrapper before crystallizing requirements or handing off to planning/execution.\n- Use these transcript/spec labels only; never use them as `omx question` `source` values, and never replace the runtime `source: \"deep-interview\"` contract for user-facing deep-interview questions:\n - `[from-code][auto-confirmed]` — exact, high-confidence codebase facts from manifests/configs or direct source evidence, with no prescription attached.\n - `[from-code]` — codebase findings that are useful but inferred, pattern-based, or low/medium confidence and therefore need a confirmation-style user-facing round before being treated as settled.\n - `[from-research]` — externally sourced facts such as API limits, compatibility, or public documentation; facts only, not decisions.\n - `[from-user]` — goals, preferences, business logic, scope, non-goals, acceptance criteria, tradeoffs, and any decision-bearing interpretation.\n- Treat `[from-code][auto-confirmed]` and other non-user fact discoveries as context/transcript updates, not interview rounds: do not call `omx question`, do not create a pending deep-interview question obligation, and do not increment the user-facing round number for facts the agent can safely establish.\n- Auto-confirm only descriptive facts. If a finding implies what the new feature should do, which pattern it should follow, which tradeoff to accept, or what should stay in/out of scope, route the entire decision-bearing question to the user as `[from-user]` even when code or research facts are available.\n- In attached-tmux Codex CLI, deep-interview uses `omx question` as the required OMX-owned structured questioning path for every interview round\n- When invoking `omx question` through attached-tmux Bash/tool paths, preserve the leader-pane return target by prefixing the command with `OMX_QUESTION_RETURN_PANE=$TMUX_PANE` (or a concrete `%pane` value)\n- If you launch `omx question` in a background terminal, immediately wait for that background terminal to finish and read its JSON answer before scoring ambiguity, asking another round, or handing off\n- Treat `answers[]` as the primary `omx question` success contract. For a single interview round, read `answers[0].answer`; use legacy top-level `answer` only as a compatibility fallback when needed.\n- If the current runtime is outside tmux and cannot render `omx question`, use the native structured question tool when available; otherwise ask exactly one concise plain-text question and wait for the answer\n- Re-score ambiguity after each answer and show progress transparently\n- Once ambiguity is at or below the active profile threshold, stop ordinary questioning. Run the practical closure audit: crystallize/handoff when readiness gates pass; otherwise ask only the final closure question needed to satisfy a named gate.\n- Treat `max_rounds` as a stop cap, not evidence that more rounds are needed.\n- Do not hand off to execution while ambiguity remains above threshold unless user explicitly opts to proceed with warning\n- Do not crystallize or hand off while `Non-goals` or `Decision Boundaries` remain unresolved, even if the weighted ambiguity threshold is met\n- Treat early exit as a safety valve, not the default success path\n- Persist mode state for resume safety only through the CLI/programmatic single-writer authority (`omx state write/read --input '<json>' --json`, backed by `src/state/operations.ts`). The MCP state server is a read-only projection and must never become a second writer.\n</Execution_Policy>\n\n<Steps>\n\n## Phase 0: Preflight Context Intake\n\n1. Parse `{{ARGUMENTS}}` and derive a short task slug.\n2. Attempt to load the latest relevant context snapshot from `.omx/context/{slug}-*.md`.\n3. Check whether the provided initial context or loaded snapshot is too large for safe prompt use. If it is oversized, the first interview round must ask for a concise prompt-safe summary instead of scoring ambiguity or continuing to downstream handoff.\n4. If no snapshot exists, create a minimum context snapshot with:\n - Task statement\n - Desired outcome\n - Stated solution (what the user asked for)\n - Probable intent hypothesis (why they likely want it)\n - Known facts/evidence\n - Constraints\n - Unknowns/open questions\n - Decision-boundary unknowns\n - Likely codebase touchpoints\n - Relevant repo docs/rules/context inspected\n - Terminology or doc/code conflicts found\n - Prompt-safe initial-context summary status (`not_needed`, `needed`, or `recorded`)\n5. For brownfield tasks, inspect the applicable documentation/rule surface before the first user-facing round. Prefer exact, nearby sources over broad scans:\n - governing `AGENTS.md` files and template/runtime instruction surfaces that apply to the touched paths\n - README/getting-started docs and relevant docs under `docs/`, especially contracts, plans, ADR-like records, and workflow docs\n - existing `.omx/context/` snapshots, `.omx/specs/`, and planning artifacts relevant to the slug\n - project-local glossary/context files such as `CONTEXT.md`, `CONTEXT-MAP.md`, or context-specific docs when they exist\n6. Save snapshot to `.omx/context/{slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`) and reference it in mode state.\n\n## Phase 1: Initialize\n\n1. Parse `{{ARGUMENTS}}` and depth profile (`--quick|--standard|--deep`).\n2. Detect project context:\n - Run `explore` to classify **brownfield** (existing codebase target) vs **greenfield**.\n - For brownfield, collect relevant codebase context before questioning.\n3. Initialize state via `omx state write --input '{\"mode\":\"deep-interview\",\"active\":true}' --json`:\n\n```json\n{\n \"active\": true,\n \"current_phase\": \"deep-interview\",\n \"state\": {\n \"interview_id\": \"<uuid>\",\n \"profile\": \"quick|standard|deep\",\n \"type\": \"greenfield|brownfield\",\n \"initial_idea\": \"<user input>\",\n \"rounds\": [],\n \"current_ambiguity\": 1.0,\n \"threshold\": 0.3,\n \"max_rounds\": 5,\n \"challenge_modes_used\": [],\n \"codebase_context\": null,\n \"current_stage\": \"intent-first\",\n \"current_focus\": \"intent\",\n \"context_snapshot_path\": \".omx/context/<slug>-<timestamp>.md\"\n }\n}\n```\n\n4. Announce kickoff with profile, threshold, and current ambiguity.\n\n## Phase 2: Socratic Interview Loop\n\nRepeat until ambiguity `<= threshold`, the pressure pass is complete, the readiness gates are explicit, the user exits with warning, or max rounds are reached. This is a stop condition: below threshold, do not open a new ordinary interview branch.\n\n### 2a) Generate next question\nIf the initial context is oversized and no prompt-safe summary has been recorded yet, the next question must be only a summary request. Do not score ambiguity, do not run readiness gates, and do not hand off to `$ultragoal`, `$ralplan`, `$autopilot`, or `$team` until that summary answer is captured.\n\nUse:\n- Original idea\n- Prior Q&A rounds\n- Current dimension scores\n- Brownfield context (if any)\n- Doc/context grounding notes, including existing terminology, governing rules, and any doc/code mismatch\n- Activated challenge mode injection (Phase 3)\n\nTarget the lowest-scoring dimension, but respect stage priority:\n- **Stage 1 — Intent-first:** Intent, Outcome, Scope, Non-goals, Decision Boundaries\n- **Stage 2 — Feasibility:** Constraints, Success Criteria\n- **Stage 3 — Brownfield grounding:** Context Clarity (brownfield only)\n\nFollow-up pressure ladder after each answer:\n1. Ask for a concrete example, counterexample, or evidence signal behind the latest claim\n2. Probe the hidden assumption, dependency, or belief that makes the claim true\n3. Force a boundary or tradeoff: what would you explicitly not do, defer, or reject?\n4. Challenge fuzzy or conflicting terms against the repo's documented language and current code behavior\n5. Stress-test the boundary with one concrete scenario or edge case when a relationship or handoff remains ambiguous\n6. If the answer still describes symptoms, reframe toward essence / root cause before moving on\n\nPrefer staying on the same thread for multiple rounds when it has the highest leverage. Breadth without pressure is not progress.\n\nMaintain a **Breadth Ledger** across independent ambiguity tracks: scope, constraints, outputs, verification, brownfield integration, and any user-mentioned deliverable tracks. The ledger is a guard, not a mandatory rotation rule: stay deep on the current thread until it has been pressure-tested, then zoom out only when another material track remains unresolved and would change execution.\n\nMaintain a **Docs/Terminology Ledger** for brownfield interviews:\n- repo docs/rules/context sources inspected, with path references\n- canonical terms already used by the repo and terms to avoid or disambiguate\n- user terms that conflict with docs or current code behavior\n- doc/code mismatches that require a human decision before implementation\n- optional durable-doc follow-ups that are safe to propose but not auto-apply\n\nDetailed dimensions:\n- Intent Clarity — why the user wants this\n- Outcome Clarity — what end state they want\n- Scope Clarity — how far the change should go\n- Constraint Clarity — technical or business limits that must hold\n- Success Criteria Clarity — how completion will be judged\n- Context Clarity — existing codebase understanding (brownfield only)\n\n`Non-goals` and `Decision Boundaries` are mandatory readiness gates. Ask about them early and keep revisiting them until they are explicit.\n\n### 2b) Ask the question\nUse the surface-appropriate structured questioning path for every interview round. In attached-tmux sessions, use OMX-owned structured questioning via `omx question` (this is the required structured-question equivalent and required `AskUserQuestion` equivalent for deep-interview). Outside tmux, use native structured input when available; otherwise ask exactly one concise plain-text question and wait for the answer. Present:\n\n```\nRound {n} | Target: {weakest_dimension} | Ambiguity: {score}%\n\n{question}\n```\n\n`omx question` payload guidance for interview rounds:\n- Deep-interview is Socratic: ask one focused round at a time. Do not use batch `questions[]` to combine multiple interview rounds, even though `omx question` supports batch forms for other workflows.\n- Use canonical `type` values instead of authoring raw `multi_select` flags by hand. `type: \"single-answerable\"` is the default for one-path decisions; `type: \"multi-answerable\"` is the canonical shape for bounded multi-select rounds. The runtime will keep `multi_select` aligned with `type`.\n- Use `single-answerable` when exactly one answer should drive the next branch, the options are mutually exclusive, or selecting more than one answer would blur the decision boundary. Typical cases: handoff lane selection, choosing the primary failure mode, or confirming which of several competing interpretations is correct.\n- Use `multi-answerable` when multiple options may all be true at once and you need to capture a bounded set of coexisting constraints, non-goals, risks, or acceptance checks in one round. Typical cases: selecting all out-of-scope items, all success metrics that must hold, or all deployment constraints that apply together.\n- If one selected option would immediately require a follow-up question to disambiguate the others, prefer a `single-answerable` round now and ask the follow-up next. Do not hide a branching interview tree inside one overloaded multi-select prompt.\n- Keep interview options bounded and concrete. If the valid answers are already known, set `allow_other: false`; only leave `allow_other: true` when the interview genuinely needs one user-supplied option that cannot be enumerated in advance.\n- Read answers structurally from the primary `answers[]` array. For a normal single-round interview response, use `answers[0].answer` as the source of truth; the top-level `answer` field is a legacy single-question projection/fallback only.\n- For `single-answerable`, expect one decisive selection in the `value` field of `answers[0].answer` plus its selected-values metadata. For `multi-answerable`, treat the selected-values field inside `answers[0].answer` as the source of truth for all chosen constraints/non-goals and preserve the full set in the transcript/spec. In legacy single-question projections, this is equivalent to: For `multi-answerable`, treat `answer.selected_values` as the source of truth.\n\nCanonical bounded single-choice payload:\n\n```json\n{\n \"question\": \"Which execution lane should own this once the interview is complete?\",\n \"type\": \"single-answerable\",\n \"options\": [\n {\n \"label\": \"Plan first\",\n \"value\": \"ralplan\",\n \"description\": \"Need architecture and test-shape review before execution\"\n },\n {\n \"label\": \"Execute directly\",\n \"value\": \"autopilot\",\n \"description\": \"Requirements are already explicit enough for planning plus execution\"\n },\n {\n \"label\": \"Refine further\",\n \"value\": \"refine\",\n \"description\": \"Clarification is still needed before any handoff\"\n }\n ],\n \"allow_other\": false,\n \"other_label\": \"Other\",\n \"source\": \"deep-interview\"\n}\n```\n\nCanonical bounded multi-select payload:\n\n```json\n{\n \"question\": \"Which non-goals must stay out of scope for the first pass?\",\n \"type\": \"multi-answerable\",\n \"options\": [\n {\n \"label\": \"No UI redesign\",\n \"value\": \"no-ui-redesign\",\n \"description\": \"Keep layout and styling unchanged\"\n },\n {\n \"label\": \"No new dependencies\",\n \"value\": \"no-new-dependencies\",\n \"description\": \"Work within the existing toolchain\"\n },\n {\n \"label\": \"No API contract changes\",\n \"value\": \"no-api-contract-changes\",\n \"description\": \"Preserve external request and response shapes\"\n }\n ],\n \"allow_other\": false,\n \"other_label\": \"Other\",\n \"source\": \"deep-interview\"\n}\n```\n\nCanonical answer-shape reminders:\n\n```json\n{\n \"answer\": {\n \"kind\": \"option\",\n \"value\": \"ralplan\",\n \"selected_labels\": [\"Plan first\"],\n \"selected_values\": [\"ralplan\"]\n }\n}\n```\n\n```json\n{\n \"answer\": {\n \"kind\": \"multi\",\n \"value\": [\"no-new-dependencies\", \"no-api-contract-changes\"],\n \"selected_labels\": [\"No new dependencies\", \"No API contract changes\"],\n \"selected_values\": [\"no-new-dependencies\", \"no-api-contract-changes\"]\n }\n}\n```\n\n### 2c) Score ambiguity\nScore each weighted dimension in `[0.0, 1.0]` with justification + gap.\n\nGreenfield: `ambiguity = 1 - (intent × 0.30 + outcome × 0.25 + scope × 0.20 + constraints × 0.15 + success × 0.10)`\n\nBrownfield: `ambiguity = 1 - (intent × 0.25 + outcome × 0.20 + scope × 0.20 + constraints × 0.15 + success × 0.10 + context × 0.10)`\n\nReadiness gate:\n- `Non-goals` must be explicit\n- `Decision Boundaries` must be explicit\n- A pressure pass must be complete: at least one earlier answer has been revisited with an evidence, assumption, or tradeoff follow-up\n- A practical closure audit must pass: another question would change execution materially, not merely polish wording or chase a narrow edge case\n- If either gate is unresolved, or the pressure pass is incomplete, continue below threshold only with a final closure question that names the unresolved gate and would materially change execution.\n- Treat a low ambiguity score as permission to audit closure, not permission to keep drilling indefinitely. If remaining uncertainty would not change implementation, crystallize the spec instead of opening a new branch.\n- If ambiguity is `<= 0.10`, another user-facing question is allowed only as that final closure question; otherwise crystallize immediately.\n\n### 2d) Report progress\nShow weighted breakdown table, readiness-gate status (`Non-goals`, `Decision Boundaries`), and the next focus dimension.\n\n### 2e) Persist state\nAppend round result and updated scores via `omx state write --input '<json>' --json`. Do not write `{mode}-state.json` directly and do not use the read-only MCP state projection as a writer.\n\n### 2f) Round controls\n- Do not offer early exit before the first explicit assumption probe and one persistent follow-up have happened\n- Apply a **Dialectic Rhythm Guard**: track consecutive non-user fact discoveries and confirmation-style answers (`[from-code][auto-confirmed]`, `[from-code]`, or `[from-research]`). After 3 consecutive non-user or confirmation answers, the next material user-facing round must solicit direct human judgment (`[from-user]`) unless the closure audit says the interview is ready to crystallize.\n- Round 4+: allow explicit early exit with risk warning\n- Soft warning at profile midpoint (e.g., round 3/6/10 depending on profile)\n- Hard cap at profile `max_rounds`; never treat this cap as a desired interview length or quota\n\n## Phase 3: Challenge Modes (assumption stress tests)\n\nUse each mode once when applicable. These are normal escalation tools, not rare rescue moves:\n\n- **Contrarian** (round 2+ or immediately when an answer rests on an untested assumption): challenge core assumptions\n- **Terminologist** (brownfield, whenever a key term is fuzzy, overloaded, or conflicts with repo docs/code): force a canonical meaning against existing project language before implementation\n- **Simplifier** (round 4+ or when scope expands faster than outcome clarity): probe minimal viable scope\n- **Ontologist** (round 5+ and ambiguity > 0.25, or when the user keeps describing symptoms): ask for essence-level reframing\n\nTrack used modes in state to prevent repetition.\n\n## Phase 4: Crystallize Artifacts\n\nWhen threshold is met (or user exits with warning / hard cap):\n\n1. Write interview transcript summary to:\n - `.omx/interviews/{slug}-{timestamp}.md`\n (kept for ralph PRD compatibility)\n2. Write execution-ready spec to:\n - `.omx/specs/deep-interview-{slug}.md`\n\nSpec should include:\n- Metadata (profile, rounds, final ambiguity, threshold, context type)\n- Context snapshot reference/path (for ralplan/team reuse)\n- Prompt-safe initial-context summary when oversized context was provided, plus references to any full source documents\n- Clarity breakdown table\n- Intent (why the user wants this)\n- Desired Outcome\n- In-Scope\n- Out-of-Scope / Non-goals\n- Decision Boundaries (what OMX may decide without confirmation)\n- Constraints\n- Testable acceptance criteria\n- Assumptions exposed + resolutions\n- Pressure-pass findings (which answer was revisited, and what changed)\n- Brownfield evidence vs inference notes for any repository-grounded confirmation questions\n- Docs/Terminology Ledger with inspected repo docs/rules/context, term conflicts, and any doc/code mismatch decisions\n- Scenario/edge-case pressure findings that materially shaped scope or acceptance criteria\n- Optional durable documentation recommendations, explicitly marked opt-in and public-safe; do not include raw private transcript dumps\n- Technical context findings\n- Full or condensed transcript\n\n### Autoresearch specialization\n\nWhen the clarified task is specifically about `$autoresearch`, or the skill is invoked with `--autoresearch`, keep the interview domain-specific and emit skill-consumable artifacts without skipping clarification.\n\n- **Accepted seed inputs:** `topic`, `evaluator`, `keep-policy`, `slug`, existing mission draft text, and prior evaluator examples/templates\n- **Required interview focus:** mission clarity, evaluator readiness, keep policy, slug/session naming, and whether the draft is ready to launch now or should refine further\n- **Canonical artifact path:** `.omx/specs/deep-interview-autoresearch-{slug}.md`\n- **Launch artifact bundle:** `.omx/specs/autoresearch-{slug}/mission.md`, `.omx/specs/autoresearch-{slug}/sandbox.md`, and `.omx/specs/autoresearch-{slug}/result.json`\n- **Launch artifact directory:** `.omx/specs/autoresearch-{slug}/`\n- **Required artifact sections:**\n - `Mission Draft`\n - `Evaluator Draft`\n - `Launch Readiness`\n - `Seed Inputs`\n - `Confirmation Bridge`\n- **Required launch artifacts under `.omx/specs/autoresearch-{slug}/`:**\n - `mission.md`\n - `sandbox.md`\n - `result.json`\n- **Launch-readiness rule:** mark the draft as **not launch-ready** while the evaluator command still contains placeholder markers such as `<...>`, `TODO`, `TBD`, `REPLACE_ME`, `CHANGEME`, or `your-command-here`\n- **Structured result contract:** `result.json` should point to the draft + mission/sandbox artifacts and carry the finalized `topic`, `evaluatorCommand`, `keepPolicy`, `slug`, `launchReady`, and `blockedReasons` fields so `$autoresearch` can consume it directly\n- **Confirmation bridge:** after artifact generation, offer at least `refine further` and `launch`; do not run direct CLI launch or detached/split tmux launch, and only hand off to `$autoresearch` after explicit confirmation\n- **Handoff rule:** downstream execution must preserve the clarified mission intent, evaluator expectations, decision boundaries, and launch-readiness status from this artifact rather than bypassing the draft review step\n\n## Phase 5: Execution Bridge\n\nPresent execution options after artifact generation using explicit handoff contracts. Treat the deep-interview spec as the current requirements source of truth and preserve intent, non-goals, decision boundaries, acceptance criteria, docs/terminology grounding, and any residual-risk warnings across the handoff.\n\n### Optional execution contract foundation\n\nWhen an Autopilot/deep-interview handoff explicitly requires a stride contract, emit it as structured data rather than prose. This is a validation foundation, not a broadness-inference feature: do not infer stride from task length, phase labels, snapshots, or freeform wording.\n\nCanonical location under Autopilot state:\n\n```json\n{\n \"handoff_artifacts\": {\n \"deep_interview\": {\n \"execution_contract_required\": true,\n \"execution_contract\": {\n \"version\": 1,\n \"execution_stride\": \"task\",\n \"source\": \"deep-interview\",\n \"selected_by\": \"user\",\n \"allow_task_shrink\": true,\n \"completion_unit\": \"One focused task\",\n \"stop_condition\": \"Stop after that task is implemented and verified\",\n \"acceptance_coverage_scope\": \"task\",\n \"shrink_policy\": \"allowed\"\n }\n }\n }\n}\n```\n\nStride meanings:\n- `task`: conservative, small-step execution; `allow_task_shrink:true`, `acceptance_coverage_scope:\"task\"`, `shrink_policy:\"allowed\"`.\n- `deliverable`: finish the named deliverable before stopping; `allow_task_shrink:false`, `acceptance_coverage_scope:\"deliverable\"`, `shrink_policy:\"ask_before_shrink\"`.\n- `milestone`: finish the larger approved milestone unless blocked; `allow_task_shrink:false`, `acceptance_coverage_scope:\"milestone\"`, `shrink_policy:\"deny_unless_blocked\"`.\n\nOnly set `execution_contract_required:true` when the selected downstream workflow needs this explicit stride/stop-condition guard. New artifacts must write the canonical snake_case schema shown above under `handoff_artifacts.deep_interview`; runtime readers may accept legacy camelCase field/marker aliases and direct/nested `execution_contract` locations only as compatibility input. If `execution_contract_required` is absent or false, downstream Autopilot compatibility behavior is unchanged.\n\n### Goal-mode follow-ups\n\nInclude these product-facing suggestions when they fit the clarified spec, without removing the existing `$ultragoal`, `$ralplan`, `$autopilot`, and `$team` handoff options:\n\n- **`$ultragoal`** — default goal-mode follow-up for implementation or general goal-oriented follow-up specs that should be converted into durable Codex/OMX goals with sequential completion tracking.\n- **`$autoresearch`** — use when the clarified context is a research project: a research question, reference/literature gathering, evaluator-backed analysis, or professor/critic-style deliverable.\n- **`$performance-goal`** — use when the clarified context is an optimization or performance project with measurable speed, latency, throughput, memory, benchmark, or evaluator criteria.\n\nRecommend `$ultragoal` as the default durable goal-mode follow-up because it supersedes Ralph for goal tracking. Preserve `$team` for coordinated parallel implementation.\n\n### 1. **`$ultragoal` (Default durable execution follow-up)**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md` (optionally accompanied by the transcript/context snapshot for traceability)\n- **Invocation:** `$ultragoal create-goals --brief-file <spec-path>` followed by `$ultragoal complete-goals` in the active execution lane\n- **Consumer Behavior:** Convert the clarified spec into durable goal-mode work. Preserve intent, non-goals, decision boundaries, acceptance criteria, docs/terminology grounding, scenario-pressure findings, and residual-risk warnings as binding story constraints.\n- **Skipped / Already-Satisfied Stages:** Requirement interview, ambiguity clarification, doc/context preflight, and early intent-boundary elicitation\n- **Expected Output:** `.omx/ultragoal/brief.md`, `.omx/ultragoal/goals.json`, `.omx/ultragoal/ledger.jsonl`, implementation evidence, verification evidence, and final cleanup/review-gate evidence\n- **Best When:** The clarified spec is execution-ready or the user explicitly wants durable goal tracking as the next step\n- **Next Recommended Step:** Run the Ultragoal completion loop; launch `$team` only inside an active Ultragoal story when parallel lanes are warranted\n\n### 2. **`$ralplan` (Recommended when architecture/test-shape review is still needed)**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md` (optionally accompanied by the transcript/context snapshot for traceability)\n- **Invocation:** `$ralplan <spec-path>`\n- **Consumer Behavior:** Treat the deep-interview spec as the requirements source of truth. Do not repeat the interview by default; refine architecture/feasibility around the clarified intent and boundaries instead.\n- **Skipped / Already-Satisfied Stages:** Requirements discovery, ambiguity clarification, and early intent-boundary elicitation\n- **Expected Output:** Canonical planning artifacts under `.omx/plans/`, especially `prd-*.md` and `test-spec-*.md`\n- **Best When:** Requirements are clear enough to stop interviewing, but architectural validation / consensus planning is still desirable\n- **Next Recommended Step:** Use the approved planning artifacts with `$ultragoal` as the default durable goal-mode follow-up (optionally with `$team` for parallel lanes); choose `$autoresearch` for research validation or `$performance-goal` for measurable optimization\n\n### 3. **`$autopilot`**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md`\n- **Invocation:** `$autopilot <spec-path>`\n- **Consumer Behavior:** Use the deep-interview spec as the clarified execution brief. Preserve intent, non-goals, decision boundaries, and acceptance criteria as binding context for planning/execution.\n- **Skipped / Already-Satisfied Stages:** Initial requirement discovery and ambiguity reduction\n- **Expected Output:** Planning/execution progress, QA evidence, and validation artifacts produced by autopilot\n- **Best When:** The clarified spec is already strong enough for direct planning + execution without an additional consensus gate\n- **Next Recommended Step:** Continue through autopilot's execution/QA/validation flow; if coordination-heavy execution emerges, prefer `$team` under a leader-owned `$ultragoal` ledger\n\n### 4. **`$team`**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md`\n- **Invocation:** `$team <spec-path>`\n- **Consumer Behavior:** Treat the spec as shared execution context for coordinated parallel work. Preserve the clarified intent, non-goals, decision boundaries, and acceptance criteria as common lane constraints.\n- **Skipped / Already-Satisfied Stages:** Requirement clarification and early ambiguity reduction\n- **Expected Output:** Coordinated multi-agent execution against the shared spec, with final verification evidence and checkpoints in an already-active Ultragoal ledger when applicable\n- **Best When:** The task is large, multi-lane, or blocker-sensitive enough to justify coordinated parallel execution instead of a single persistent loop\n- **Next Recommended Step:** Follow the team verification path when the coordinated execution phase finishes; checkpoint an already-active `$ultragoal` ledger when applicable. Do not start another execution loop solely to verify.\n\n### 5. **Refine further**\n- **Input Artifact:** Existing transcript, context snapshot, and current spec draft\n- **Invocation:** Continue the interview loop\n- **Consumer Behavior:** Re-enter questioning to resolve the highest-leverage remaining uncertainty\n- **Skipped / Already-Satisfied Stages:** None beyond already-captured context\n- **Expected Output:** A lower-ambiguity spec with tighter boundaries and fewer unresolved assumptions\n- **Best When:** Residual ambiguity is still too high, the user wants stronger clarity, or the above-threshold / early-exit warning indicates too much risk to proceed cleanly\n- **Next Recommended Step:** Return to one of the execution handoff contracts above once the spec is sufficiently clarified\n\n**Residual-Risk Rule:** If the interview ended via early exit, hard-cap completion, or above-threshold proceed-with-warning, explicitly preserve that residual-risk state in the handoff so the downstream skill knows it inherited a partially clarified brief.\n\n**IMPORTANT:** Deep-interview is a requirements mode. On handoff, invoke the selected skill using the contract above. **Do NOT implement directly** inside deep-interview.\n\n</Steps>\n\n<Tool_Usage>\n- Use `explore` for codebase fact gathering\n- Use `omx question` as the OMX-native structured user-input tool for each interview round when an attached tmux renderer is available\n- From attached-tmux Bash/tool paths, call it as `OMX_QUESTION_RETURN_PANE=$TMUX_PANE omx question ...` unless an explicit `%pane` return target is already known\n- If the current runtime is outside tmux and cannot render `omx question`, use native structured input when available; otherwise ask exactly one concise plain-text question and wait for the answer\n- After `omx question` returns JSON, prefer `answers[0].answer` / `answers[]`; use legacy `answer` only as a fallback for older records\n- Use `omx state write/read --input '<json>' --json` for resumable mode state through the sole-writer state operations path; the MCP state server is read-only and is not a fallback writer\n- If the interview cannot ask a required `omx question` round, persist the blocker as terminal state with `active: false` and `current_phase: \"blocked\"`; do not write a terminal blocked phase with `active: true`\n- Read/write context snapshots under `.omx/context/`\n- Read applicable repo docs/rules/context during preflight; write durable docs, glossary, ADR, or memory updates only when the user explicitly opts in and the content is public-safe\n- Record whether the oversized-context summary gate is not needed, pending, or satisfied before any scoring or handoff step\n- Save transcript/spec artifacts under `.omx/interviews/` and `.omx/specs/`\n</Tool_Usage>\n\n<Escalation_And_Stop_Conditions>\n- User says stop/cancel/abort -> persist state and stop\n- Ambiguity stalls for 3 rounds (+/- 0.05) -> force Ontologist mode once\n- Max rounds reached -> proceed with explicit residual-risk warning\n- All dimensions >= 0.9 -> allow early crystallization even before max rounds\n</Escalation_And_Stop_Conditions>\n\n<Final_Checklist>\n- [ ] Preflight context snapshot exists under `.omx/context/{slug}-{timestamp}.md`\n- [ ] Oversized initial context, if present, has a prompt-safe summary recorded before ambiguity scoring or downstream handoff\n- [ ] Ambiguity score shown each round\n- [ ] Intent-first stage priority used before implementation detail\n- [ ] Weakest-dimension targeting used within the active stage\n- [ ] At least one explicit assumption probe happened before crystallization\n- [ ] At least one persistent follow-up / pressure pass deepened a prior answer\n- [ ] Challenge modes triggered at thresholds (when applicable)\n- [ ] Transcript written to `.omx/interviews/{slug}-{timestamp}.md`\n- [ ] Spec written to `.omx/specs/deep-interview-{slug}.md`\n- [ ] Brownfield questions use evidence-backed confirmation when applicable\n- [ ] Brownfield preflight inspected applicable repo docs/rules/context before user-facing questions\n- [ ] Fuzzy or conflicting terminology was challenged against repo language/current code behavior when applicable\n- [ ] Scenario-based edge-case grilling was used when boundary ambiguity would materially affect implementation\n- [ ] Durable docs/ADR/memory updates, if any, were explicitly opted into and public-safe\n- [ ] Handoff options provided (`$ultragoal`, `$ralplan`, `$autopilot`, `$team`) plus context-sensitive goal-mode suggestions (`$autoresearch`, `$performance-goal`) when applicable\n- [ ] No direct implementation performed in this mode\n</Final_Checklist>\n\n<Advanced>\n## Suggested Config (optional)\n\nDeep-interview reads runtime defaults from the first existing config source in this order:\n\n1. Repository-local `.omx/config.toml`\n2. Repository-root `omx.toml`\n3. User-global `~/.omx/config.toml`\n\nThis section is currently a deep-interview-specific runtime override surface, not a general replacement for Codex `config.toml` or `.omx-config.json` model/env routing.\nMalformed config files are ignored fail-soft so `$deep-interview` activation can continue with built-in defaults.\nExplicit `--quick`, `--standard`, or `--deep` invocation flags override `defaultProfile`.\n\n```toml\n[omx.deepInterview]\ndefaultProfile = \"standard\"\nquickThreshold = 0.30\nstandardThreshold = 0.20\ndeepThreshold = 0.15\nquickMaxRounds = 5\nstandardMaxRounds = 12\ndeepMaxRounds = 20\nenableChallengeModes = true\n```\n\n## Resume\n\nIf interrupted, rerun `$deep-interview`. Resume from persisted mode state via `omx state read --input '{\"mode\":\"deep-interview\"}' --json`.\n\n## Canonical Autopilot Entry Pipeline\n\n```\nautopilot -> deep-interview -> ralplan -> ultragoal\n```\n\n- Autopilot begins with this independent deep-interview clarity gate; it must not substitute `$plan --interview`.\n- Stage 1 (deep-interview): ambiguity clearance and execution-ready requirements artifact\n- Stage 2 (ralplan): feasibility, architecture, and consensus gate\n- Stage 3 (ultragoal): durable execution, verification, and completion receipts\n</Advanced>\n","frontmatter":{"name":"deep-interview","description":"Socratic deep interview with mathematical ambiguity gating before execution","argument-hint":"[--quick|--standard|--deep] [--autoresearch] <idea or vague description>"},"isInternal":false,"tokens":9030,"sizeBytes":41261},{"name":"SKILL.md","path":"skills/design/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/design/SKILL.md","title":"design","category":"anthropic-skill","format":"markdown","content":"---\nname: design\ndescription: Canonical repo-local DESIGN.md workflow for product, UI/UX, and frontend decision source of truth\n---\n\n# Design Skill\n\nUse `$design` to discover product and UI evidence, close only design-critical context gaps, and create or refresh the repository’s durable `DESIGN.md` contract. It is a maintained design brief, not a pixel-matching loop or one-off critique.\n\nShared operating, delegation, state, hook, team, cancellation, and verification invariants live in [`templates/AGENTS.md`](../../templates/AGENTS.md). Follow that source instead of duplicating its rules here.\n\n## Use when\n\n- Product, UX, frontend, or design-system decisions need a repo-local source of truth.\n- A feature needs a design brief before a designer lane or implementation.\n- Existing UI, assets, screenshots, or constraints need an actionable design summary.\n\nDo not use it for visual-reference implementation matching (use `$visual-ralph`), screenshot comparison alone, or backend/infrastructure work without user-facing design impact.\n\n## Relationship to `$visual-ralph`\n\n`$design` owns product goals, users, information architecture, visual language, components, accessibility, constraints, and open questions in `DESIGN.md`. `$visual-ralph` owns implementation against an approved visual reference or live-URL baseline, measured verdicts, and pixel-diff evidence. Run `$design` first when both are needed; `DESIGN.md` supports but does not replace the visual verdict target.\n\n## Workflow\n\n### 1. Discover local evidence\n\nInspect and cite existing `DESIGN.md`, design/UX/frontend docs, README/specs/issues, routes/pages/layouts/components/stories, theme and token files, assets, screenshots/mockups, Storybook or Playwright baselines, and accessibility/responsive/i18n/platform constraints. Separate observations from inferences; note absent evidence.\n\n### 2. Interview only missing context\n\nAsk concise questions only for gaps the repository cannot resolve: users/jobs, goals/non-goals, brand personality and forbidden aesthetics, primary flows, accessibility/device/browser targets, or unavailable assets/references. If answers are unavailable, record explicit assumptions and open questions rather than blocking.\n\n### 3. Create or refresh `DESIGN.md`\n\nPreserve useful content, remove contradictions, mark unknowns, and keep decisions actionable. The root file must contain these sections:\n\n# Design\n## Source of truth\nStatus (Draft | Active | Needs refresh), date, product surfaces, evidence reviewed.\n## Brand\nPersonality, trust signals, avoid.\n## Product goals\nGoals, non-goals, success signals.\n## Personas and jobs\nPrimary personas, user jobs, contexts of use.\n## Information architecture\nNavigation, routes/screens, content hierarchy.\n## Design principles\nPrinciples and tradeoffs.\n## Visual language\nColor, typography, spacing, shape/elevation, motion, imagery/iconography.\n## Components\nExisting/new components, variants/states, token ownership.\n## Accessibility\nTarget standard, keyboard/focus, contrast, semantics, reduced motion/sensory concerns.\n## Responsive behavior\nBreakpoints/devices, layout adaptations, touch/hover differences.\n## Interaction states\nLoading, empty, error, success, disabled, offline/slow network where applicable.\n## Content voice\nTone, terminology, microcopy rules.\n## Implementation constraints\nFramework/styling, tokens, performance, compatibility, test/screenshot expectations.\n## Open questions\n`[ ]` question, owner, and impact.\n\n### 4. Apply the contract\n\nBefore UI decisions, cite relevant `DESIGN.md` sections, reuse documented components/tokens, and update the file or add an open question when implementation exposes a contradiction. Do not invent a parallel design-system layer.\n\n### 5. Handoff\n\nFor normal frontend work, provide the relevant sections, repo evidence, and acceptance criteria. For visual-reference, image, or live-URL matching, hand off to `$visual-ralph` with the approved baseline and identify `DESIGN.md` as supporting context only.\n\n## Evidence and completion\n\nComplete only when design docs/assets/components/screenshots were inspected or noted absent; missing context is answered, assumed, or listed; root `DESIGN.md` contains every required section; recommendations cite it; and any Visual Ralph handoff is clearly separated from design governance.\n\nTask: {{ARGUMENTS}}\n","frontmatter":{"name":"design","description":"Canonical repo-local DESIGN.md workflow for product, UI/UX, and frontend decision source of truth"},"isInternal":false,"tokens":891,"sizeBytes":4351},{"name":"SKILL.md","path":"skills/doctor/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/doctor/SKILL.md","title":"doctor","category":"anthropic-skill","format":"markdown","content":"---\nname: doctor\ndescription: Diagnose and fix oh-my-codex installation issues\n---\n\n# OMX Doctor\n\nUse this task card to diagnose installation/discovery problems. Shared safety, lifecycle, hook, team, autonomy, and cancellation rules live in `templates/AGENTS.md`. `~/.codex` means `${CODEX_HOME:-~/.codex}` when `CODEX_HOME` is set.\n\n## Run diagnostics\n\n```bash\nomx doctor\nomx doctor --team # include Team runtime checks\nomx doctor --verbose # include detailed check evidence\nomx doctor --force # repair eligible repo artifact ownership issues\nomx doctor --dry-run --force # preview eligible ownership repairs\n```\n\nFor a local source checkout, build first and invoke `node dist/cli/omx.js doctor`. Keep command output and exact paths for the report.\n\n### Plugin cache and version\n\n```bash\nPLUGIN_CACHE_ROOT=\"${CODEX_HOME:-$HOME/.codex}/plugins/cache\"\nCACHE_ENTRIES=$(find \"$PLUGIN_CACHE_ROOT\" -path \"*/oh-my-codex/*\" -mindepth 3 -maxdepth 3 -type d 2>/dev/null)\nif [[ -z \"$CACHE_ENTRIES\" ]]; then\n echo \"Installed plugin cache: none\"\nelse\n while IFS= read -r d; do\n m=$(basename \"$(dirname \"$(dirname \"$d\")\")\"); v=$(basename \"$d\")\n printf 'Installed plugin cache: marketplace=%s version=%s path=%s\\n' \"$m\" \"$v\" \"$d\"\n done <<<\"$CACHE_ENTRIES\"\nfi\nLATEST=$(npm view oh-my-codex version 2>/dev/null)\necho \"Latest npm: $LATEST\"\n```\n\nNo cache is INFO (normal for npm/setup-only installs). A non-`local` cache version differing from `LATEST`, or multiple versions for one marketplace, is WARN. Plugin discovery does not replace npm installation plus `omx setup`; native/runtime wiring remains setup-owned.\n\n### Hooks, AGENTS, and skill roots\n\n```bash\nCODEX_DIR=\"${CODEX_HOME:-$HOME/.codex}\"\nls -la \"$CODEX_DIR/config.toml\" \"$CODEX_DIR/settings.json\" 2>/dev/null\nrg 'keyword-detector|persistent-mode|session-start|stop-continuation' \"$CODEX_DIR/config.toml\" \"$CODEX_DIR/settings.json\" 2>/dev/null || true\nls -la \"$CODEX_DIR/hooks\"/*.sh 2>/dev/null\nls -la \"$CODEX_DIR/AGENTS.md\" 2>/dev/null\ngrep -q \"oh-my-codex Multi-Agent System\" \"$CODEX_DIR/AGENTS.md\" 2>/dev/null && echo \"Has OMX config\" || echo \"Missing OMX config\"\nls -la \"$CODEX_DIR/agents\" \"$CODEX_DIR/commands\" \"$CODEX_DIR/skills\" \"$HOME/.agents/skills\" 2>/dev/null\n```\n\nClassify legacy hook references as **CRITICAL** (duplicate hooks). The scripts `keyword-detector.sh`, `persistent-mode.sh`, `session-start.sh`, and `stop-continuation.sh` are **WARN**. Missing AGENTS.md is **CRITICAL**; missing the OMX marker is **WARN**. `${CODEX_HOME:-~/.codex}/skills` is the canonical user root. `~/.agents/skills` is historical and overlapping trees can duplicate skill entries. OMX files under legacy `agents/` or `commands/` are **WARN**.\n\nWith `--team`, retain any `resume_blocker`, `slow_shutdown`, `delayed_status_lag`, `stale_leader`, or `orphan_tmux_session` diagnostics; failed checks set a non-zero exit status.\n\n## Report contract\n\n```text\n## OMX Doctor Report\n### Summary\n[HEALTHY / ISSUES FOUND]\n### Checks\n| Check | Status | Details |\n| Plugin Version | OK/WARN/INFO | ... |\n| Hook Config (config.toml / legacy settings.json) | OK/CRITICAL | ... |\n| Legacy Scripts (~/.codex/hooks/) | OK/WARN | ... |\n| AGENTS.md | OK/WARN/CRITICAL | ... |\n| Plugin Cache | OK/WARN | ... |\n| Legacy Agents / Commands | OK/WARN | ... |\n| Skills (canonical / historical root) | OK/WARN | ... |\n### Issues Found\n1. ...\n### Recommended Fixes\n...\n```\n\n## Remediation (after user confirmation and confirming each target is OMX-owned)\n\nRemove only confirmed OMX legacy content; preserve unrelated user files:\n\n```bash\n# If settings.json exists, remove only its legacy \"hooks\" section.\nrm -f \"$CODEX_DIR/hooks/keyword-detector.sh\" \"$CODEX_DIR/hooks/persistent-mode.sh\" \"$CODEX_DIR/hooks/session-start.sh\" \"$CODEX_DIR/hooks/stop-continuation.sh\"\nPLUGIN_CACHE_ROOT=\"${CODEX_HOME:-$HOME/.codex}/plugins/cache\"\nfind \"$PLUGIN_CACHE_ROOT\" -path \"*/oh-my-codex\" -type d -prune -exec rm -rf {} +\n```\n\nFor older curl installs, inspect first and remove only directories containing OMX-managed files:\n\n```bash\nls -la \"$CODEX_DIR/agents\" \"$CODEX_DIR/commands\" \"$CODEX_DIR/skills\" \"$HOME/.agents/skills\" 2>/dev/null\n# Optional backups:\n# mv \"$CODEX_DIR/agents\" \"$CODEX_DIR/agents.bak\"\n# mv \"$CODEX_DIR/commands\" \"$CODEX_DIR/commands.bak\"\n# mv \"$HOME/.agents/skills\" \"$HOME/.agents/skills.bak\"\nrm -rf \"$CODEX_DIR/agents\" \"$CODEX_DIR/commands\" \"$HOME/.agents/skills\"\n```\n\nIf AGENTS.md is missing/outdated, fetch the current raw file and write it to `$CODEX_DIR/AGENTS.md`:\n\n```text\nWebFetch(url: \"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/main/docs/AGENTS.md\", prompt: \"Return the complete raw markdown content exactly as-is\")\n```\n\nTo keep only the newest cache version for a selected marketplace:\n\n```bash\nPLUGIN_CACHE_DIR=\"$PLUGIN_CACHE_ROOT/$MARKETPLACE_NAME/oh-my-codex\"\nKEEP_VERSION=$(for d in \"$PLUGIN_CACHE_DIR\"/*; do [[ -d \"$d\" ]] && basename \"$d\"; done | sort -V | tail -1)\n[[ -n \"$KEEP_VERSION\" ]] && find \"$PLUGIN_CACHE_DIR\" -mindepth 1 -maxdepth 1 -type d ! -name \"$KEEP_VERSION\" -exec rm -rf {} +\n```\n\nIf AGENTS.md is missing or stale, refresh it from the current release source, then rerun `omx doctor`. If legacy `~/.agents/skills` overlaps the canonical root, archive/remove that tree only after checking for custom skills. Restart Codex after fixes and report before/after evidence.\n\n## Exit conditions\n\nStop with **HEALTHY** only when required paths, hook/config checks, AGENTS marker, plugin cache status, and (when requested) Team checks pass. Otherwise report **ISSUES FOUND**, exact failed evidence, and the smallest confirmed remediation; do not claim a fix from a recommendation alone.\n","frontmatter":{"name":"doctor","description":"Diagnose and fix oh-my-codex installation issues"},"isInternal":false,"tokens":1530,"sizeBytes":5684},{"name":"SKILL.md","path":"skills/git-master/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/git-master/SKILL.md","title":"git-master","category":"anthropic-skill","format":"markdown","content":"---\nname: git-master\ndescription: Git expert for atomic commits, rebasing, and history management\n---\n\n# Git Master Command\n\nRoutes to the git-master agent for git operations.\n\n## Usage\n\n```\n/git-master <git task>\n```\n\n## Routing\n\n```text\nUse /prompts:git-master with the user task.\n```\n\n## Capabilities\n- Atomic commits with conventional format\n- Interactive rebasing\n- Branch management\n- History cleanup\n- Style detection from repo history\n","frontmatter":{"name":"git-master","description":"Git expert for atomic commits, rebasing, and history management"},"isInternal":false,"tokens":101,"sizeBytes":443},{"name":"SKILL.md","path":"skills/hud/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/hud/SKILL.md","title":"hud","category":"anthropic-skill","format":"markdown","content":"---\nname: \"hud\"\ndescription: \"Show or configure the OMX HUD (two-layer statusline)\"\nrole: \"display\"\nscope: \".omx/**\"\n---\n\n# HUD Skill\n\nThe OMX HUD uses a two-layer architecture:\n\n1. **Layer 1 - Codex built-in statusLine**: Real-time TUI footer showing model, git branch, and context usage. Configured via `[tui] status_line` in `~/.codex/config.toml`. Zero code required.\n\n2. **Layer 2 - `omx hud` CLI command**: Shows OMX-specific orchestration state (ralph, ultrawork, autopilot, team, pipeline, ecomode, turns). Reads `.omx/state/` files.\n\n## Quick Commands\n\n| Command | Description |\n|---------|-------------|\n| `omx hud` | Show current HUD (modes, turns, activity) |\n| `omx hud --watch` | Live-updating display (polls every 1s) |\n| `omx hud --json` | Raw state output for scripting |\n| `omx hud --preset=minimal` | Minimal display |\n| `omx hud --preset=focused` | Default display |\n| `omx hud --preset=full` | All elements |\n\n## Presets\n\n### minimal\n```\n[OMX] ralph:3/10 | turns:42\n```\n\n### focused (default)\n```\n[OMX] ralph:3/10 | ultrawork | team:3 workers | turns:42 | last:5s ago\n```\n\n### full\n```\n[OMX] ralph:3/10 | ultrawork | autopilot:execution | team:3 workers | pipeline:exec | turns:42 | last:5s ago | total-turns:156\n```\n\n## Setup\n\n`omx setup` automatically configures both layers:\n- Adds `[tui] status_line` to `~/.codex/config.toml` (Layer 1)\n- Writes `.omx/hud-config.json` with default preset (Layer 2)\n- Default preset is `focused`; if HUD/statusline changes do not appear, restart Codex CLI once.\n\n## Layer 1: Codex Built-in StatusLine\n\nConfigured in `~/.codex/config.toml`:\n```toml\n[tui]\nstatus_line = [\"model-with-reasoning\", \"git-branch\", \"context-remaining\"]\n```\n\nAvailable built-in items (Codex CLI v0.101.0+):\n`model-name`, `model-with-reasoning`, `current-dir`, `project-root`, `git-branch`, `context-remaining`, `context-used`, `five-hour-limit`, `weekly-limit`, `codex-version`, `context-window-size`, `used-tokens`, `total-input-tokens`, `total-output-tokens`, `session-id`\n\n## Layer 2: OMX Orchestration HUD\n\nThe `omx hud` command reads these state files:\n- `.omx/state/ralph-state.json` - Ralph loop iteration\n- `.omx/state/ultrawork-state.json` - Ultrawork mode\n- `.omx/state/autopilot-state.json` - Autopilot phase\n- `.omx/state/team-state.json` - Team workers\n- `.omx/state/pipeline-state.json` - Pipeline stage\n- `.omx/state/ecomode-state.json` - Ecomode active\n- `.omx/state/hud-state.json` - Last activity (from notify hook)\n- `.omx/metrics.json` - Turn counts\n\n## Configuration\n\nHUD config stored at `.omx/hud-config.json`:\n```json\n{\n \"preset\": \"focused\"\n}\n```\n\n## Color Coding\n\n- **Green**: Normal/healthy\n- **Yellow**: Warning (ralph >70% of max)\n- **Red**: Critical (ralph >90% of max)\n\n## Troubleshooting\n\nIf the TUI statusline is not showing:\n1. Ensure Codex CLI v0.101.0+ is installed\n2. Run `omx setup` to configure `[tui]` section\n3. Restart Codex CLI\n\nIf `omx hud` shows \"No active modes\":\n- This is expected when no workflows are running\n- Start an explicitly requested supported workflow (`$autopilot` or `$ultragoal`) and check again\n","frontmatter":{"name":"hud","description":"Show or configure the OMX HUD (two-layer statusline)","role":"display","scope":".omx/**"},"isInternal":false,"tokens":919,"sizeBytes":3089},{"name":"SKILL.md","path":"skills/omx-setup/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/omx-setup/SKILL.md","title":"omx-setup","category":"anthropic-skill","format":"markdown","content":"---\nname: omx-setup\ndescription: Setup and configure oh-my-codex using current CLI behavior\n---\n\n# OMX Setup\n\nUse this task card to install or refresh OMX for the current project and/or user scope. Shared safety, lifecycle, hook, team, autonomy, and cancellation rules live in `templates/AGENTS.md`. Do not infer new CLI behavior from this card; the implementation is authoritative.\n\n## Command and alternatives\n\n```bash\nomx setup [--force] [--merge-agents|--no-merge-agents|--clear-merge-agents-policy] [--dry-run] [--verbose] [--scope <user|project>] [--plugin|--legacy|--install-mode <legacy|plugin>] [--mcp <none|compat>] [--no-mcp|--with-mcp] [--disable-team|--enable-team|--team-mode <enabled|disabled>]\nomx agents-init [path] [--dry-run] [--force] [--verbose]\n```\n\nUse `agents-init` for lightweight AGENTS.md scaffolding only, not a full install.\n\nSupported setup options:\n- `--force`: overwrite/reinstall managed artifacts; transient, not persisted or replayed.\n- `--merge-agents`, `--no-merge-agents`, `--clear-merge-agents-policy`: exact bare selectors (no values/equals). Repeated identical selectors are idempotent; conflicting selectors fail before mutations. Set persists an explicit policy per invoking project root; clear removes it and cannot combine with a set. Merge refreshes managed sections; no-merge only suppresses that branch and is not a preserve mode.\n- `--dry-run`, `--verbose`: preview actions or show per-file/per-step detail.\n- `--scope user|project`: choose user (`~/.codex`, `~/.omx/agents`) or project (`./.codex`, `./.omx/agents`) targets.\n- `--plugin` / `--legacy`: select delivery mode; `--install-mode legacy|plugin` is the canonical scripted spelling. Conflicting mode flags fail.\n- `--mcp none|compat` (plus `--no-mcp` / `--with-mcp`): omit or enable first-party MCP compatibility and shared registry sync.\n- `--disable-team`, `--enable-team`, `--team-mode enabled|disabled`: select Team skill/context generation; conflicting selectors fail.\n\n## Resolve setup\n\n1. Scope: explicit flag, valid persisted `./.omx/setup-scope.json`, TTY choice (default `user`), or non-interactive `user`. Legacy `project-local` migrates to `project`.\n2. Mode: explicit flag, persisted mode when retained, discovered `${CODEX_HOME:-~/.codex}/plugins/cache/**/.codex-plugin/plugin.json` with `name: oh-my-codex` (plugin default), otherwise legacy. TTY reruns summarize saved choices and offer keep/review/reset; non-interactive runs do not block.\n3. Create required directories and atomically persist preferences only after successful setup.\n\n## What setup changes\n\n- Legacy mode installs prompts/native agents/skills and merges full config.toml.\n- Plugin mode archives/removes legacy OMX-managed prompts/skills, refreshes installable native agent TOMLs and stale generated non-installable agents, and keeps setup-owned runtime hooks.\n- Both modes verify Team CLI interop markers in built `dist/cli/team.js`, generate AGENTS defaults only when selected/allowed, and write `./.omx/hud-config.json`; notification hook references are setup-owned outside plugin skill delivery.\n- `AGENTS.md` is `./AGENTS.md`. Without `--force` or `--merge-agents`, interactive runs ask before overwrite and non-interactive runs preserve it. Active-session safeguards may skip writes. Plugin mode may separately prompt for AGENTS and `developer_instructions` defaults; non-interactive runs preserve existing files.\n- Plugin mode enables setup-owned runtime flags (`plugin_hooks`, `goals`, or legacy `hooks`/`codex_hooks` fallback). Project scope uses `CODEX_HOME=./.codex` unless explicitly overridden.\n\n## Verify\n\n```bash\nomx setup --force --verbose\nomx doctor\n```\n\nExpect doctor evidence for prompts and skills in the selected scope, project-root AGENTS.md, `.omx/state`, and CLI-first config in the scope target `config.toml`. First-party MCP and shared registry sync are omitted unless setup used `--mcp compat` (if supported by the installed CLI).\n\nIf using local source, run `npm run build` before `node dist/cli/omx.js setup --force --verbose` and `node dist/cli/omx.js doctor`. If AGENTS was not overwritten or merged, stop the active OMX session and rerun with `--force` or `--merge-agents`; do not edit lifecycle state manually.\n\n## Discovery troubleshooting\n\nIf `$omx-setup` is absent/stale: run `omx setup --verbose`, then `omx doctor`; verify `./.codex/skills/omx-setup/SKILL.md` for project scope or `${CODEX_HOME:-~/.codex}/skills/omx-setup/SKILL.md` for legacy user scope. In plugin mode verify the oh-my-codex plugin is installed/discovered. For duplicates, inspect historical `~/.agents/skills` overlap and follow doctor/setup cleanup guidance.\n\n## Exit contract\n\nReport selected scope/mode, dry-run versus mutation, AGENTS policy, affected roots, and doctor indicators. Stop only after setup completes successfully and verification identifies the expected files/config; on failure preserve the exact command output and rerun the smallest corrective command. Do not claim installation from a dry-run alone.\n","frontmatter":{"name":"omx-setup","description":"Setup and configure oh-my-codex using current CLI behavior"},"isInternal":false,"tokens":1174,"sizeBytes":5022},{"name":"SKILL.md","path":"skills/performance-goal/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/performance-goal/SKILL.md","title":"performance-goal","category":"anthropic-skill","format":"markdown","content":"---\nname: performance-goal\ndescription: \"Run an evaluator-gated performance optimization workflow over Codex goal mode with durable OMX artifacts and safe goal handoffs.\"\n---\n\n# Performance Goal Workflow\n\nUse this skill when a user asks OMX to optimize performance and wants a goal-oriented loop rather than a one-off review.\n\n## Contract\n\n- OMX owns durable workflow state under `.omx/goals/performance/<slug>/`.\n- Codex goal mode owns only the active-thread focus/accounting primitive.\n- Shell commands do **not** mutate hidden Codex goal state. They write artifacts and emit model-facing handoff text.\n- No optimization work may start until an evaluator command and pass/fail contract exist.\n- Do not call `update_goal({status: \"complete\"})` until the evaluator has a passing checkpoint and a completion audit proves the objective is done; then call `get_goal` again and pass that fresh snapshot to `omx performance-goal complete --codex-goal-json`.\n\n## CLI\n\nCreate the workflow and evaluator contract:\n\n```sh\nomx performance-goal create \\\n --objective \"Reduce CLI startup latency by 20%\" \\\n --evaluator-command \"npm run perf:startup\" \\\n --evaluator-contract \"PASS when p95 latency improves by 20% and regression tests pass\" \\\n --slug startup-latency\n```\n\nEmit the Codex goal handoff:\n\n```sh\nomx performance-goal start --slug startup-latency\n```\n\nRecord evaluator evidence:\n\n```sh\nomx performance-goal checkpoint --slug startup-latency --status pass --evidence \"benchmark + tests passed\"\nomx performance-goal checkpoint --slug startup-latency --status fail --evidence \"benchmark regressed\"\nomx performance-goal checkpoint --slug startup-latency --status blocked --evidence \"missing fixture\"\n```\n\nComplete only after a passing checkpoint:\n\n```sh\nomx performance-goal complete --slug startup-latency --evidence \"final evaluator evidence\" --codex-goal-json <get_goal-json-or-path>\n```\n\n## Agent Loop\n\n1. Run `omx performance-goal create` if no workflow exists.\n2. Run `omx performance-goal start` and follow the handoff:\n - call `get_goal`;\n - call `create_goal` only when no active goal exists and the objective is explicit;\n - work only against the evaluator contract;\n - after evaluator pass and completion audit, call `update_goal({status: \"complete\"})`, call `get_goal` again, and pass that snapshot to `omx performance-goal complete --codex-goal-json`;\n - after `omx performance-goal complete` succeeds, run `/goal clear` in the Codex UI before starting another goal in this same thread/session; OMX prints this terminal cleanup step but does not invoke hidden clear routes;\n3. Optimize in small reversible patches.\n4. Run the evaluator and related regression tests.\n5. Record each pass/fail/blocker with `checkpoint`.\n6. Complete only when the pass artifact exists and no required work remains.\n\n## Completion Gate\n\nA performance goal is incomplete unless `.omx/goals/performance/<slug>/state.json` contains a `lastValidation.status` of `pass` and `omx performance-goal complete` receives a matching complete Codex `get_goal` snapshot via `--codex-goal-json`. Passing ordinary tests alone is not sufficient unless they are the declared evaluator contract.\n\nLifecycle: `create_goal` starts the Codex thread goal, `update_goal({status: \"complete\"})` marks terminal success after the evaluator and audit pass, and `/goal clear` removes the completed thread goal when another same-thread goal is needed. OMX shell commands and hooks reconcile snapshots and print the cleanup instruction; they must not mutate hidden Codex goal state.\n","frontmatter":{"name":"performance-goal","description":"Run an evaluator-gated performance optimization workflow over Codex goal mode with durable OMX artifacts and safe goal handoffs."},"isInternal":false,"tokens":769,"sizeBytes":3551},{"name":"SKILL.md","path":"skills/pipeline/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/pipeline/SKILL.md","title":"pipeline","category":"anthropic-skill","format":"markdown","content":"---\nname: pipeline\ndescription: Sunset stub — use $plan and $team directly instead\n---\n\n# Pipeline — removed\n\n`$pipeline` was removed in OMX 0.21.\n\nPipeline's configurable stage sequencing overlapped `$plan` (planning) and `$team` (execution) without a unique runtime. Use the canonical skills directly: `$plan` for optional planning, `$team` for coordinated parallel execution, `$ultragoal` for durable goal-mode runs.\n\nMigration: replace `$pipeline` with explicit `$plan` and `$team` invocations as the task warrants.\n\nTask: {{ARGUMENTS}}\n","frontmatter":{"name":"pipeline","description":"Sunset stub — use $plan and $team directly instead"},"isInternal":false,"tokens":126,"sizeBytes":545},{"name":"SKILL.md","path":"skills/plan/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/plan/SKILL.md","title":"plan","category":"anthropic-skill","format":"markdown","content":"---\nname: plan\ndescription: Lightweight planning with optional interview\n---\n\n<Purpose>\nPlan creates concise, actionable work plans. Auto-detects interview vs direct, supports `--interview` for Socratic clarification and `--review` for evaluation.\n</Purpose>\n\n<Use_When>\n- Planning before implementation — \"plan this\", \"let's plan\"\n- Requirements are vague and need scoping — use `--interview`\n- Reviewing an existing plan — `--review`\n</Use_When>\n\n<Do_Not_Use_When>\n- Want direct execution — execute the scoped task directly; use `ultragoal` only for durable goals or `team` for coordinated parallel work\n- Simple focused fix with obvious scope — skip planning\n</Do_Not_Use_When>\n\n<Execution_Policy>\n- Auto-detect interview vs direct; `--interview` forces Socratic mode, `--direct` skips it\n- Ask one question at a time; gather codebase facts first\n- `omx explore` is deprecated. Use normal repository inspection for codebase facts; `omx sparkshell` only for explicit shell-native evidence\n- Plans must be evidence-backed: 80%+ claims cite file/line, 90%+ criteria testable\n- Right-size steps to scope; save to `.omx/plans/`\n</Execution_Policy>\n\n<Steps>\n\n### Mode Selection\n| Mode | Trigger | Behavior |\n|------|---------|----------|\n| Interview | `--interview` or broad request | Socratic requirements gathering |\n| Direct | `--direct` or detailed request | Generate plan immediately |\n| Review | `--review` | Critic evaluation of existing plan |\n\n### Interview (`--interview`)\n1. Classify request; ask one focused question via `omx question`\n2. Gather codebase facts first, then ask informed follow-ups\n3. Build on answers; consult Analyst for hidden requirements\n4. Create plan when user signals readiness\n\n### Direct\n1. Quick analysis (optional Analyst)\n2. Generate plan immediately\n3. Optional Critic review if requested\n\n### Review (`--review`)\n1. Read plan from `.omx/plans/`\n2. Evaluate via Critic; verdict APPROVED/REVISE/REJECT\n3. If author == reviewer, hand off to `$code-review`\n\n### Output\nEvery plan includes: Requirements Summary, Acceptance Criteria (testable), Implementation Steps (with file refs, adaptive count), Risks/Mitigations, Verification. Saved to `.omx/plans/`.\n\nOutcome-first framing: apply outcome-first framing, concise visible updates for multi-step planning. Local overrides for the active workflow branch apply via newer user task updates. If the user says `continue`, continue the current branch instead of restarting.\n\n</Steps>\n\n<Tool_Usage>\n- `omx explore` is deprecated. Use normal repository inspection; `omx sparkshell` only for explicit shell-native evidence\n- Use `omx question` for interview questions; plain text only as fallback\n- Use `ask_codex` with `planner`/`analyst`/`critic` as needed\n</Tool_Usage>\n\n<Escalation_And_Stop_Conditions>\n- Stop interviewing when requirements are clear — do not over-interview\n- Escalate on irreconcilable trade-offs requiring business decision\n- \"just do it\" / \"skip planning\" → hand off to `$ultragoal`\n</Escalation_And_Stop_Conditions>\n\n<Final_Checklist>\n- [ ] Acceptance criteria testable (90%+ concrete)\n- [ ] Claims cite file/line (80%+)\n- [ ] Risks have mitigations, no vague terms\n- [ ] Plan saved to `.omx/plans/`\n</Final_Checklist>\n\n<Advanced>\n## Question Classification\n| Type | Examples | Action |\n|------|----------|--------|\n| Codebase Fact | \"Where is X?\" | Explore first, do not ask |\n| User Preference | \"Priority?\" | Ask via `omx question` |\n| Scope Decision | \"Include Y?\" | Ask user |\n\n## Review Quality Criteria\n| Criterion | Standard |\n|-----------|----------|\n| Clarity | 80%+ claims cite file/line |\n| Testability | 90%+ criteria concrete |\n| Verification | File refs exist |\n</Advanced>\n","frontmatter":{"name":"plan","description":"Lightweight planning with optional interview"},"isInternal":false,"tokens":906,"sizeBytes":3706},{"name":"SKILL.md","path":"skills/ralph/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/ralph/SKILL.md","title":"ralph","category":"anthropic-skill","format":"markdown","content":"---\nname: ralph\ndescription: Sunset stub — use $ultragoal instead\n---\n\n# Ralph — removed\n\n`$ralph` was removed in OMX 0.21; use `$ultragoal` instead.\n\nRalph's loop-until-done behavior is a degenerate single-goal ultragoal run. `$ultragoal` owns durable Codex goal handoffs, `.omx/ultragoal` ledger checkpoints, implementation, tests, build/lint/typecheck evidence, and resume across stories. A single-goal ultragoal run reuses the same persistence and verified-completion promise that Ralph provided.\n\nMigration: replace `$ralph` with `$ultragoal`.\n\nTask: {{ARGUMENTS}}\n","frontmatter":{"name":"ralph","description":"Sunset stub — use $ultragoal instead"},"isInternal":false,"tokens":151,"sizeBytes":574},{"name":"SKILL.md","path":"skills/ralplan/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/ralplan/SKILL.md","title":"ralplan","category":"anthropic-skill","format":"markdown","content":"---\nname: ralplan\ndescription: Consensus planning stage for Planner -> Architect -> Critic handoff to $ultragoal\n---\n\n# Ralplan (Consensus Planning Alias)\n\nRalplan is the canonical consensus-planning stage used by Autopilot between `$deep-interview` and `$ultragoal`. It drives Planner, Architect, and Critic planning and records their review lifecycle with **RALPLAN-DR structured deliberation** (short mode by default, deliberate mode for high-risk work). Local lifecycle evidence is not host-issued security authority, but ordinary progression to Ultragoal must remain reachable after the execution-ready plan and sequential review evidence are durable; missing host provenance must not terminalize Ralplan or block cancel, clear, or recovery.\n\n## Usage\n\n```\n$ralplan \"task description\"\n```\n\nStandalone advisory planning is explicitly opt-in:\n\n```text\n$ralplan --advisory \"task description\"\n```\n\nAdvisory runs the same sequential Planner → Architect → Critic review lifecycle, binds the plan and both review artifacts to exact bytes and one tracker-backed iteration, then returns to the caller with `active:false`. It is a cooperative workflow pause, not a security fence or permission system. It never emits a `PreToolUse` allow/block decision, never completes the host consensus gate, never authorizes execution, and never suppresses unrelated host behavior. Terminal state must carry explicit `false` values for the consensus gate, host verification, and execution handoff rather than omitting them. A later concrete affirmative execution request may produce non-authoritative routing context, but it does not persist a permission, rewrite terminal evidence, or create an automatic handoff; quotations, code, examples, documentation, questions, modal requests, negations, and vague approval remain classifier negatives. `approved+proven` requires complete lifecycle digests plus post-write revalidation. Administrative abandonment is append-only, idempotent for prepared or committed journals, and records a separate byte-bound admin event without rewriting the original closeout journal. Real enforcement requires an explicit host-issued, host-verified receipt or capability on a non-user-mintable surface; local Advisory files, prompts, session/thread fields, tracker records, and HERDR observability cannot substitute for it. On Darwin, each Advisory evidence artifact is limited to 128 KiB by the pinned-directory reader; other supported platforms allow up to 8 MiB.\n\n## Flags\n\n- `--interactive`: Enables user prompts at key decision points (draft review in step 2 and final approval in step 6). Without this flag the workflow runs fully automated — Planner → Architect → Critic loop — and outputs the final plan without asking for confirmation.\n- `--deliberate`: Forces deliberate mode for high-risk work. Adds pre-mortem (3 scenarios) and expanded test planning (unit/integration/e2e/observability). Without this flag, deliberate mode can still auto-enable when the request explicitly signals high risk (auth/security, migrations, destructive changes, production incidents, compliance/PII, public API breakage).\n- `--advisory`: Standalone only. It cannot be combined with Autopilot, Pipeline, Team, Ralph, Ultragoal, execution flags, or unknown flags. Activation requires canonical session, root thread, and turn identity.\n\n## Ontology-heavy review\n\nFor requirements semantics, taxonomy, prompt/spec design, policy distinctions, or category-risk architecture, cite the `architect` role agent's read-only review as advisory evidence. Its findings can inform the plan or follow-up evidence when explicitly used, but `$ralplan` itself records Architect→Critic lifecycle evidence only, and advisory review is never a durable execution authorization.\n\n## Usage with interactive mode\n\n```\n$ralplan --interactive \"task description\"\n```\n\n## Behavior\n\n## GPT-5.6 Guidance Alignment\n\nUse the shared workflow guidance pattern: outcome-first framing, concise visible updates for multi-step planning, local overrides for the active workflow branch, evidence-backed planning and validation expectations, explicit stop rules, right-sized implementation/PRD shape, and automatic continuation for safe reversible steps. Ask only for material, destructive, credentialed, external-production, or preference-dependent branches.\n\nThis skill runs its own consensus runtime; it does not delegate to a nonexistent Plan consensus mode:\n\n```\nomx ralplan run --task <arguments> [--session <id>]\n```\n\nThe consensus workflow:\n1. **Planner** creates an adaptive plan (right-sized to task scope; do not default to exactly five steps) and a compact **RALPLAN-DR summary** before review. Current `[main]` vs `[planner]` behavior: standalone `$ralplan` may be authored by the active main planning lane unless the caller/runtime supplies a dedicated planner routing record; inside `$autopilot`, state field `planning_routing.owner:\"planner\"` means the initial Planner draft/decomposition must use dedicated `[planner]`. Set `.omx-config.json` `agentModels.planner` to opt into a specific planner model and force dedicated planner ownership for complex Autopilot planning even when `[main]` is not cheap/mini. The RALPLAN-DR summary includes:\n - Principles (3-5)\n - Decision Drivers (top 3)\n - Viable Options (>=2) with bounded pros/cons\n - If only one viable option remains, explicit invalidation rationale for alternatives\n - Deliberate mode only: pre-mortem (3 scenarios) + expanded test plan (unit/integration/e2e/observability)\n2. **User feedback** *(--interactive only)*: If `--interactive` is set, use the structured question UI (`omx question` in attached tmux; native structured input outside tmux when available) to present the draft plan **plus the Principles / Drivers / Options summary** before review (Proceed to review / Request changes / Skip review). Otherwise, automatically proceed to review.\n**Native role-routing preflight:** Keyword routing may already have selected Ralplan, but it is not authority. Run `omx ralplan preflight --json` only when the native task surface reports `role_routing_unavailable` and this workflow attempts adapted Ralplan Planner, Architect, or Critic authority, adapted role-intent, or adapted consensus authority. On `unsupported_documented_leader_proof`, stop before that adapted authority and use a Codex surface with documented root proof or a reviewed alternative workflow. Do not infer root identity from `session_id`, undocumented `thread_id`, session/pointer/transcript/cwd state, absence of child data, or a prompt label. Ordinary native planning, lifecycle, state, status, health, HUD, runtime, setup, install, sync, and unrelated delegation are outside this preflight boundary and remain governed by existing controls.\n\n**Native role-routing rule:** When the native surface exposes `agent_type` role routing, set `agent_type` to an installed OMX role and never omit it for OMX work. When it does not (`role_routing_unavailable`), do not fabricate `agent_type`. On the exact reviewed Codex releases 0.144.5, 0.145.0, 0.146.1, and 0.148.0-alpha.5, adapted Ralplan Planner, Architect, Critic, role-intent, and consensus authority are unavailable because they lack documented root proof; every other version remains unknown and fails closed. Do not silently weaken routing with a prompt role label or inferred carrier. Use a Codex surface with documented root proof or a reviewed alternative workflow for that authority. A direct `omx ralplan role-intent write` attempt is denied with machine reason `unsupported_documented_leader_proof`.\n\n3. **Architect** reviews for architectural soundness and must provide the strongest steelman antithesis, at least one real tradeoff tension, and (when possible) synthesis — **await completion before step 4**. Launch this as a subsequent role-specific `Architect` subagent and pass the full task statement, context snapshot, PRD/test-spec paths, and relevant prior findings; do not substitute an unvalidated reviewer identity or a short improvised reviewer prompt. In deliberate mode, Architect should explicitly flag principle violations.\n4. **Critic** evaluates against quality criteria — run only after step 3 completes. Launch this as a subsequent role-specific `Critic` subagent with the full task statement, context snapshot, PRD/test-spec paths, and the completed Architect review; do not ask the Architect subagent to perform the Critic gate and do not substitute an unvalidated reviewer identity or a short improvised reviewer prompt. Critic must enforce principle-option consistency, fair alternatives, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. In deliberate mode, Critic must reject missing/weak pre-mortem or expanded test plan.\n5. **Re-review loop** (max 5 iterations): Any non-`APPROVE` Critic verdict (`ITERATE` or `REJECT`) MUST run the same full closed loop:\n a. Collect Architect and Critic feedback\n b. Revise the plan with Planner\n c. Return to Architect review\n d. Return to Critic evaluation\n e. Repeat this loop until Critic returns `APPROVE` or 5 iterations are reached\n f. If 5 iterations are reached without `APPROVE`, present the best version to the user\n6. On Critic approval, persist the execution-ready planning artifacts and sequential Architect→Critic evidence. In standalone interactive Ralplan, present the requested future execution lane. Inside Autopilot, the existing explicit `$autopilot` invocation authorizes the supervised transition to its defining next stage, `$ultragoal`; persist an Autopilot-owned `ralplan_execution_handoff` bound to the same session and review cycle.\n7. Record `ralplan_execution_handoff` with `{authorized: true, reason, authorized_at, session_id, review_cycle, source: \"autopilot\"|\"user\"}`. `source:\"autopilot\"` is valid only for a supervised active Autopilot run whose current phase is `ralplan`; it does not claim host-consensus authority.\n8. Transition to `$ultragoal` after the durable plan, sequential approvals, and bound execution handoff exist. Do not implement directly inside Ralplan.\n\n> **Important:** Steps 3 and 4 MUST run sequentially as role-specific subagents. Do NOT issue both agent calls in the same parallel batch. Always await the subsequent `Architect` result before invoking the subsequent `Critic`; their completed approvals establish local lifecycle evidence only and cannot satisfy the durable execution gate.\n\n## Planning/Execution Boundary\n\n`$ralplan` is a planning mode. While ralplan is active and no explicit execution handoff is active, implementation-focused write tools are out of scope. Ralplan may inspect the repository and may write only planning artifacts such as `.omx/context/`, `.omx/plans/`, `.omx/specs/`, and required `.omx/state/` records.\n\nThe canonical flow is:\n\n```\n$ralplan -> local Architect→Critic lifecycle evidence -> bound execution handoff -> $ultragoal\n```\n\nBefore any execution lane begins, ralplan must emit terminal planning state (complete, paused, failed, or waiting for input) and the durable handoff record below. Do not continue from consensus planning into direct code edits in the same ralplan session.\n\n## Durable Consensus Handoff Contract\n\nRalplan is not complete, skippable, or ready for execution merely because `.omx/plans/prd-*.md` and `.omx/plans/test-spec-*.md` exist. Those files are planning artifacts, not consensus evidence.\n\nBefore any Autopilot, Ultragoal, Team, or implementation handoff, persist a durable handoff record that distinguishes:\n\n- `planning_artifacts`: PRD/test-spec paths.\n- `ralplan_architect_review`: the completed Architect review with an approving verdict.\n- `ralplan_critic_review`: the completed Critic review with an approving verdict, recorded only after the Architect review.\n- `ralplan_execution_handoff`: persist `{authorized: true, reason: \"<rationale>\", authorized_at: \"<ISO timestamp>\", session_id: \"<current session>\", review_cycle: <matching lifecycle cycle>, source: \"autopilot\"|\"user\"}`. Autopilot may issue this only for its own supervised `ralplan` phase; standalone Ralplan uses `source:\"user\"`.\n- `ralplan_consensus_gate.complete` records lifecycle completion after the sequential Architect and Critic approvals. It is not a host-security claim. Locally authored JSON/env/prompt/tracker/transcript/receipt-shaped evidence must never be described as host-issued authority.\n\nIf Architect is missing/blocked, keep the workflow in Architect review or report that blocker. If Critic is missing/blocked/non-approving, keep the workflow in Critic/re-review or report the max-iteration outcome. After both reviews approve, execution begins only when the matching `ralplan_execution_handoff` is durable. Existing plan/test-spec files alone are never permission to skip Ralplan or execute.\n\nFollow the Plan skill's full documentation for consensus mode details.\n\n## Goal-Mode Follow-up Suggestions\n\nWhen a bound `ralplan_execution_handoff` permits execution, include product-facing goal-mode suggestions alongside coordinated Team execution. Record the requested lane and persist the handoff without claiming host-issued authority.\n\n- `$ultragoal` — **default goal-mode follow-up** for implementation or general goal-oriented follow-up plans that should become durable Codex/OMX goals with sequential completion tracking.\n- `$autoresearch` — research-project follow-up when the plan centers on a question, literature/reference gathering, evaluator-backed research, or a professor/critic-style research deliverable. (`$autoresearch-goal` was retired to a sunset stub in OMX 0.21.)\n- `$performance-goal` — optimization/performance follow-up when the plan centers on speed, latency, throughput, memory, benchmark, or other measurable performance work.\n\nUse `$ultragoal` for durable goal tracking and `$team` for coordinated parallel implementation. When combined, Ultragoal owns the ledger and Team returns checkpoint-ready execution evidence.\nUse the available-agent-types roster to produce explicit role/staffing allocation, reasoning-by-lane guidance, concrete launch hints (including `omx team` when parallel delivery is justified), and team verification responsibilities for any future receipt-authorized execution path.\n\n## Pre-context Intake\n\nBefore consensus planning or execution handoff, ensure a grounded context snapshot exists:\n\n1. Derive a task slug from the request.\n2. Reuse the latest relevant snapshot in `.omx/context/{slug}-*.md` when available.\n3. If none exists, create `.omx/context/{slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`) with:\n - task statement\n - desired outcome\n - known facts/evidence\n - constraints\n - unknowns/open questions\n - likely codebase touchpoints\n4. If ambiguity remains high, gather brownfield facts first. `omx explore` is deprecated; use normal repository inspection tools/subagents for simple read-only repository lookups and `omx sparkshell` only for explicit shell-native read-only evidence. Then run `$deep-interview --quick <task>` before continuing.\n5. If the plan depends on official docs, version-aware framework guidance, best practices, or external dependency behavior, use `$best-practice-research` as the bounded evidence wrapper and auto-delegate `researcher` for the official/upstream lookup before finalizing the planning handoff so execution does not start from repo-local recall alone.\n6. If a prior `$autoresearch` run exists, treat its approved artifact as evidence for the plan. Read historical artifacts from `$autoresearch-goal` only as compatibility input. Do not include Autoresearch as a final architecture or runtime component unless the user explicitly requested ongoing research automation; otherwise synthesize the evidence into the `$ralplan` ADR, risks, and verification steps.\n\nDo not hand off to execution modes until this intake is complete; if urgency forces progress, explicitly document the risk tradeoffs.\n\n## Routing boundary\n\nOrdinary scoped tasks stay in the direct execution lane described by `templates/AGENTS.md`.\nExplicit workflow requests follow the keyword registry (`src/hooks/keyword-registry.ts`) and their owning skill contracts; this card does not define a second activation table.\nOnce Ralplan is active, preserve the planning/execution and consensus handoff requirements above. A conversational “just do it” is not a substitute for the required review evidence.\n\n## Scenario Examples\n\n**Good:** The user says `continue` after the workflow already has a clear next step. Continue the current branch of work instead of restarting or re-asking the same question.\n\n**Good:** The user changes only the output shape or downstream delivery step (for example `make a PR`). Preserve earlier non-conflicting workflow constraints and apply the update locally.\n\n**Bad:** The user says `continue`, and the workflow restarts discovery or stops before the missing verification/evidence is gathered.\n","frontmatter":{"name":"ralplan","description":"Consensus planning stage for Planner -> Architect -> Critic handoff to $ultragoal"},"isInternal":false,"tokens":3558,"sizeBytes":16945},{"name":"SKILL.md","path":"skills/skill/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/skill/SKILL.md","title":"skill","category":"anthropic-skill","format":"markdown","content":"---\nname: skill\ndescription: Manage local skills - list, add, remove, search, edit, setup wizard\nargument-hint: \"<command> [args]\"\n---\n\n# Skill Management\n\nManage local `SKILL.md` files with `/skill` commands. Shared execution, delegation,\nstate, hook, team, cancellation, verification, and escalation invariants live in\n`templates/AGENTS.md`; follow that contract instead of repeating it here.\n\n<Purpose>\nCreate, inspect, validate, update, and organize user- or project-scoped skills.\nKeep each skill specific, actionable, evidence-based, and useful to this codebase.\n</Purpose>\n\n<Use_When>\n- The user asks to list, add, edit, remove, search, inspect, sync, set up, scan, or validate skills.\n- A durable, codebase-specific solution or workflow should be captured as a skill.\n</Use_When>\n\n<Do_Not_Use_When>\n- Use `/learner` to extract a skill from a conversation and `/note` for a short note.\n- Do not use this prompt to change runtime code, catalogs, hooks, or installation logic.\n</Do_Not_Use_When>\n\n## Scopes and commands\n\nCanonical roots are `${CODEX_HOME:-$HOME/.codex}/skills/` (user) and `.codex/skills/`\n(project). A skill lives at `<root>/<name>/SKILL.md`.\n\n| Command | Contract |\n|---|---|\n| `/skill list` | Scan both roots, parse frontmatter, and show name, description, triggers, scope, and quality/usage (`N/A` when unavailable). |\n| `/skill add [name]` | Run the authoring wizard, validate the name, choose scope, create `SKILL.md`, and report its path. |\n| `/skill edit <name>` | Find one scope, show metadata, then update description, triggers, argument hint, body, or rename and report the change. |\n| `/skill remove <name>` | Find the skill, show scope and metadata, confirm explicitly, then remove its directory. |\n| `/skill search <query>` | Case-insensitively search name, description, triggers, and body; rank name/trigger matches first and show context. |\n| `/skill info <name>` | Show parsed metadata, scope, path, and full body; suggest `/skill search` when absent. |\n| `/skill sync` | Compare user/project skills, show user-only/project-only/common entries, and confirm every copy or overwrite. |\n| `/skill setup` | Ensure both roots exist, scan them, then offer add, list, pattern scan, import, or done. |\n| `/skill scan` | Run setup's scan/inventory without its interactive menu. |\n| `/skill validate` | Validate every skill in both roots and report each path's pass/fail result; never rewrite files. |\n\nWith an argument, use direct command mode; without one, use the guided setup menu.\n\n## Authoring contract\n\nAsk for any missing values:\n1. `name`: lowercase letters/digits separated by single hyphens (`[a-z0-9]+(?:-[a-z0-9]+)*`).\n2. `description`: a concise, non-empty one-line purpose.\n3. `triggers`: comma-separated recognition terms.\n4. `argument-hint`: optional invocation arguments.\n5. `scope`: `user` or `project`.\n\nWrite this frontmatter at the start of every skill; optional metadata may add `id`,\n`source`, and `quality` without replacing required fields:\n\n```yaml\n---\nname: <name>\ndescription: <one-line purpose>\ntriggers: [<trigger1>, <trigger2>]\nargument-hint: \"<args>\"\n# optional: id, source, quality\n---\n```\n\nUse an actionable body. The minimum recommended shape is:\n\n```markdown\n# <Skill title>\n\n## Purpose\nWhat durable, codebase-specific outcome does this skill provide?\n\n## When to Activate\nRecognition signals, scope, and explicit non-goals.\n\n## Workflow\n1. Inspect the named files or inputs.\n2. Apply the precise approach and record important assumptions.\n3. Verify observable behavior and report evidence.\n\n## Examples / Gotchas\nConcrete invocation, edge cases, and failure recovery.\n```\n\nPrefer hard-won, non-obvious knowledge over generic programming advice. Include\nexact paths, commands, error text, and expected evidence when they materially help.\n\n## Validation and errors\n\nBefore reporting success, check that the file exists, starts with `---` frontmatter,\nhas non-empty `name` and `description`, uses a valid name, and has a non-empty body.\nReject malformed or unterminated YAML, multiline required scalar values, duplicate\nnames in one scope, missing directories/files, permission failures, and invalid\narguments. Report errors consistently:\n\n```text\n✗ Error: <clear message>\n→ Suggestion: <specific next step>\n```\n\n## Exit contract\n\nEvery command ends with one concise result: `✓` plus the affected skill/path and\nnext action, or `✗` plus the error and suggestion. Preserve files on cancel or\nvalidation-only runs. For add/edit/sync, report changed scope and metadata; for\nlist/search/info/scan/validate, report counts or matched paths and any failures.\n","frontmatter":{"name":"skill","description":"Manage local skills - list, add, remove, search, edit, setup wizard","argument-hint":"<command> [args]"},"isInternal":false,"tokens":1098,"sizeBytes":4624},{"name":"SKILL.md","path":"skills/team/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/team/SKILL.md","title":"team","category":"anthropic-skill","format":"markdown","content":"---\nname: team\ndescription: N coordinated agents on shared task list using tmux-based orchestration\n---\n\n# Team Skill\n\n## When to use\n\nUse only for an explicit `$team` request or `omx team ...` launch that benefits from durable tmux workers, shared task state, mailbox coordination, or worktree isolation. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot`; do not copy its durable rules into this card.\n\n## Inputs and preconditions\n\n- Launch shape: `omx team [N:agent-type] \"<task>\"` (for example `omx team 3:executor \"implement X\"`).\n- Require `tmux -V`, a leader session with `$TMUX`, and the intended `omx` executable. In Codex App/plain non-tmux sessions, explain the runtime boundary instead of pretending Team is available.\n- Before launch, ground the task in a recent `.omx/context/{slug}-*.md`; create a concise snapshot when none exists. Include target, evidence, constraints, unknowns, and likely touchpoints.\n- Do not launch nested Team runs. Pick worker roles deliberately; use `OMX_TEAM_WORKER_CLI=codex|claude|auto` or `OMX_TEAM_WORKER_CLI_MAP=...` only when needed.\n- Per-agent reasoning is set by `agentReasoning`; accepted values are `low`, `medium`, `high`, `xhigh`, and `max`. `max` is passed unchanged and remains capability-dependent. `ultra` is unsupported and is not an alias for `max`.\n- Invalid configured values use the built-in role-default fallback. An explicit raw `-c model_reasoning_effort=...` is opaque and wins. When both sources are present, explicit raw reasoning wins over inherited Team reasoning and environment reasoning. Do not downgrade or retry `max` as `xhigh`; built-in role defaults remain unchanged.\n\n## Operational steps\n\n1. Start the runtime and capture startup evidence: `Team started: <name>`, tmux target, worker panes, and the leader ACK mailbox.\n2. **Current Runtime Behavior:** runtime-owned task files and APIs are the operational interface; the durable ownership and safety rules remain in `templates/AGENTS.md`.\n3. Runtime creates `.omx/state/team/<name>/config.json`, `manifest.v2.json`, `tasks/task-<id>.json`, worker identities/inboxes, mailbox files, and a dispatch queue. Workers receive `OMX_TEAM_WORKER`, `OMX_TEAM_STATE_ROOT`, and `OMX_TEAM_LEADER_CWD`.\n4. Deliver assignments through durable inbox/task state and the CLI API. The worker card defines ACK, claim, transition, mailbox, and idle-status commands.\n5. Prefer these machine-readable operations:\n ```bash\n omx team api send-message --input '{\"team_name\":\"<name>\",\"from_worker\":\"leader-fixed\",\"to_worker\":\"worker-1\",\"body\":\"<short trigger>\"}' --json\n omx team api read-task --input '{\"team_name\":\"<name>\",\"task_id\":\"<id>\"}' --json\n omx team api transition-task-status --input '{\"team_name\":\"<name>\",\"task_id\":\"<id>\",\"from\":\"in_progress\",\"to\":\"completed\",\"claim_token\":\"<token>\"}' --json\n ```\n6. Monitor with `omx team status <name> --json` or `omx team await <name> --timeout-ms 30000 --json`; inspect mailbox/state files when a worker is blocked or stale.\n7. Keep the team running until `pending=0`, `in_progress=0`, and `failed=0` (or an explicitly acknowledged failure path). Run `omx team shutdown <name>` only then, unless the user explicitly aborts.\n8. Verify shutdown evidence and state cleanup. Do not claim completion while workers are still writing.\n\n## Team and Ultragoal\n\nWhen a leader-owned `.omx/ultragoal/goals.json` exists, workers return task evidence only. The leader checkpoints with a fresh Codex `get_goal` snapshot:\n```bash\nomx ultragoal checkpoint --goal-id <id> --status complete --evidence \"<Team evidence>\" --codex-goal-json <fresh-get-goal-json-or-path>\n```\nTeam launch remains an explicit separate action; it does not create hidden Codex goals.\n\n## Dispatch and recovery\n\n- If dispatch reports `worker_notify_failed:<worker>`, inspect `tmux list-panes`, capture the pane, then send one concise trigger and re-check mailbox/state.\n- For Claude panes, do not spam Enter while work is active. Confirm runtime status first.\n- If a worker reports `omx team api ... ENOENT`, check whether shutdown or state deletion happened too early; preserve state until all transitions finish.\n- For a clean retry, kill only known stale worker panes, remove only the exact stale Team root, and relaunch; never kill the leader/HUD pane accidentally.\n\n## Exit and evidence\n\nReport team name, launch command, pane/ACK evidence, task counts, worker verification, failures or blockers, shutdown result, and cleaned state paths. Include any worktree or CLI-map choices and keep final integration/verification in the leader lane.\n","frontmatter":{"name":"team","description":"N coordinated agents on shared task list using tmux-based orchestration"},"isInternal":false,"tokens":1092,"sizeBytes":4575},{"name":"SKILL.md","path":"skills/ultragoal/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/ultragoal/SKILL.md","title":"ultragoal","category":"anthropic-skill","format":"markdown","content":"---\nname: ultragoal\ndescription: Create and execute durable repo-native multi-goal plans over Codex goal mode artifacts.\n---\n\n# Ultragoal Workflow\n\n## When to use\n\nUse for `ultragoal`, `create-goals`, `complete-goals`, durable multi-goal planning, or sequential execution over Codex `/goal`. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot` for state ownership and goal-tool boundaries.\n\n## Inputs and preconditions\n\n- Durable artifacts are `.omx/ultragoal/brief.md`, `.omx/ultragoal/goals.json`, and `.omx/ultragoal/ledger.jsonl`.\n- New plans use aggregate Codex goal mode by default: one stable pointer objective for the plan while OMX tracks individual stories. Use `--codex-goal-mode per-story` only when explicitly requested.\n- Do not call `/goal clear` from shell or this skill. After a completed run, the operator may clear the interactive Codex goal in the Codex UI before another same-thread run.\n\n## Operational steps: create\n\nRun one command, then inspect the generated plan:\n```bash\nomx ultragoal create-goals --brief \"<brief>\"\nomx ultragoal create-goals --brief-file <path>\ncat <brief> | omx ultragoal create-goals --from-stdin\nomx ultragoal create-goals --codex-goal-mode per-story --brief \"<brief>\"\n```\nIf refinement is needed, use explicit supported steering rather than editing durable artifacts by hand.\n\n## Operational steps: execute\n\nRepeat until `omx ultragoal status` reports all goals complete:\n\n1. Run `omx ultragoal complete-goals` and read its handoff.\n2. Call `get_goal`. Call `create_goal` with the printed payload only when no active Codex goal exists; otherwise continue the matching aggregate objective.\n3. Complete one OMX story and audit its objective against real artifacts and verification evidence.\n4. For intermediate aggregate stories, keep the Codex goal active and checkpoint:\n ```bash\n omx ultragoal checkpoint --goal-id <id> --status complete --evidence \"<evidence>\" --codex-goal-json <fresh-get-goal-json-or-path>\n ```\n5. For a blocked/failed story, use `--status blocked|failed` with evidence; resume failed work with `omx ultragoal complete-goals --retry-failed`.\n6. On the final story, complete the final gate below before `update_goal({status: \"complete\"})`; then call `get_goal` again and checkpoint the fresh complete snapshot.\n\n## Explicit steering\n\nUse evidence-backed directives only when the decomposition must change:\n```bash\nomx ultragoal steer --kind add_subgoal --title \"<title>\" --objective \"<objective>\" --evidence \"<evidence>\" --rationale \"<reason>\" --json\nomx ultragoal steer --directive-json ./steering.json --json\n```\nSupported kinds: `add_subgoal`, `split_subgoal`, `reorder_pending`, `revise_pending_wording`, `annotate_ledger`, and `mark_blocked_superseded`. Ordinary prose does not mutate the plan; repeated structured directives dedupe.\n\n## Phase/HUD handoff\n\nAt standalone activation, declare the smallest accurate phase (`planning`, `executing`, `verifying`, `reviewing`, `checkpointing`, or `blocked`):\n```bash\nomx state write --input '{\"mode\":\"ultragoal\",\"active\":true,\"current_phase\":\"planning\"}' --json\n```\nInside Autopilot, keep the parent mode active and set `current_phase:\"ultragoal\"`; persist Ultragoal evidence under `handoff_artifacts.ultragoal` before a code-review handoff. Mark standalone Ultragoal complete only when every durable goal is complete.\n\n## Optional Team bridge\n\nFor parallel story execution, use the separate Team command. The leader records the Ultragoal checkpoint with a fresh `get_goal` snapshot; see the Team skill for the bridge details.\n\n## Final gate and exit evidence\n\nBefore final completion:\n\n1. Run targeted story verification.\n2. Run `ai-slop-cleaner` on changed files, then rerun verification.\n3. Audit every architecture/domain invariant from the brief/spec/accepted steering against implementation, test, and review evidence.\n4. Run `$code-review` through independent `code-reviewer` and `architect` lanes. If review or invariant proof is not clean, do not update the Codex goal; record durable blockers:\n ```bash\n omx ultragoal record-review-blockers --goal-id <id> --title \"Resolve final code-review blockers\" --objective \"<objective>\" --evidence \"<findings>\" --codex-goal-json <active-get-goal-json-or-path>\n ```\n5. If clean, call `update_goal({status: \"complete\"})`, call `get_goal`, and checkpoint with `--quality-gate-json` containing cleaner, verification, review, and architecture-invariant evidence.\n\nReport goal ids/statuses, ledger/checkpoint paths, fresh goal snapshot evidence, review verdicts, and any blocker. Never claim completion from OMX state alone.\n","frontmatter":{"name":"ultragoal","description":"Create and execute durable repo-native multi-goal plans over Codex goal mode artifacts."},"isInternal":false,"tokens":1081,"sizeBytes":4606},{"name":"SKILL.md","path":"skills/ultraqa/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/ultraqa/SKILL.md","title":"ultraqa","category":"anthropic-skill","format":"markdown","content":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=skills%2Fultraqa%2FSKILL.md -->","frontmatter":{"name":"ultraqa","description":"Adversarial dynamic e2e QA workflow - generate hostile scenarios, test, verify, fix, report, and clean up"},"isInternal":false,"tokens":1472,"sizeBytes":6370},{"name":"agent-tiers.md","path":"skills/ultrawork/references/agent-tiers.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/ultrawork/references/agent-tiers.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=skills%2Fultrawork%2Freferences%2Fagent-tiers.md -->","isInternal":false,"tokens":644,"sizeBytes":2590},{"name":"SKILL.md","path":"skills/ultrawork/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/ultrawork/SKILL.md","title":"ultrawork","category":"anthropic-skill","format":"markdown","content":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=skills%2Fultrawork%2FSKILL.md -->","frontmatter":{"name":"ultrawork","description":"Sunset stub — use $team instead"},"isInternal":false,"tokens":114,"sizeBytes":462},{"name":"SKILL.md","path":"skills/visual-ralph/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/visual-ralph/SKILL.md","title":"visual-ralph","category":"anthropic-skill","format":"markdown","content":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=skills%2Fvisual-ralph%2FSKILL.md -->","frontmatter":{"name":"visual-ralph","description":"Visual Ralph orchestration for frontend UI from generated references, static references, or live URL targets, using $ultragoal with built-in visual verdict and pixel-diff evidence until the implementation matches and leaves a reproducible design system."},"isInternal":false,"tokens":1162,"sizeBytes":5649},{"name":"SKILL.md","path":"skills/wiki/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/wiki/SKILL.md","title":"wiki","category":"anthropic-skill","format":"markdown","content":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=skills%2Fwiki%2FSKILL.md -->","frontmatter":{"name":"wiki","description":"Persistent markdown project wiki stored under repository omx_wiki with keyword search and lifecycle capture","triggers":["wiki add","wiki lint","wiki query","wiki read","wiki delete"]},"isInternal":false,"tokens":438,"sizeBytes":1723},{"name":"SKILL.md","path":"skills/worker/SKILL.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/skills/worker/SKILL.md","title":"worker","category":"anthropic-skill","format":"markdown","content":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=skills%2Fworker%2FSKILL.md -->","frontmatter":{"name":"worker","description":"Team worker protocol (ACK, mailbox, task lifecycle) for tmux-based OMX teams"},"isInternal":false,"tokens":712,"sizeBytes":2767},{"name":"marketplace.json","path":".agents/plugins/marketplace.json","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/.agents/plugins/marketplace.json","title":"oh-my-codex-local","category":"marketplace","format":"json","content":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=.agents%2Fplugins%2Fmarketplace.json -->","frontmatter":{"name":"oh-my-codex-local","interface":{"displayName":"oh-my-codex Local Plugins"},"plugins":[{"name":"oh-my-codex","source":{"source":"local","path":"./plugins/oh-my-codex"},"policy":{"installation":"AVAILABLE","authentication":"ON_INSTALL"},"category":"Developer Tools"}]},"isInternal":false,"tokens":113,"sizeBytes":397},{"name":"README.md","path":"packages/vscode-extension/README.md","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/packages/vscode-extension/README.md","title":"vscode-extension Documentation","category":"plugin-manifest","format":"markdown","content":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=packages%2Fvscode-extension%2FREADME.md -->","isInternal":false,"tokens":922,"sizeBytes":4144},{"name":"plugin.json","path":"plugins/oh-my-codex/.codex-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/HEAD/plugins/oh-my-codex/.codex-plugin/plugin.json","title":"oh-my-codex","category":"plugin-manifest","format":"json","content":"<!-- Skill available on-demand via /api/skills/Yeachan-Heo/oh-my-codex?path=plugins%2Foh-my-codex%2F.codex-plugin%2Fplugin.json -->","frontmatter":{"name":"oh-my-codex","version":"0.21.31","description":"Multi-agent orchestration layer for OpenAI Codex CLI","author":{"name":"Yeachan Heo","url":"https://github.com/Yeachan-Heo"},"homepage":"https://yeachan-heo.github.io/oh-my-codex","repository":"https://github.com/Yeachan-Heo/oh-my-codex.git","license":"MIT","keywords":["codex","openai","cli","agents","orchestration","multi-agent"],"skills":"./skills/","mcpServers":"./.mcp.json","apps":"./.app.json","interface":{"displayName":"oh-my-codex","shortDescription":"Workflow layer and skill bundle for OpenAI Codex CLI.","longDescription":"Plugin = OMX skill/workflow discovery plus plugin-scoped companion metadata for hooks, MCP servers, and apps. Setup = runtime wiring; legacy setup installs native agents/prompts, while plugin setup enables official plugin-scoped hooks, archives stale legacy native agents/prompts, and keeps config, optional AGENTS.md, HUD, and runtime state current.","developerName":"Yeachan Heo","category":"Developer Tools"},"hooks":"./hooks/hooks.json"},"isInternal":false,"tokens":330,"sizeBytes":1170}],"systemPromptSnippet":"<yakaai_skills repo=\"Yeachan-Heo/oh-my-codex\">\n<!-- File: templates/AGENTS.md (Tokens: ~4559 | Category: root-instruction) -->\n<!-- AUTONOMY DIRECTIVE — DO NOT REMOVE -->\nYOU ARE AN AUTONOMOUS CODING AGENT. EXECUTE TASKS TO COMPLETION WITHOUT ASKING FOR PERMISSION.\nDO NOT STOP TO ASK \"SHOULD I PROCEED?\" — PROCEED. DO NOT WAIT FOR CONFIRMATION ON OBVIOUS NEXT STEPS.\nIF BLOCKED, TRY AN ALTERNATIVE APPROACH. ONLY ASK WHEN TRULY AMBIGUOUS OR DESTRUCTIVE.\nUSE CODEX NATIVE SUBAGENTS FOR INDEPENDENT PARALLEL SUBTASKS WHEN THAT IMPROVES THROUGHPUT. THIS IS COMPLEMENTARY TO OMX TEAM MODE.\n<!-- END AUTONOMY DIRECTIVE -->\n\n# oh-my-codex - Intelligent Multi-Agent Orchestration\n\nYou are running with oh-my-codex (OMX), a coordination layer for Codex CLI.\nThis AGENTS.md is the top-level operating contract for the workspace.\nRole prompts under `prompts/*.md` are narrower execution surfaces. They must follow this file, not override it.\nWhen OMX is installed, load the installed prompt/skill/agent surfaces from `~/.codex/prompts`, `~/.codex/skills`, and `~/.codex/agents` (or the project-local `./.codex/...` equivalents when project scope is active).\n\n<guidance_schema_contract>\nCanonical guidance schema for this template is defined in `docs/guidance-schema.md`.\nKeep runtime marker contracts stable and non-destructive when overlays are applied:\n- `<!-- OMX:RUNTIME:START --> ... <!-- OMX:RUNTIME:END -->`\n- `<!-- OMX:TEAM:WORKER:START --> ... <!-- OMX:TEAM:WORKER:END -->`\n</guidance_schema_contract>\n\n<operating_principles>\n- Solve the task directly when you can do so safely and well.\n- Delegate only when it materially improves quality, speed, or correctness.\n- Keep progress short, concrete, and useful.\n- Prefer evidence over assumption; verify before claiming completion.\n- Check official documentation before implementing with unfamiliar SDKs, frameworks, or APIs.\n- Within one Codex session or team pane, use Codex native subagents for independent, bounded subtasks when that improves throughput.\n<!-- OMX:GUIDANCE:OPERATING:START -->\n- Default to outcome-first, quality-focused responses: identify the user's target result, success criteria, constraints, available evidence, expected output, and stop condition before adding process detail.\n- Keep collaboration style short and direct. Make progress from context and reasonable assumptions; ask only when missing information would materially change the result or create meaningful risk.\n- Start multi-step or tool-heavy work with a concise visible preamble that acknowledges the request and names the first step; keep later updates brief and evidence-based.\n- Proceed automatically on clear, low-risk, reversible next steps; ask only for irreversible, credential-gated, external-production, destructive, or materially scope-changing actions.\n- AUTO-CONTINUE for clear, already-requested, low-risk, reversible, local edit-test-verify work; keep inspecting, editing, testing, and verifying without permission handoff.\n- ASK only for destructive, irreversible, credential-gated, external-production, or materially scope-changing actions, or when missing authority blocks progress.\n- On AUTO-CONTINUE branches, do not use permission-handoff phrasing; state the next action or evidence-backed result.\n- Keep going unless blocked; finish the current safe branch before asking for confirmation or handoff.\n- Ask only when blocked by missing information, missing authority, or an irreversible/destructive branch.\n- Use absolute language only for true invariants: safety, security, side-effect boundaries, required output fields, workflow state transitions, and product contracts.\n- Do not ask or instruct humans to perform ordinary non-destructive, reversible actions; execute those safe reversible OMX/runtime operations and ordinary commands yourself.\n- Treat OMX runtime manipulation, state transitions, and ordinary command execution as agent responsibilities when they are safe and reversible.\n- Treat newer user task updates as local overrides for the active task while preserving earlier non-conflicting instructions.\n- When the user provides newer same-thread evidence (for example logs, stack traces, or test output), treat it as the current source of truth, re-evaluate earlier hypotheses against it, and do not anchor on older evidence unless the user reaffirms it.\n- Persist with retrieval, inspection, diagnostics, tests, or tool use only while they materially improve correctness, required citations, validation, or safe execution; stop once the core request is answerable with sufficient evidence.\n- More effort does not mean reflexive web/tool escalation; re-evaluate low/medium effort and the smallest useful tool loop before escalating reasoning or retrieval.\n<!-- OMX:GUIDANCE:OPERATING:END -->\n</operating_principles>\n\n## Working agreements\n- For cleanup/refactor/deslop work, write a cleanup plan and lock behavior with regression tests before editing when coverage is missing.\n- Prefer deletion, existing utilities, and existing patterns before new abstractions; add dependencies only when explicitly requested.\n- Keep diffs small, reviewable, and reversible.\n- Verify with lint, typecheck, tests, and static analysis after changes; final reports include changed files, simplifications, and remaining risks.\n\n\n<delegation_rules>\nChoose the lane before acting:\n- Solo execute by default when scope is clear: work directly. The ordinary workflow is `understand -> execute -> verify -> report`.\n- Use `$autopilot` for explicit hands-off orchestration. Its defining default chain is `$deep-interview -> $ralplan -> $ultragoal`; these supervised stages must not be hollowed into optional hints.\n- Use `$deep-interview` when requirements, intent, non-goals, or decision boundaries are materially ambiguous; it is the independent Ouroboros-style Socratic deep interview stage before planning.\n- Use `$plan` for lightweight planning when a deep interview is unnecessary.\n- Use `$team` when an approved plan needs coordinated parallel execution across multiple lanes.\n- Use `$ultragoal` for durable multi-goal runs with checkpoint/resume semantics.\n- Outside active `team`/`swarm` mode, use `executor` for bounded implementation or review slices; do not invoke `worker` as a general-purpose role.\n- Reserve `worker` strictly for active `team`/`swarm` sessions where the team runtime assigns a worker lane.\n- `worker` is a team-runtime surface, not a general-purpose child role.\n- Stages may also be invoked independently when their input contract is satisfied. `$deep-interview` is not `$plan --interview`.\n\n\nUse Codex native subagents for bounded implementation, research, review, or verification slices when they materially improve quality, speed, or safety. Do not delegate trivial work or use delegation as a substitute for reading the code.\n- Under ordinary native support with inherited permissions, native children may implement, mutate, and report bounded delegated work directly: reporting back through the native result surface is ordinary completion, not a separate authority grant, and local state, task text, session fields, trackers, or child provenance remain routing/diagnostic data, never a substitute for real sandbox, approval, cross-session ownership, or privileged-operation boundaries. Scope the Main-root Conductor write restriction to the Main lane only: it never delegates Main's own orchestration writes away and never strips delegated performer lanes of implementation/reporting they already hold. Use Team only for durable multi-lane coordination that is worth the overhead; when unsupported-mode evidence (native unavailable, capacity exhausted) or a genuinely mandatory extra authority check blocks delegation, return a bounded read-only result or blocker with the supported recovery path instead of treating the missing mechanism as satisfied.\n</delegation_rules>\n\n<child_agent_protocol>\nLeader responsibilities: choose the mode, delegate bounded verifiable subtasks, integrate results, and own final verification.\nWorker responsibilities: execute the assigned slice, stay inside scope, and report blockers, shared-file conflicts, scope expansion, or recommended handoffs upward; child prompts should report recommended handoffs upward rather than recursively orchestrating.\nLeader vs worker: leaders own mode selection, integration, verification, and stop/escalate calls; workers execute assigned slices and escalate from worker to leader for blockers, shared-file conflicts, scope expansion, missing authority, or mode mismatch.\nRules: max 6 concurrent child agents; child prompts remain under AGENTS.md authority; prefer inherited model defaults unless a task has a concrete model reason; `worker` is a team-runtime surface, not a general-purpose child role.\n</child_agent_protocol>\n\n\n<invocation_conventions>\n- `$name` — invoke a workflow skill.\n- `/skills` — browse available skills.\n- Prefer explicit skill invocation for deterministic workflow routing.\n</invocation_conventions>\n\n<model_routing>\nMatch role to task shape: `explore` for repo lookup, `researcher` for official docs/reference gathering, `dependency-expert` for SDK/package decisions, `executor` for implementation, `debugger` for root cause, `architect`/`critic` for high-complexity review. Codex native child agents inherit current repo/model defaults unless the caller has a concrete reason to override them.\n</model_routing>\n\n<specialist_routing>\nLeader/workflow routing contract:\n<!-- OMX:GUIDANCE:SPECIALIST-ROUTING:START -->\n- Route to `explore` for repo-local file / symbol / pattern / relationship lookup, current implementation discovery, or mapping how this repo currently uses a dependency. `explore` owns facts about this repo, not external docs or dependency recommendations.\n- Route to `researcher` when the main need is official docs, external API behavior, version-aware framework guidance, release-note history, or citation-backed reference gathering. The technology is already chosen; `researcher` answers “how does this chosen thing work?” and is not the default dependency-comparison role.\n- Route to `dependency-expert` when the main need is package / SDK selection or a comparative dependency decision: whether / which package, SDK, or framework to adopt, upgrade, replace, or migrate; candidate comparison; maintenance, license, security, or risk evaluation across options.\n- Use mixed routing deliberately: `explore` -> `researcher` for current local usage plus official-doc confirmation; `explore` -> `dependency-expert` for current dependency usage plus upgrade / replacement / migration evaluation; `researcher` -> `explore` when docs are clear but repo usage or impact still needs confirmation; `dependency-expert` -> `explore` when a dependency decision is clear but the local migration surface still needs mapping.\n- Specialists should report boundary crossings upward instead of silently absorbing adjacent work.\n- When external evidence materially affects the answer, do not keep the leader in the main lane on recall alone; route to the relevant specialist first, then return to planning or execution.\n<!-- OMX:GUIDANCE:SPECIALIST-ROUTING:END -->\n</specialist_routing>\n\n<agent_catalog>\nKey roles: `explore`, `researcher`, `dependency-expert`, `planner`, `architect`, `debugger`, `executor`, `test-engineer`, `verifier`, and `critic`. Use the installed role catalog for full descriptions.\n</agent_catalog>\n\n<keyword_detection>\nKeyword routing is implemented primarily by native `UserPromptSubmit` hooks and the generated keyword registry. Treat hook-injected routing context as authoritative for the current turn, then load the named `SKILL.md` or prompt file as instructed.\n\nFallback behavior when hook context is unavailable:\n- Explicit `$name` invocations run left-to-right and override implicit keywords.\n- Bare skill names do not activate skills by themselves; skill-name activation requires explicit `$skill` invocation. Natural-language routing phrases may still map to a workflow. Examples: `analyze` / `investigate` → `$analyze` for read-only deep analysis with ranked synthesis, explicit confidence, and concrete file references.\n- Keep the detailed keyword list in `src/hooks/keyword-registry.ts`; do not duplicate it here.\n\nRuntime workflows such as `autopilot`, `ultraqa`, `team`, and `ultragoal` require OMX CLI runtime support. In Codex App, outside-tmux, or plain Codex sessions without OMX tmux runtime, explain that those workflows are not directly available there and continue with the nearest App-safe surface unless the user explicitly wants to launch OMX CLI from shell first.\n- Route explicit `$autopilot` to its supervised `$deep-interview -> $ralplan -> $ultragoal` chain.\n- `$ralph`, `$ultrawork`, `$pipeline`, `ecomode`, and `swarm` remain removed or deprecated sunset stubs; do not route users there.\n- When deep-interview is active in attached-tmux OMX CLI/runtime, ask each interview round via `omx question`; after launching `omx question` in a background terminal, wait for that terminal to finish and read the JSON answer before continuing; preserve the leader pane with `OMX_QUESTION_RETURN_PANE=$TMUX_PANE` when invoking it through Bash/tool paths. Outside tmux or native surfaces that cannot render `omx question` should use the native structured question path when available; otherwise ask exactly one concise plain-text question and wait for the answer.\n\n</keyword_detection>\n\n<skills>\nSkills are workflow commands. Always load the relevant installed `SKILL.md` before following a skill-specific process. Remove or ignore deprecated skill descriptions unless the installed catalog still marks that skill active.\n</skills>\n\n<team_compositions>\nUse explicit team orchestration for feature development, bug investigation, code review, UX audit, and similar multi-lane work when coordination value outweighs overhead.\n</team_compositions>\n\n<team_pipeline>\nTeam mode is the structured multi-agent surface. Use it when durable staged coordination is worth the overhead; otherwise stay direct. Terminal states: `complete`, `failed`, `cancelled`.\n</team_pipeline>\n\n<team_model_resolution>\nTeam/Swarm worker model precedence: explicit `OMX_TEAM_WORKER_LAUNCH_ARGS`, inherited leader `--model`, then low-complexity default from `OMX_DEFAULT_SPARK_MODEL` (legacy alias: `OMX_SPARK_MODEL`). Normalize model flags to one canonical `--model <value>` entry and use `OMX_DEFAULT_FRONTIER_MODEL` / `OMX_DEFAULT_SPARK_MODEL` rather than guessing defaults.\n</team_model_resolution>\n\n<!-- OMX:MODELS:START -->\n<!-- Auto-generated by omx setup -->\n<!-- OMX:MODELS:END -->\n\n<verification>\nVerify before claiming completion.\n<!-- OMX:GUIDANCE:VERIFYSEQ:START -->\nVerification loop: define the claim and success criteria, run the smallest validation that can prove it, read the output, then report with evidence. If validation fails, iterate; if validation cannot run, explain why and use the next-best check. Keep evidence summaries concise but sufficient.\n\n- Run dependent tasks sequentially; verify prerequisites before starting downstream actions.\n- If a task update changes only the current branch of work, apply it locally and continue without reinterpreting unrelated standing instructions.\n- For coding work, prefer targeted tests for changed behavior, then typecheck/lint/build/smoke checks when applicable; do not claim completion without fresh evidence or an explicit validation gap.\n- When correctness depends on retrieval, diagnostics, tests, or other tools, continue only until the task is grounded and verified; avoid extra loops that only improve phrasing or gather nonessential evidence.\n<!-- OMX:GUIDANCE:VERIFYSEQ:END -->\n</verification>\n\n<execution_protocols>\nMode selection: follow `<delegation_rules>` above. Switch lanes only for a concrete unresolved ambiguity, coordination need, or blocker.\n\nCommand routing: use normal Codex repository inspection tools/subagents as the default surface for simple read-only repository lookup tasks; use `omx sparkshell` only for explicit shell-native read-only evidence or bounded verification.\nWhen to use what:\n- Use normal Codex repository inspection tools/subagents for repository lookup and implementation context.\n- Use `omx sparkshell --tmux-pane` only as an explicit opt-in operator aid for shell-native tmux evidence or bounded verification; it does not replace raw evidence capture.\n\nSupervisor tmux handoff safety:\n- Never paste from tmux's implicit/current buffer. Load handoff text into a fresh named buffer with `tmux set-buffer -b <name> -- \"$message\"` or a temp-file-backed `tmux load-buffer -b <name> <file>`; never use `tmux load-buffer -- <message>`.\n- Verify the named buffer with `tmux show-buffer -b <name>` before any paste. A failed load or mismatched buffer is a blocker; do not run `paste-buffer` or submit keys after it.\n- Clear the pane composer with `tmux send-keys -t <pane> C-u` immediately before paste, then use bracketed paste (`tmux paste-buffer -t <pane> -b <name> -p -d`) and submit intentionally.\n- Recapture the pane after paste/Enter and verify the intended turn was accepted rather than leaving stale draft text visible.\n\nLeader vs worker: leaders choose mode, delegate bounded work, integrate, and own verification; workers execute their slice and escalate blockers, scope expansion, shared-file conflicts, or mode mismatch upward. Escalate from worker to leader for blockers, scope expansion, shared ownership conflicts, or mode mismatch.\n\nStop / escalate: stop when the task is verified complete, the user says stop/cancel, or no meaningful recovery path remains. Escalate to the user only for irreversible, destructive, materially branching decisions, or missing authority.\n\nOutput contract: Default update/final shape: state current mode, action/result, and evidence or blocker/next step. Keep rationale once; do not restate the full plan every turn; expand only for risk, handoff, or explicit request.\n\nAnti-slop workflow:\n- Cleanup/refactor/deslop work follows the same lightweight workflow (`understand -> execute -> verify -> report`); use `$ai-slop-cleaner` as a bounded helper inside the chosen execution lane, not as a competing top-level workflow.\n- Write a cleanup plan before modifying code; lock existing behavior with regression tests first, then make one smell-focused pass at a time.\n- Prefer deletion over addition, and prefer reuse plus boundary repair over new layers.\n- No new dependencies without explicit request.\n- Run lint, typecheck, tests, and static analysis before claiming completion.\n- Keep writer/reviewer pass separation for cleanup plans and approvals; preserve writer/reviewer pass separation explicitly.\n\nContinuation: before concluding, confirm no pending work remains, features work, tests pass or gaps are explicit, and verification evidence is collected. If not, continue.\n</execution_protocols>\n\n<cancellation>\nUse the `cancel` skill to end active execution modes when work is done and verified, when the user says stop, or when a hard blocker prevents meaningful progress. Do not cancel while recoverable work remains.\n</cancellation>\n\n<state_management>\nSee [Durable Runtime Invariants](#durable-runtime-invariants-canonical-ssot) for state ownership and hook boundaries. OMX runtime state lives under `.omx/`.\n</state_management>\n\n## Durable Runtime Invariants (canonical SSOT)\n\nThis section is the single source of truth for durable state ownership, hook boundaries, cancellation, and Team coordination. Skills and role prompts reference it; they must not restate or weaken these rules.\n\n### State and hook ownership\n\n- Durable state is authoritative only in the current, proven session or Team scope. Compatibility discovery is read-only and never grants write authority.\n- Hooks own normal skill activation and workflow-state persistence under `.omx/state/`; skills do not duplicate or mutate hook-owned state except through documented recovery paths.\n- Native hook payloads, prompt labels, task text, cwd, environment, pointers, transcripts, markers, and local trackers are routing or diagnostic data, not ownership or write authority.\n- The Team state files and `omx team api ... --json` are the source of truth for task lifecycle and mailbox coordination.\n\n### Cancellation boundary\n\n- Cancellation parses and validates arguments before mutation, resolves one exact writable scope, freezes and revalidates target identity, mutates only proven targets, and leaves unrelated sessions, legacy roots, Team artifacts, and tmux sessions untouched.\n- Ralph cancellation must satisfy its documented terminal post-conditions in the same scope; linked modes are handled only when the link is proven.\n- `--force` does not widen cancellation scope; it only removes the selected exact-session native-stop entry after the same authority checks. `--all` is unsupported.\n- Team cancellation requires exact frozen Team root, internal name, session, leader pane, and runtime identity. It fails closed when that proof is unavailable or changes; it must not enumerate or broadly kill Team sessions or recursively delete unrelated Team state.\n\n### Team protocol\n\n- Team runtime is explicit and outside the default workflow. Ultragoal does not auto-launch Team, and ordinary workflows do not silently become Team runs.\n- Workers ACK startup, claim before work, transition task status through the lifecycle API, use release only for rollback, and report verification evidence. Leaders own integration, final verification, and shutdown decisions.\n- Prefer durable state writes and `omx team api ... --json` dispatch. Direct `tmux send-keys` is fallback-only, never primary dispatch; manual pane actions require prior state/evidence checks.\n- Team shutdown waits for terminal task state and uses exact Team authority. It does not shut down active work unless explicitly aborting.\n\n### Ultragoal ownership\n\n- `.omx/ultragoal/goals.json` is the leader-owned plan and `.omx/ultragoal/ledger.jsonl` is its durable audit trail. Workers report task evidence only; they do not create worker ledgers, mutate Ultragoal artifacts, or checkpoint goals.\n- Shell commands and hooks do not mutate hidden Codex goal state. The active agent uses `get_goal`, `create_goal`, and `update_goal` only at the documented gates, then checkpoints with a fresh `get_goal` snapshot.\n\n## Setup\n\nExecute `omx setup` to install all components. Execute `omx doctor` to verify installation.\n\n<!-- File: plugins/oh-my-codex/skills/ai-slop-cleaner/SKILL.md (Tokens: ~1015 | Category: anthropic-skill) -->\n---\nname: ai-slop-cleaner\ndescription: Run an anti-slop cleanup/refactor/deslop workflow\n---\n\n# AI Slop Cleaner Task Card\n\nUse this bounded helper for cleanup/refactor/deslop work, not as a competing top-level\nworkflow. Shared operating invariants live in `templates/AGENTS.md`; this card defines\nscope, smell taxonomy, passes, and evidence.\n\n## When to use and inputs\n\nUse when working code is bloated, noisy, repetitive, over-abstracted, or AI-generated;\nthe user requests cleanup/refactor/deslop; or a follow-up left duplicate/dead code,\nweak boundaries, missing tests, fallback-like paths, or wrappers. Inputs are the requested\nfeature/files and behavior to preserve. A file list scope is valid; keep the pass bounded\nto it. Limit the pass to the calling task's changed files unless broader cleanup was requested.\n\n## Before editing\n\n1. **Lock behavior with regression tests first**: identify behavior to preserve, run/add the narrowest targeted tests, and cover both primary and preserved compatibility/fail-safe fallback paths.\n2. **Create a cleanup plan before code**: list scope and smells, include fallback findings/classifications/escalation, and order safest/highest-signal fixes first.\n3. **Inventory fallback-like code** in scope: quick hacks, temporary workaround, temporary fallback, just bypass, just skip, fallback if it fails, swallowed errors, silent defaults, broad compatibility shims, and duplicate alternate execution paths.\n4. Classify each fallback: **Masking fallback slop** hides evidence, bypasses the contract, suppresses validation, swallows failures, silently defaults, or adds untested paths; **Grounded compatibility/fail-safe fallback** is narrow at an external/version/fail-safe boundary, documents rationale, preserves failure evidence, and tests primary plus fallback.\n5. Prefer root-cause repair, deletion, boundary repair, or explicit failure behavior. For broad/ambiguous/cross-layer/architectural findings, invoke `$ralplan` for consensus resolution; when already inside ralplan, ultragoal, team, or another OMX workflow, do not spawn a nested `$ralplan`—attach the finding to the active handoff.\n\n## Smell taxonomy and passes\n\nClassify before changing:\n\n- **Fallback-like code**: masking fallbacks, workaround branches, bypasses, swallowed errors, silent defaults, broad shims, alternate paths.\n- **Duplication**: repeated logic, copy-paste branches, redundant helpers.\n- **Dead code**: unused/unreachable code, stale flags, debug leftovers.\n- **Needless abstraction**: pass-through wrappers, speculative indirection, single-use layers.\n- **Boundary violations**: hidden coupling, leaky responsibilities, wrong-layer imports/side effects.\n- **Missing tests**: behavior not locked or edge cases uncovered.\n- **UI/design slop**: context-sensitive signals, not absolute bans; preserve intentional brand, design-system, accessibility, or product-context exceptions. Challenge Korean body text at 11-12px (generally 14px or larger); gratuitous box shadows; repetitive eyebrow + title + description + paragraph stacks and generic emoji badges; default AI blue/purple such as `#3B82F6`; reflexive 3-column or 4-column grids; and extreme gradients unless justified by context.\n\nResolve the fallback-like code resolution gate first, then one smell at a time:\n**Pass 1: Dead code deletion**; **Pass 2: Duplicate removal**; **Pass 3: Naming/error\nhandling cleanup**; **Pass 4: Test reinforcement**. Re-run targeted verification after\neach pass and avoid unrelated refactors. Prefer deletion/existing utilities; no new\nabstractions or dependencies unless explicitly required.\n\n## Evidence/output contract\n\nReport:\n\n```text\nAI SLOP CLEANUP REPORT\nScope: [files/feature]\nBehavior Lock: [targeted tests added/run]\nCleanup Plan: [bounded smells/order]\nFallback Findings: [finding -> masking fallback slop | grounded compatibility/fail-safe fallback -> escalation]\nUI/Design Findings: [none/N/A or signal -> action/defer -> intentional rationale]\nPasses Completed: [resolution gate; Passes 1-4]\nQuality Gates: Regression tests, Lint, Typecheck, Tests, Static/security scan (PASS/FAIL/N/A)\nChanged Files: [path -> simplification]\nRemaining Risks: [none or deferred item]\n```\n\nInclude changed files, simplifications, fallback classifications/escalation status,\ntests/diagnostics/build checks run, UI findings when relevant, and deferred risks. Keep\nwriter/reviewer separation for cleanup plans and approvals.\n\n## Exit condition\n\nStop when the requested scope has behavior-lock evidence, each selected smell pass is\ncomplete or explicitly deferred with rationale, verification is reported, and no\nunrelated files or temporary artifacts remain. Never present an unverified cleanup as\ncomplete; escalate a real architectural blocker rather than masking it.\n\n<!-- File: plugins/oh-my-codex/skills/analyze/SKILL.md (Tokens: ~643 | Category: anthropic-skill) -->\n---\nname: analyze\ndescription: \"Run read-only deep repository analysis and return a ranked synthesis with explicit confidence, concrete file references, and clear evidence-vs-inference boundaries. Use when a user says 'analyze', 'investigate', 'why does', 'what's causing', or needs grounded cross-file explanation before any changes are proposed.\"\n---\n\n# Analyze — Read-Only Deep Analysis\n\nUse `$analyze` to answer a repository question with grounded, read-only evidence. Explain what the code most likely says; do not turn analysis into implementation or generic fix planning.\n\nShared operating, delegation, state, hook, team, cancellation, and verification invariants live in [`templates/AGENTS.md`](../../templates/AGENTS.md). Follow that source instead of duplicating its rules here.\n\n## Use when\n\n- The user needs a causal, architectural, behavioral, impact, or tradeoff explanation.\n- The answer requires tracing multiple files or boundaries, or ranking plausible explanations.\n- The user needs confidence and concrete evidence before changing anything.\n\nDo not use it for edits, implementation, a new product plan, a simple one-file lookup, or OMX team-runtime operation.\n\n## Inputs and method\n\n1. Restate the question and define the evidence-backed scope.\n2. Identify the smallest files, tests, configs, and docs likely to answer it.\n3. Read direct code paths and contracts first; trace boundaries only as far as needed.\n4. Compare competing explanations, rank them by support, and mark unresolved points.\n5. Stop when the question is answered with sufficient evidence, or name the smallest read-only probe that would resolve the remaining uncertainty.\n\n## Evidence discipline\n\nLabel every material claim as one of:\n\n- **Evidence** — directly shown by code, tests, generated artifacts, configuration, or docs.\n- **Inference** — a reasoned conclusion drawn from cited evidence.\n- **Unknown** — not settled by the repository evidence.\n\nPrefer direct paths and independent corroboration over contextual clues. Never present guesses as evidence or inference, and never overclaim certainty.\n\n## Output contract\n\nAnswer the asked question first and use this shape:\n\n### Question\nRestated question, briefly.\n\n### Ranked synthesis\n| Rank | Explanation | Confidence | Basis |\n|------|-------------|------------|-------|\n| 1 | ... | High / Medium / Low | strongest supporting evidence |\n| 2 | ... | High / Medium / Low | why it trails |\n| 3 | ... | High / Medium / Low | why it remains possible |\n\n### Evidence\n- `path/to/file:line-line` — direct observation.\n- `path/to/file:line-line` — corroborating observation.\n\n### Inference\n- What the evidence most strongly implies.\n- Why weaker alternatives were down-ranked.\n\n### Unknowns / limits\n- What the repository does not establish.\n- The next discriminating read-only probe, when useful.\n\n## Stop conditions\n\n- Do not edit files, run an implementation lane, or make recommendations the evidence cannot support.\n- Do not continue searching after the answer and confidence boundary are grounded.\n- If evidence is insufficient, report the limit explicitly rather than manufacturing certainty.\n\nTask: {{ARGUMENTS}}\n\n<!-- File: plugins/oh-my-codex/skills/ask/SKILL.md (Tokens: ~386 | Category: anthropic-skill) -->\n---\nname: ask\ndescription: Ask a local external advisor CLI (Claude or Gemini) and capture a reusable artifact\n---\n\n# Ask (Local Advisor CLI)\n\nUse a locally installed external advisor CLI for focused questions, reviews, brainstorming, or second opinions. This skill replaces the separate `ask-claude` and `ask-gemini` skills.\n\n## Usage\n\n```bash\n$ask claude <question or task>\n$ask gemini <question or task>\nomx ask claude \"<question or task>\"\nomx ask gemini \"<question or task>\"\n```\n\n## Backend selection\n\n- Use `claude` when the user asks for Claude, Anthropic, or the previous `$ask-claude` behavior.\n- Use `gemini` when the user asks for Gemini or the previous `$ask-gemini` behavior.\n- If no backend is specified, choose the installed backend that best matches the user request; if neither is clearly available, explain that a local CLI is required.\n\n## Local CLI commands\n\nClaude:\n\n```bash\nomx ask claude \"{{ARGUMENTS}}\"\nclaude -p \"{{ARGUMENTS}}\"\n```\n\nGemini:\n\n```bash\nomx ask gemini \"{{ARGUMENTS}}\"\ngemini -p \"{{ARGUMENTS}}\"\n```\n\nIf needed, adapt to the user's installed CLI variant while keeping local execution as the default path. Do not silently switch to an MCP or remote provider when the local binary is missing.\n\n## Artifact requirement\n\nAfter local execution, save a markdown artifact to:\n\n```text\n.omx/artifacts/ask-<backend>-<slug>-<timestamp>.md\n```\n\nMinimum artifact sections:\n1. Original user task\n2. Backend and final prompt sent to the CLI\n3. Raw CLI output\n4. Concise summary\n5. Action items / next steps\n\nTask: {{ARGUMENTS}}\n\n<!-- File: plugins/oh-my-codex/skills/autopilot/SKILL.md (Tokens: ~1735 | Category: anthropic-skill) -->\n---\nname: autopilot\ndescription: \"[OMX] Canonical autonomous orchestrator: $deep-interview -> $ralplan -> $ultragoal\"\n---\n\n# Autopilot\n\n<Purpose>\nAutopilot is the first-class canonical orchestrator for hands-off delivery. Its defining default chain is mandatory:\n\n```text\n$deep-interview -> $ralplan -> $ultragoal\n```\n\nThe chain is not a list of optional hints and Autopilot is not an alias for direct execution. Autopilot supervises each child stage in one recoverable session, carries durable artifacts forward, and continues through implementation verification until the requested outcome is complete or a genuine blocker is recorded.\n</Purpose>\n\n<Use_When>\n- The user explicitly invokes `$autopilot`.\n- The user asks for end-to-end autonomous delivery from an idea, issue, or requirements seed.\n- The work needs requirements clarification, consensus planning, durable execution, and evidence-backed completion as one supervised workflow.\n</Use_When>\n\n<Default_Chain>\nRun or resume these stages in order:\n\n1. **`deep-interview`** — clarify intent, scope, non-goals, constraints, acceptance criteria, and unresolved decisions. Produce a durable requirements/specification handoff. Deep Interview is a real stage; do not replace it with a one-question check or skip it merely because the task looks actionable.\n2. **`ralplan`** — turn the clarified requirements into an execution-ready consensus plan with architecture, sequencing, test, and verification guidance. Preserve review evidence as lifecycle evidence, not host-issued security authority.\n3. **`ultragoal`** — execute the approved plan through durable goals and ledger receipts, implementation, focused verification, cleanup, review, and terminal evidence.\n\n`$team`, `$code-review`, and `$ultraqa` may be used inside the supervised execution when the active Ultragoal plan or verification boundary requires them. They do not replace or weaken the defining three-stage chain.\n\nWhen review or QA proves the requirements or plan wrong, keep Autopilot active, return its supervised phase to `ralplan`, attach the findings, and continue through `ultragoal` again. Implementation-only review fixes may remain within Ultragoal's blocker/review loop.\n</Default_Chain>\n\n<Execution_Policy>\n- Autopilot MUST begin at `deep-interview` for a new run and MUST preserve the phase order `deep-interview -> ralplan -> ultragoal`.\n- Child stages are supervised phases, not peer workflow activations. Keep `mode:\"autopilot\"` active and update `current_phase` rather than replacing Autopilot with standalone child state.\n- Use the current CLI state SSOT (`omx state ... --json`) and the current session-scoped state root. Do not create a second writer or revive legacy root-state authority.\n- Local artifacts, prompts, trackers, transcripts, environment values, and role labels are lifecycle evidence only. Do not reintroduce the retired unrecoverable host-receipt lock or terminalize the workflow because host provenance is unavailable.\n- Authority-decreasing operations are always recoverable: `$cancel`, state clear, hook disable/uninstall recovery, and stale-state repair must remain available without completion receipts or child-stage approval.\n- Continue automatically through safe, reversible stage transitions. Stop only for an explicit user cancellation, a human-only dependency, or a verified terminal result.\n</Execution_Policy>\n\n<State_Management>\nAutopilot state is session-scoped and owned by the canonical state writer. A new run records at least:\n\n```json\n{\n \"mode\": \"autopilot\",\n \"active\": true,\n \"current_phase\": \"deep-interview\",\n \"iteration\": 1,\n \"phase_cycle\": [\"deep-interview\", \"ralplan\", \"ultragoal\"],\n \"handoff_artifacts\": {\n \"deep_interview\": null,\n \"ralplan\": null,\n \"ultragoal\": null\n },\n \"return_to_ralplan_reason\": null\n}\n```\n\nStart or update state only through the CLI-first state surface:\n\n```bash\nomx state write --input '{\"mode\":\"autopilot\",\"active\":true,\"current_phase\":\"deep-interview\",\"state\":{\"phase_cycle\":[\"deep-interview\",\"ralplan\",\"ultragoal\"],\"handoff_artifacts\":{\"deep_interview\":null,\"ralplan\":null,\"ultragoal\":null},\"return_to_ralplan_reason\":null}}' --json\n```\n\nStage transitions:\n\n- **`deep-interview -> ralplan`**: require a durable clarified requirements/specification artifact and a non-empty completion rationale. Preserve same-session question evidence when a question surface was used.\n- **`ralplan -> ultragoal`**: require durable planning artifacts, sequential Architect then Critic approvals, and a session/review-cycle-bound `ralplan_execution_handoff`. For supervised Autopilot, the explicit Autopilot request is the source of that bound handoff. Ordinary progression MUST NOT depend on a host-issued consensus receipt; missing host provenance is not a blocker.\n- **`ultragoal -> complete`**: require durable goal/ledger completion receipts and fresh verification evidence matching the requested outcome.\n- **review/QA loopback**: keep Autopilot active, set `current_phase:\"ralplan\"`, and persist `return_to_ralplan_reason` plus the findings.\n- **cancellation**: run `$cancel`; preserve handoff artifacts for inspection or resume and mark the exact session terminal without deleting unrelated state.\n- **clear/recovery**: exact-session clear may remove corrupt or stale Autopilot state. It must not require forward-progression evidence and must not clear other skills or sessions.\n</State_Management>\n\n<Continuation_And_Resume>\nWhen the user says `continue`, `resume`, or `keep going`, read the current session's `autopilot-state.json` and continue from `current_phase`:\n\n- `deep-interview`: resume clarification and produce the requirements handoff.\n- `ralplan`: resume consensus planning from the deep-interview artifact and any loopback findings.\n- `ultragoal`: resume durable execution from the approved plan and ledger.\n- `complete`: report the terminal evidence; do not restart.\n- `cancelled`, `cleared`, or `failed`: report preserved artifacts and start a new run only on a new explicit Autopilot request.\n\nNever discard valid handoff artifacts or restart discovery merely because the conversation resumed.\n</Continuation_And_Resume>\n\n<Recovery_Contract>\nAutopilot continuation hooks may nudge an active non-terminal run, but they MUST fail open for recovery:\n\n- A stale, malformed, cancelled, cleared, complete, or foreign-session state must not keep Stop blocked.\n- `$cancel`, exact-session state clear, and setup hook disable/uninstall paths must remain executable while Autopilot is active or damaged.\n- Continuation must be bounded and session-scoped; never recreate an unconditional hook lock.\n</Recovery_Contract>\n\n<Final_Checklist>\n- [ ] A new run started with `deep-interview`.\n- [ ] Deep Interview produced a durable clarified requirements/specification handoff.\n- [ ] Ralplan produced an execution-ready plan with lifecycle review evidence.\n- [ ] Ultragoal completed the plan with durable goals and ledger receipts.\n- [ ] Verification evidence covers the requested behavior, failure paths, and recovery paths.\n- [ ] Missing host provenance did not block ordinary progression, cancel, clear, or hook recovery.\n- [ ] Autopilot state is terminal and exact-session artifacts remain coherent.\n</Final_Checklist>\n\n<Examples>\n<Good>\nUser: `$autopilot implement issue #42`\nFlow: activate Autopilot at `deep-interview`, crystallize requirements, continue to supervised `ralplan`, then supervised `ultragoal`, verify the completed outcome, and mark the exact session complete.\n</Good>\n\n<Good>\nUser: `continue`\nContext: Autopilot state has `current_phase:\"ralplan\"`.\nFlow: resume the existing plan from the deep-interview handoff; do not create a separate standalone Ralplan run.\n</Good>\n\n<Bad>\nFlow: treat `$deep-interview`, `$ralplan`, and `$ultragoal` as optional suggestions and jump directly to implementation.\nWhy bad: this hollows out Autopilot's defining orchestration contract.\n</Bad>\n</Examples>\n\nTask: {{ARGUMENTS}}\n\n<!-- File: plugins/oh-my-codex/skills/autoresearch/SKILL.md (Tokens: ~708 | Category: anthropic-skill) -->\n---\nname: autoresearch\ndescription: Stateful validator-gated research loop with native-hook persistence\n---\n\n# Autoresearch\n\nAutoresearch is the skill-first replacement for the deprecated `omx autoresearch` command.\nIt keeps the useful measured-research loop, but it now runs as a native-hook stateful workflow instead of a direct CLI or tmux launch surface.\n\n## Boundary with planning research\n\nUse `$autoresearch` when the research output itself is a bounded deliverable that must pass an explicit validator. Do not recommend it for ordinary pre-planning docs lookup or general best-practice checks; use `$best-practice-research` for that. If `$autoresearch` is intentionally run before architecture planning, its approved artifact should feed evidence into `$ralplan`; it should not become a final architecture/component unless the user explicitly asks for ongoing research automation.\n\n## Use when\n- You want a Ralph-ish persistent research loop\n- The task should keep nudging until explicit validation evidence exists\n- You want init-time choice between script validation and prompt+architect validation\n\n## Do not use when\n- You want the old `omx autoresearch` command surface (hard-deprecated)\n- You want detached tmux or split-pane launch parity\n- You have not decided the validation regime yet\n\n## Core contract\n1. **Init chooses validation mode.** Pick exactly one:\n - `mission-validator-script`\n - `prompt-architect-artifact`\n2. **Persist mode state** in `.omx/state/.../autoresearch-state.json` including:\n - `validation_mode`\n - `completion_artifact_path`\n - `mission_validator_command` **or** `validator_prompt`\n - optional `output_artifact_path`\n3. **Completion is artifact-gated.** The loop does not stop because the model says “done”, because a stop hook fired once, or because several turns were no-ops.\n4. **Direct CLI launch is gone.** Use `$deep-interview --autoresearch` for intake and `$autoresearch` for execution.\n\n## Completion artifact contract\n\n### `mission-validator-script`\nThe completion artifact must exist and record a passing validator result, for example:\n\n```json\n{\n \"status\": \"passed\",\n \"passed\": true,\n \"summary\": \"metric improved beyond baseline\"\n}\n```\n\n### `prompt-architect-artifact`\nThe completion artifact must include both an architect approval verdict and an output artifact path, for example:\n\n```json\n{\n \"validator_prompt\": \"Review the research output against the mission.\",\n \"architect_review\": { \"verdict\": \"approved\" },\n \"output_artifact_path\": \".omx/specs/autoresearch-demo/report.md\"\n}\n```\n\n## Recommended flow\n1. Run `$deep-interview --autoresearch` to clarify mission + evaluator.\n2. Materialize `.omx/specs/autoresearch-{slug}/mission.md`, `sandbox.md`, and `result.json`.\n3. Start `$autoresearch` with the chosen validation mode stored in mode state.\n4. Let stop-hook / auto-nudge continue until the completion artifact satisfies the chosen validation mode.\n5. Finish only after the validator artifact is complete.\n\n## Migration note\n- `omx autoresearch` is hard-deprecated.\n- No direct CLI launch.\n- No tmux split-pane launch.\n- No noop-count completion gate.\n\n<!-- File: plugins/oh-my-codex/skills/best-practice-research/SKILL.md (Tokens: ~1085 | Category: anthropic-skill) -->\n---\nname: best-practice-research\ndescription: \"[OMX] Bounded best-practice research wrapper using official/upstream evidence first\"\nargument-hint: \"<technology|decision|practice question>\"\n---\n\n# Best-Practice Research\n\nUse this skill when a task depends on current external best practices, version-aware guidance, standards, official recommendations, or upstream behavior. This is a workflow wrapper: it routes evidence gathering and synthesis; it is not a new research authority and it does not replace `researcher`.\n\n## Purpose\n\nProduce a cited, reusable best-practice answer or handoff that separates current external evidence from repo-local facts and dependency-selection decisions. For pre-planning investigation, this is the ordinary first research wrapper: gather official/upstream evidence, then hand it to `$ralplan` or the caller as planning input. Do not present `$best-practice-research` as a final architecture component or as a validator-gated research loop.\n\n## Terminal By Default\n\nThis skill is terminal and read-only by default. It gathers evidence and produces a cited recommendation with a handoff, then stops. Do not write or edit files, create or amend commits, run mutating commands, or otherwise modify repository state under this skill — even when the question has clear implementation implications. When implementation is warranted, stop and hand off rather than continuing: name `$ralplan` for planning and `$ultragoal`, `$team`, or `executor` for execution, and resume only after the user explicitly switches to that workflow.\n\n## Activate When\n\n- The user asks for best practices, recommended approach, current guidance, official recommendations, standards, or version-aware external behavior.\n- `$ralplan`, `$deep-interview`, `$team`, or another workflow needs current external evidence before planning or execution can be correct.\n- The task involves an already chosen technology and needs authoritative usage guidance, migration notes, API behavior, lifecycle rules, or current safety guidance.\n\n## Do Not Activate When\n\n- The answer is fully repo-local; use `explore` for codebase facts.\n- The main question is whether to adopt, replace, upgrade, or compare dependencies; use `dependency-expert`.\n- The user only needs implementation against already-grounded requirements; execute directly, or use `$team` when coordinated parallel work is warranted.\n- The task can be answered from stable local project conventions without current external lookup.\n\n## Specialist Routing\n\n1. Use `explore` first for brownfield facts: current code usage, local constraints, versions, config, and integration points.\n2. Use `researcher` for official/upstream docs, release notes, standards, migration guides, source-backed examples, and current best-practice evidence for an already chosen technology.\n3. Use `dependency-expert` only for adoption/upgrade/replacement/comparison decisions.\n4. Return to the caller with explicit evidence, uncertainty, and any implementation handoff constraints.\n\n## Source-Quality Rules\n\n- Prefer official documentation, upstream source, release notes, changelogs, standards, and maintainer guidance.\n- Include source URLs for material claims.\n- State date/version context for current best-practice claims.\n- Label third-party summaries as supplemental; do not use them before official/upstream sources.\n- Flag stale, conflicting, undocumented, or version-mismatched evidence.\n- Do not over-fetch: gather the smallest evidence set that can support the decision.\n\n## Workflow\n\n1. Classify the question: conceptual best practice, implementation guidance, migration/version guidance, standards/compliance guidance, or mixed local + external guidance.\n2. Gather repo-local facts with `explore` when local usage or constraints affect the answer.\n3. Gather external evidence with `researcher` when current or version-aware practice affects correctness.\n4. Synthesize a concise answer with source quality, version/date context, caveats, and an implementation or planning handoff.\n5. Stop when the answer is grounded enough for the caller; otherwise report the exact blocker or specialist handoff needed.\n\n## Output Contract\n\n```md\n## Best-Practice Research: <question>\n\n### Direct Recommendation\n<actionable guidance or decision support>\n\n### Evidence Used\n- Official/upstream: <source URL> — <what it establishes>\n- Supplemental, if any: <source URL> — <why it is secondary>\n\n### Version / Date Context\n<versions, dates, release channels, or unknowns>\n\n### Repo-Local Context\n<facts from explore, or \"not needed\">\n\n### Boundaries / Non-goals\n<what this research does not decide>\n\n### Handoff\n<planning/execution/test implications; name the next workflow — `$ralplan` for planning, `$ultragoal`/`$team`/`executor` for execution — and note that this skill stops here unless the user explicitly switches workflows>\n```\n\n## Stop Rules\n\n- Stop after a source-backed recommendation is reusable by the caller.\n- Stop and route upward if the task becomes dependency comparison, broad architecture, or implementation.\n- Do not continue researching when remaining work would only polish wording rather than change the recommendation.\n- This skill never implements. After delivering the recommendation and handoff, stop; do not modify repo files or repo state. Resume only when the user explicitly switches to a planning or implementation workflow named in the handoff.\n\nTask: {{ARGUMENTS}}\n\n<!-- File: plugins/oh-my-codex/skills/cancel/SKILL.md (Tokens: ~543 | Category: anthropic-skill) -->\n---\nname: cancel\ndescription: Cancel any active OMX mode (autopilot, ralph, ultrawork, ecomode, ultraqa, swarm, ultrapilot, pipeline, team)\n---\n\n# Cancel Skill\n\n## When to use\n\nUse `/cancel` (or `cancelomc` / `stopomc`) to stop an active OMX mode and perform its documented cleanup. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot` first; it is the invariant authority for scope, ownership, hooks, and Team cleanup.\n\n## Inputs and preconditions\n\n- Accepted forms are `/cancel` and `/cancel --force`.\n- Reject `--all`, unknown flags, repeated flags, and mixed flags before mutation.\n- Discover the current session/root with the state read surfaces before cleanup:\n ```bash\n omx state list-active --json\n omx state get-status --mode <mode> --json\n ```\n- Confirm the current session/root and exact target before cleanup; stop when the required evidence is missing.\n\n## Operational steps\n\n1. Parse and validate arguments; select one exact session/root scope.\n2. Inspect active modes in dependency order:\n `autopilot → ralph → ultrawork → ecomode → ultraqa → swarm → ultrapilot → pipeline → team → plan-consensus`.\n3. Cancel Autopilot while preserving its resumable state; clean only linked child modes it owns.\n4. For Ralph, terminalize the target state (`active:false`, `current_phase:\"cancelled\"`, `completed_at`) and terminalize a proven linked Ultrawork/Ecomode state in the same scope. Confirm the post-conditions in `docs/contracts/ralph-cancel-contract.md`.\n5. Clear standalone modes only after proving they are not linked to another active mode.\n6. For Team, inspect the runtime with `omx team status <team> --json`; use `omx team shutdown <team>` after the normal completion gate, or follow the explicit abort path.\n7. Clear only the selected mode/session state through the state API, for example:\n ```bash\n omx state clear --input '{\"mode\":\"<mode>\",\"session_id\":\"<session>\"}' --json\n ```\n8. With `--force`, perform its documented native-stop cleanup. Report rollback or cleanup failures rather than claiming success.\n\n## Exit and evidence\n\nReport one result per selected mode: mode, scope/session, terminal phase, preserved state, linked cleanup, and any refusal reason. A clean no-op reports `No active OMX modes detected.` Include Team status and shutdown evidence when Team was selected.\n\n<!-- File: plugins/oh-my-codex/skills/code-review/SKILL.md (Tokens: ~1289 | Category: anthropic-skill) -->\n---\nname: code-review\ndescription: Run a comprehensive code review\n---\n\n# Code Review Task Card\n\nUse this explicit opt-in for a merge-readiness review. Shared operating invariants\nlive in `templates/AGENTS.md`; this card only defines review-specific behavior.\n\n## When to use\n\n- The user asks for a code review or quality/security assessment.\n- A change is ready for review before merge, or a major feature needs an independent review.\n- Do not activate this card for implementation, broad planning, or automatic cleanup.\n\n## Inputs\n\n- Scope: the requested files, commit, PR, or whole diff.\n- Requirements/specification, acceptance criteria, and relevant test/CI evidence.\n- Existing review artifacts and known risks, if any.\n- If the user says `continue`, advance the current verified review step rather than restarting discovery.\n\nStart by recording the scope:\n\n```sh\ngit status --short\ngit diff --stat\ngit diff -- <scope>\n```\n\n## Execution\n\n1. Identify changed files and review boundaries; do not silently widen the scope.\n2. Launch the `code-reviewer` and `architect` agents in parallel. Both lanes run in parallel on a clean context with explicit scope and artifacts. If either lane cannot be launched or does not return evidence, report `independent review unavailable`; do **not** substitute the current/authoring lane, and do **not** approve or mark the review merge-ready.\n3. Respect the user's current model and reasoning/effort selection. Do not pass `model` or `reasoning_effort` overrides in review-lane calls.\n\n```text\ntask(\n agent_type=\"code-reviewer\",\n prompt=\"CODE REVIEW TASK\n\nReview the supplied scope for spec compliance, security, quality, performance, and maintainability.\nReturn files reviewed, severity-rated findings with file:line evidence and concrete fixes,\nand a recommendation: APPROVE / REQUEST CHANGES / COMMENT. Do not review architecture.\nScope: [scope and artifacts]\"\n)\n\ntask(\n agent_type=\"architect\",\n prompt=\"ARCHITECTURE / DEVIL'S-ADVOCATE REVIEW TASK\n\nReview the same scope for boundaries, interfaces, hidden coupling, long-term tradeoffs,\nand the strongest counterargument against approval. Return file:line evidence,\nrecommendations, and Architectural Status: CLEAR / WATCH / BLOCK.\nScope: [scope and artifacts]\"\n)\n```\n\n## Review taxonomy\n\n- `code-reviewer` checks **Security**, **Code Quality**, **Performance**, **Best Practices**, and **Maintainability**.\n- Rate each finding: **CRITICAL** (security or data-loss blocker), **HIGH** (bug/major smell), **MEDIUM** (important improvement), or **LOW** (style/suggestion).\n- `architect` checks explicit boundaries/interfaces, hidden coupling, long-horizon tradeoffs, and devil's-advocate concerns. Status is **CLEAR**, **WATCH** (non-blocking concern), or **BLOCK** (merge blocker).\n- Every finding names `file:line`, issue, risk, and a concrete fix; distinguish facts from suggestions.\n\n## State/HUD Phase Contract\n\n- Standalone `$code-review` relies on hook-owned `skill-active-state.json` (`skill:\"code-review\"`, `phase:\"planning\"`); do not create `code-review-state.json`.\n- Inside Autopilot, keep `mode:\"autopilot\"` active with `current_phase:\"code-review\"` / skill-active `phase:\"code-review\"`; do not activate a peer workflow.\n- On clean review, persist the artifact under Autopilot `handoff_artifacts.code_review` before moving to `ultraqa`. On non-clean review, persist findings and use `rework` or `ralplan` as appropriate.\n\n```sh\nomx state write --input '{\"mode\":\"autopilot\",\"active\":true,\"current_phase\":\"code-review\"}' --json\n```\n\n## Final Synthesis and gate\n\n### Architectural Status Contract\n\nCombine the `code-reviewer` recommendation and architect status. Approval requires explicit evidence from both independent lanes; missing or failed delegation is a blocking unavailable-review state, not an approval fallback. The final report must make architect blockers impossible to miss.\n\n- If architect status is **BLOCK**, final recommendation is **REQUEST CHANGES**.\n- Else if `code-reviewer` recommendation is **REQUEST CHANGES**, final recommendation is **REQUEST CHANGES**.\n- Else if architect status is **WATCH**, final recommendation is **COMMENT**.\n- Else final recommendation follows the `code-reviewer` lane.\n\nApproval criteria: **APPROVE** only when `code-reviewer` returns APPROVE, architect status is `CLEAR`, and both independent lanes returned evidence. **REQUEST CHANGES** for a blocker, unresolved high/critical finding, or unavailable lane. **COMMENT** may record non-blocking findings.\n\nDo not self-review as a fallback. If the `code-reviewer` or `architect` path is missing, unavailable, skipped, or fails, block approval until independent lane evidence exists. On the supported `omx ralph` CLI compatibility path, findings may trigger automatic fix follow-up without another permission prompt; plain `code-review` itself remains read-only and does **not** promise auto-fix.\n\n## Evidence/output contract\n\nReturn a concise report containing:\n\n```text\nCODE REVIEW REPORT\nFiles Reviewed: <count>\nTotal Issues: 0\nArchitectural Status: CLEAR | WATCH | BLOCK\nCRITICAL (0) | HIGH (0) | MEDIUM (0) | LOW (0)\nFindings: file:line -> issue, risk, concrete fix (or none)\nARCHITECTURE WATCHLIST: concern, status, recommendation (or none)\n- code-reviewer recommendation: COMMENT\n- architect status: WATCH\n- final recommendation: COMMENT\nRECOMMENDATION: COMMENT\n```\n\nReplace the illustrative counts and verdict with observed values. Include scope,\nlane evidence/artifact references, unresolved risks, and validation gaps.\n\n## Exit condition\n\nStop when the scoped diff has two independent lane results and a deterministic final\nrecommendation. Report `APPROVE` only under the approval criteria; otherwise leave a\nbounded `REQUEST CHANGES`, `COMMENT`, or unavailable-review result. Never claim\nmerge-ready without the required evidence.\n\n<!-- File: plugins/oh-my-codex/skills/configure-notifications/SKILL.md (Tokens: ~1808 | Category: anthropic-skill) -->\n---\nname: configure-notifications\ndescription: Configure OMX notifications - unified entry point for all platforms\ntriggers:\n - \"configure notifications\"\n - \"setup notifications\"\n - \"notification settings\"\n - \"configure discord\"\n - \"configure telegram\"\n - \"configure slack\"\n - \"configure openclaw\"\n - \"setup discord\"\n - \"setup telegram\"\n - \"setup slack\"\n - \"setup openclaw\"\n - \"discord notifications\"\n - \"telegram notifications\"\n - \"slack notifications\"\n - \"openclaw notifications\"\n - \"discord webhook\"\n - \"telegram bot\"\n - \"slack webhook\"\n---\n\n# Configure OMX Notifications\n\nUse this card for Discord, Telegram, Slack, generic command aliases, or OpenClaw. Shared safety, lifecycle, hook, team, autonomy, and cancellation rules live in `templates/AGENTS.md`.\n\n## 1. Inspect and choose a path\n\n```bash\nCONFIG_FILE=\"$HOME/.codex/.omx-config.json\"\nif [ -f \"$CONFIG_FILE\" ]; then\n jq -r '{notifications_enabled:(.notifications.enabled // false), discord:(.notifications.discord.enabled // false), discord_bot:(.notifications[\"discord-bot\"].enabled // false), telegram:(.notifications.telegram.enabled // false), slack:(.notifications.slack.enabled // false), openclaw:(.notifications.openclaw.enabled // false), custom_webhook_command:(.notifications.custom_webhook_command.enabled // false), custom_cli_command:(.notifications.custom_cli_command.enabled // false), verbosity:(.notifications.verbosity // \"session\"), idleCooldownSeconds:(.notifications.idleCooldownSeconds // 60), reply_enabled:(.notifications.reply.enabled // false)}' \"$CONFIG_FILE\"\nelse\n echo \"NO_CONFIG_FILE\"\nfi\n```\n\nUse AskUserQuestion to choose: Discord native (webhook or bot), Telegram native (bot token + chat id), Slack native (incoming webhook), `custom_webhook_command`, `custom_cli_command`, cross-cutting settings, or disable all notifications.\n\n## 2. Native providers\n\nCollect and validate provider values, then write only these native keys: `notifications.discord`, `notifications[\"discord-bot\"]`, `notifications.telegram`, or `notifications.slack`. Do not represent native providers with generic aliases.\n\n## 3. Generic aliases\n\nFor `custom_webhook_command`, collect URL, optional headers, method (`POST` default or `PUT`), events (`session-end`, `ask-user-question`, `session-start`, `session-idle`, `stop`), and an instruction template:\n\n```bash\njq --arg url \"$URL\" --arg method \"${METHOD:-POST}\" --arg instruction \"${INSTRUCTION:-OMX event {{event}} for {{projectPath}}}\" --argjson headers \"${HEADERS_JSON:-{}}\" '.notifications=(.notifications//{enabled:true})|.notifications.enabled=true|.notifications.custom_webhook_command={enabled:true,url:$url,headers:$headers,method:$method,instruction:$instruction,events:[\"session-end\",\"ask-user-question\"]}' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\nFor `custom_cli_command`, collect a command template (`{{event}}`, `{{instruction}}`, `{{sessionId}}`, `{{projectPath}}`), optional events, and an instruction template:\n\n```bash\njq --arg command \"$COMMAND_TEMPLATE\" --arg instruction \"${INSTRUCTION:-OMX event {{event}} for {{projectPath}}}\" '.notifications=(.notifications//{enabled:true})|.notifications.enabled=true|.notifications.custom_cli_command={enabled:true,command:$command,instruction:$instruction,events:[\"session-end\",\"ask-user-question\"]}' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\nOpenClaw dispatch requires `OMX_OPENCLAW=1`; command gateways additionally require `OMX_OPENCLAW_COMMAND=1`; timeout precedence is `gateways.<name>.timeout` > `OMX_OPENCLAW_COMMAND_TIMEOUT_MS` > `5000` ms.\n\n## 4. OpenClaw + Clawdbot agent mode\n\nUse this only when the requested route is a `clawdbot agent` turn delivered to Discord. The `session-stop` notification intentionally maps to the OpenClaw `stop` hook. OMX shell-escapes substitutions; keep instructions short, avoid untrusted shell metacharacters, append `|| true`, and append JSONL logs with `>>`.\n\n```bash\njq --arg command \"(clawdbot agent --session-id omx-hooks --message {{instruction}} --thinking minimal --deliver --reply-channel discord --reply-to 'channel:CHANNEL_ID' --timeout 120 --json >>/tmp/omx-openclaw-agent.jsonl 2>&1 || true)\" '.notifications=(.notifications//{enabled:true})|.notifications.enabled=true|.notifications.verbosity=\"verbose\"|.notifications.openclaw={enabled:true,gateways:{local:{type:\"command\",command:$command,timeout:120000}},hooks:{\"session-start\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-start project={{projectName}} session={{sessionId}} tmux={{tmuxSession}}. 한국어로 상태를 #omc-dev에 공유하고 SOUL.md를 참고하세요.\"},\"session-idle\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-idle session={{sessionId}} tmux={{tmuxSession}}. 한국어로 팔로업을 #omc-dev에 안내하세요.\"},\"ask-user-question\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=ask-user-question session={{sessionId}} tmux={{tmuxSession}} question={{question}}. 한국어로 응답 필요를 #omc-dev에 알리세요.\"},\"stop\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-stop session={{sessionId}} tmux={{tmuxSession}}. 한국어로 중단 상태를 전달하세요.\"},\"session-end\":{enabled:true,gateway:\"local\",instruction:\"OMX hook=session-end session={{sessionId}} tmux={{tmuxSession}} reason={{reason}}. 한국어로 완료 요약을 #omc-dev에 남기세요.\"}}}' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\n### Compatibility + precedence contract\n\nExplicit `notifications.openclaw` wins when valid; generic aliases are ignored with a warning.\n\nVerify this mode and inspect evidence without hiding output:\n\n```bash\nclawdbot agent --session-id omx-hooks --message \"OMX hook test via clawdbot agent path\" --thinking minimal --deliver --reply-channel discord --reply-to 'channel:CHANNEL_ID' --timeout 120 --json\ntmux list-sessions -F '#{session_name}' | rg '^omx-' || true\njq '.notifications.openclaw.hooks' \"$CONFIG_FILE\"\ntail -n 120 /tmp/omx-openclaw-agent.jsonl | jq -s '.[] | {timestamp:(.timestamp // .time),status:(.status // .error // \"ok\")}'\nrg '\"error\"|\"failed\"|\"timeout\"' /tmp/omx-openclaw-agent.jsonl | tail -20\n```\n\nFor HTTP integrations, run both a `/hooks/wake` smoke test and `/hooks/agent` delivery verification.\n\n## 5. Cross-cutting settings and disable\n\n- Verbosity: `minimal`, `session` (recommended), `agent`, or `verbose`.\n- Idle cooldown: `notifications.idleCooldownSeconds` (environment override: `OMX_IDLE_COOLDOWN_SECONDS`).\n- Profiles: `notifications.profiles` and `notifications.defaultProfile`.\n- Reply listener: `notifications.reply.enabled`; gates are `OMX_REPLY_ENABLED=true` and, for Discord, `OMX_REPLY_DISCORD_USER_IDS=...`. An authorized Discord bot operator may exact-match `status` on a tracked notification for a bounded read-only session summary.\n\nDisable all notifications:\n\n```bash\njq '.notifications.enabled=false' \"$CONFIG_FILE\" >\"$CONFIG_FILE.tmp\" && mv \"$CONFIG_FILE.tmp\" \"$CONFIG_FILE\"\n```\n\n## Exit evidence\n\nRun `jq empty \"$CONFIG_FILE\"` after edits. Report the config path, enabled native providers, enabled aliases, whether valid `notifications.openclaw` overrides aliases, verbosity, idle cooldown, reply-listener state, and smoke-test results. Stop when the JSON parses and the selected path has its required evidence; do not claim delivery from configuration alone.\n\n<!-- File: plugins/oh-my-codex/skills/deep-interview/SKILL.md (Tokens: ~9030 | Category: anthropic-skill) -->\n---\nname: deep-interview\ndescription: Socratic deep interview with mathematical ambiguity gating before execution\nargument-hint: \"[--quick|--standard|--deep] [--autoresearch] <idea or vague description>\"\n---\n\n<Purpose>\nDeep Interview is an intent-first Socratic clarification loop before planning or implementation. It turns vague ideas into execution-ready specifications by asking targeted questions about why the user wants a change, how far it should go, what should stay out of scope, and what OMX may decide without confirmation.\n</Purpose>\n\n<Use_When>\n- The request is broad, ambiguous, or missing concrete acceptance criteria\n- The user says \"deep interview\", \"interview me\", \"ask me everything\", \"don't assume\", or \"ouroboros\"\n- The user wants to avoid misaligned implementation from underspecified requirements\n- You need a requirements artifact before handing off to `ralplan`, `autopilot`, `ultragoal`, or `team`\n</Use_When>\n\n<Do_Not_Use_When>\n- The request already has concrete file/symbol targets and clear acceptance criteria\n- The user explicitly asks to skip planning/interview and execute immediately\n- The user asks for lightweight brainstorming only (use `plan` instead)\n- A complete PRD/plan already exists and execution should start\n</Do_Not_Use_When>\n\n<Why_This_Exists>\nExecution quality is usually bottlenecked by intent clarity, not just missing implementation detail. A single expansion pass often misses why the user wants a change, where the scope should stop, which tradeoffs are unacceptable, and which decisions still require user approval. This workflow applies Socratic pressure + quantitative ambiguity scoring so orchestration modes begin with an explicit, testable, intent-aligned spec.\n</Why_This_Exists>\n\n<Depth_Profiles>\n- **Quick (`--quick`)**: fast pre-PRD pass; target threshold `<= 0.30`; max rounds 5\n- **Standard (`--standard`, default)**: full requirement interview; target threshold `<= 0.20`; max rounds 12\n- **Deep (`--deep`)**: high-rigor exploration; target threshold `<= 0.15`; max rounds 20\n- **Autoresearch (`--autoresearch`)**: same interview rigor as Standard, but specialized for `$autoresearch` mission readiness and `.omx/specs/` artifact handoff\n\nProfile `max rounds` is a hard cap, not a target. Do not continue only to reach a numbered round count. Extra Socratic rigor does not override the active threshold unless the profile/config changes.\n\nIf no flag is provided, use **Standard**.\n\n<Mode_Flags>\n- **`--autoresearch`**: switch the interview into autoresearch-intake mode for `$autoresearch` handoff. In this mode, the interview should converge on a validator-ready research mission, write canonical artifacts under `.omx/specs/`, and preserve the explicit `refine further` vs `launch` boundary for downstream skill intake.\n</Mode_Flags>\n</Depth_Profiles>\n\n<Execution_Policy>\n- Ask ONE question per round (never batch multiple interview rounds into one `questions[]` form)\n- Ask about intent and boundaries before implementation detail\n- Target the weakest clarity dimension each round after applying the stage-priority rules below\n- Treat every answer as a claim to pressure-test before moving on: the next question should usually demand evidence or examples, expose a hidden assumption, force a tradeoff or boundary, or reframe root cause vs symptom\n- Do not rotate to a new clarity dimension just for coverage when the current answer is still vague; stay on the same thread until one layer deeper, one assumption clearer, or one boundary tighter\n- Before crystallizing, complete at least one explicit pressure pass that revisits an earlier answer with a deeper, assumption-focused, or tradeoff-focused follow-up\n- Gather codebase facts via `explore` before asking user about internals\n- `omx explore` is deprecated. Use normal repository inspection tools/subagents for simple read-only brownfield fact gathering; use `omx sparkshell` only for explicit shell-native read-only evidence, and keep ambiguous or non-shell-only investigation on the richer normal path.\n- Always run a preflight context intake before the first interview question\n- For brownfield work, preflight must include doc/context grounding before user-facing questions: inspect applicable `AGENTS.md` files, README/getting-started docs, relevant `docs/` contracts/plans/ADRs, existing `.omx/context/` snapshots, and any project-local glossary/context files such as `CONTEXT.md` or `CONTEXT-MAP.md` when present.\n- Treat existing repo language as evidence, not authority: if the user uses a fuzzy, overloaded, or conflicting term, surface the specific doc/code wording and ask which meaning should govern before implementation.\n- Cross-check user claims about current behavior against code or documented contracts when discoverable. If docs and code disagree, ask a confirmation question that names both sources instead of silently choosing one.\n- Use scenario-based edge-case grilling when relationships, boundaries, or handoff behavior are unclear: invent one concrete scenario that stresses the ambiguous boundary, then ask one focused question about the expected outcome.\n- Durable docs, glossary, ADR, or memory updates are opt-in and public-safe only. Deep-interview may recommend such updates in the handoff summary, but must not automatically create or dump public docs from interview transcripts unless the user explicitly chooses that as in-scope.\n- If initial context is oversized or would exceed the prompt budget, do not paste or forward the raw payload into interview prompts; request and record a prompt-safe initial-context summary first\n- The oversized initial-context summary gate is blocking: wait for the concise summary before ambiguity scoring, crystallizing artifacts, or any downstream execution handoff\n- The summary must preserve goals, constraints, success criteria, non-goals, decision boundaries, and references to any full source documents so downstream consumers receive a prompt-safe but faithful context\n- Keep total prompt payloads within a safe budget by summarizing or trimming retained history; preserve newest/highest-signal answers and never let raw oversized context crowd out the current question\n- Reduce user effort: ask only the highest-leverage unresolved question, and never ask the user for codebase facts that can be discovered directly\n- For brownfield work, prefer evidence-backed confirmation questions such as \"I found X in Y. Should this change follow that pattern?\"\n- Route facts before judgment in the Ouroboros style: before presenting a user-facing interview round, classify whether the needed information is a discoverable fact, a fact needing confirmation, or a human decision. The interview is with the human for judgment, not for facts the agent can inspect.\n- When unresolved ambiguity depends on current external best practices, official/upstream guidance, standards, or version-aware behavior, use `$best-practice-research` as the bounded evidence wrapper before crystallizing requirements or handing off to planning/execution.\n- Use these transcript/spec labels only; never use them as `omx question` `source` values, and never replace the runtime `source: \"deep-interview\"` contract for user-facing deep-interview questions:\n - `[from-code][auto-confirmed]` — exact, high-confidence codebase facts from manifests/configs or direct source evidence, with no prescription attached.\n - `[from-code]` — codebase findings that are useful but inferred, pattern-based, or low/medium confidence and therefore need a confirmation-style user-facing round before being treated as settled.\n - `[from-research]` — externally sourced facts such as API limits, compatibility, or public documentation; facts only, not decisions.\n - `[from-user]` — goals, preferences, business logic, scope, non-goals, acceptance criteria, tradeoffs, and any decision-bearing interpretation.\n- Treat `[from-code][auto-confirmed]` and other non-user fact discoveries as context/transcript updates, not interview rounds: do not call `omx question`, do not create a pending deep-interview question obligation, and do not increment the user-facing round number for facts the agent can safely establish.\n- Auto-confirm only descriptive facts. If a finding implies what the new feature should do, which pattern it should follow, which tradeoff to accept, or what should stay in/out of scope, route the entire decision-bearing question to the user as `[from-user]` even when code or research facts are available.\n- In attached-tmux Codex CLI, deep-interview uses `omx question` as the required OMX-owned structured questioning path for every interview round\n- When invoking `omx question` through attached-tmux Bash/tool paths, preserve the leader-pane return target by prefixing the command with `OMX_QUESTION_RETURN_PANE=$TMUX_PANE` (or a concrete `%pane` value)\n- If you launch `omx question` in a background terminal, immediately wait for that background terminal to finish and read its JSON answer before scoring ambiguity, asking another round, or handing off\n- Treat `answers[]` as the primary `omx question` success contract. For a single interview round, read `answers[0].answer`; use legacy top-level `answer` only as a compatibility fallback when needed.\n- If the current runtime is outside tmux and cannot render `omx question`, use the native structured question tool when available; otherwise ask exactly one concise plain-text question and wait for the answer\n- Re-score ambiguity after each answer and show progress transparently\n- Once ambiguity is at or below the active profile threshold, stop ordinary questioning. Run the practical closure audit: crystallize/handoff when readiness gates pass; otherwise ask only the final closure question needed to satisfy a named gate.\n- Treat `max_rounds` as a stop cap, not evidence that more rounds are needed.\n- Do not hand off to execution while ambiguity remains above threshold unless user explicitly opts to proceed with warning\n- Do not crystallize or hand off while `Non-goals` or `Decision Boundaries` remain unresolved, even if the weighted ambiguity threshold is met\n- Treat early exit as a safety valve, not the default success path\n- Persist mode state for resume safety only through the CLI/programmatic single-writer authority (`omx state write/read --input '<json>' --json`, backed by `src/state/operations.ts`). The MCP state server is a read-only projection and must never become a second writer.\n</Execution_Policy>\n\n<Steps>\n\n## Phase 0: Preflight Context Intake\n\n1. Parse `{{ARGUMENTS}}` and derive a short task slug.\n2. Attempt to load the latest relevant context snapshot from `.omx/context/{slug}-*.md`.\n3. Check whether the provided initial context or loaded snapshot is too large for safe prompt use. If it is oversized, the first interview round must ask for a concise prompt-safe summary instead of scoring ambiguity or continuing to downstream handoff.\n4. If no snapshot exists, create a minimum context snapshot with:\n - Task statement\n - Desired outcome\n - Stated solution (what the user asked for)\n - Probable intent hypothesis (why they likely want it)\n - Known facts/evidence\n - Constraints\n - Unknowns/open questions\n - Decision-boundary unknowns\n - Likely codebase touchpoints\n - Relevant repo docs/rules/context inspected\n - Terminology or doc/code conflicts found\n - Prompt-safe initial-context summary status (`not_needed`, `needed`, or `recorded`)\n5. For brownfield tasks, inspect the applicable documentation/rule surface before the first user-facing round. Prefer exact, nearby sources over broad scans:\n - governing `AGENTS.md` files and template/runtime instruction surfaces that apply to the touched paths\n - README/getting-started docs and relevant docs under `docs/`, especially contracts, plans, ADR-like records, and workflow docs\n - existing `.omx/context/` snapshots, `.omx/specs/`, and planning artifacts relevant to the slug\n - project-local glossary/context files such as `CONTEXT.md`, `CONTEXT-MAP.md`, or context-specific docs when they exist\n6. Save snapshot to `.omx/context/{slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`) and reference it in mode state.\n\n## Phase 1: Initialize\n\n1. Parse `{{ARGUMENTS}}` and depth profile (`--quick|--standard|--deep`).\n2. Detect project context:\n - Run `explore` to classify **brownfield** (existing codebase target) vs **greenfield**.\n - For brownfield, collect relevant codebase context before questioning.\n3. Initialize state via `omx state write --input '{\"mode\":\"deep-interview\",\"active\":true}' --json`:\n\n```json\n{\n \"active\": true,\n \"current_phase\": \"deep-interview\",\n \"state\": {\n \"interview_id\": \"<uuid>\",\n \"profile\": \"quick|standard|deep\",\n \"type\": \"greenfield|brownfield\",\n \"initial_idea\": \"<user input>\",\n \"rounds\": [],\n \"current_ambiguity\": 1.0,\n \"threshold\": 0.3,\n \"max_rounds\": 5,\n \"challenge_modes_used\": [],\n \"codebase_context\": null,\n \"current_stage\": \"intent-first\",\n \"current_focus\": \"intent\",\n \"context_snapshot_path\": \".omx/context/<slug>-<timestamp>.md\"\n }\n}\n```\n\n4. Announce kickoff with profile, threshold, and current ambiguity.\n\n## Phase 2: Socratic Interview Loop\n\nRepeat until ambiguity `<= threshold`, the pressure pass is complete, the readiness gates are explicit, the user exits with warning, or max rounds are reached. This is a stop condition: below threshold, do not open a new ordinary interview branch.\n\n### 2a) Generate next question\nIf the initial context is oversized and no prompt-safe summary has been recorded yet, the next question must be only a summary request. Do not score ambiguity, do not run readiness gates, and do not hand off to `$ultragoal`, `$ralplan`, `$autopilot`, or `$team` until that summary answer is captured.\n\nUse:\n- Original idea\n- Prior Q&A rounds\n- Current dimension scores\n- Brownfield context (if any)\n- Doc/context grounding notes, including existing terminology, governing rules, and any doc/code mismatch\n- Activated challenge mode injection (Phase 3)\n\nTarget the lowest-scoring dimension, but respect stage priority:\n- **Stage 1 — Intent-first:** Intent, Outcome, Scope, Non-goals, Decision Boundaries\n- **Stage 2 — Feasibility:** Constraints, Success Criteria\n- **Stage 3 — Brownfield grounding:** Context Clarity (brownfield only)\n\nFollow-up pressure ladder after each answer:\n1. Ask for a concrete example, counterexample, or evidence signal behind the latest claim\n2. Probe the hidden assumption, dependency, or belief that makes the claim true\n3. Force a boundary or tradeoff: what would you explicitly not do, defer, or reject?\n4. Challenge fuzzy or conflicting terms against the repo's documented language and current code behavior\n5. Stress-test the boundary with one concrete scenario or edge case when a relationship or handoff remains ambiguous\n6. If the answer still describes symptoms, reframe toward essence / root cause before moving on\n\nPrefer staying on the same thread for multiple rounds when it has the highest leverage. Breadth without pressure is not progress.\n\nMaintain a **Breadth Ledger** across independent ambiguity tracks: scope, constraints, outputs, verification, brownfield integration, and any user-mentioned deliverable tracks. The ledger is a guard, not a mandatory rotation rule: stay deep on the current thread until it has been pressure-tested, then zoom out only when another material track remains unresolved and would change execution.\n\nMaintain a **Docs/Terminology Ledger** for brownfield interviews:\n- repo docs/rules/context sources inspected, with path references\n- canonical terms already used by the repo and terms to avoid or disambiguate\n- user terms that conflict with docs or current code behavior\n- doc/code mismatches that require a human decision before implementation\n- optional durable-doc follow-ups that are safe to propose but not auto-apply\n\nDetailed dimensions:\n- Intent Clarity — why the user wants this\n- Outcome Clarity — what end state they want\n- Scope Clarity — how far the change should go\n- Constraint Clarity — technical or business limits that must hold\n- Success Criteria Clarity — how completion will be judged\n- Context Clarity — existing codebase understanding (brownfield only)\n\n`Non-goals` and `Decision Boundaries` are mandatory readiness gates. Ask about them early and keep revisiting them until they are explicit.\n\n### 2b) Ask the question\nUse the surface-appropriate structured questioning path for every interview round. In attached-tmux sessions, use OMX-owned structured questioning via `omx question` (this is the required structured-question equivalent and required `AskUserQuestion` equivalent for deep-interview). Outside tmux, use native structured input when available; otherwise ask exactly one concise plain-text question and wait for the answer. Present:\n\n```\nRound {n} | Target: {weakest_dimension} | Ambiguity: {score}%\n\n{question}\n```\n\n`omx question` payload guidance for interview rounds:\n- Deep-interview is Socratic: ask one focused round at a time. Do not use batch `questions[]` to combine multiple interview rounds, even though `omx question` supports batch forms for other workflows.\n- Use canonical `type` values instead of authoring raw `multi_select` flags by hand. `type: \"single-answerable\"` is the default for one-path decisions; `type: \"multi-answerable\"` is the canonical shape for bounded multi-select rounds. The runtime will keep `multi_select` aligned with `type`.\n- Use `single-answerable` when exactly one answer should drive the next branch, the options are mutually exclusive, or selecting more than one answer would blur the decision boundary. Typical cases: handoff lane selection, choosing the primary failure mode, or confirming which of several competing interpretations is correct.\n- Use `multi-answerable` when multiple options may all be true at once and you need to capture a bounded set of coexisting constraints, non-goals, risks, or acceptance checks in one round. Typical cases: selecting all out-of-scope items, all success metrics that must hold, or all deployment constraints that apply together.\n- If one selected option would immediately require a follow-up question to disambiguate the others, prefer a `single-answerable` round now and ask the follow-up next. Do not hide a branching interview tree inside one overloaded multi-select prompt.\n- Keep interview options bounded and concrete. If the valid answers are already known, set `allow_other: false`; only leave `allow_other: true` when the interview genuinely needs one user-supplied option that cannot be enumerated in advance.\n- Read answers structurally from the primary `answers[]` array. For a normal single-round interview response, use `answers[0].answer` as the source of truth; the top-level `answer` field is a legacy single-question projection/fallback only.\n- For `single-answerable`, expect one decisive selection in the `value` field of `answers[0].answer` plus its selected-values metadata. For `multi-answerable`, treat the selected-values field inside `answers[0].answer` as the source of truth for all chosen constraints/non-goals and preserve the full set in the transcript/spec. In legacy single-question projections, this is equivalent to: For `multi-answerable`, treat `answer.selected_values` as the source of truth.\n\nCanonical bounded single-choice payload:\n\n```json\n{\n \"question\": \"Which execution lane should own this once the interview is complete?\",\n \"type\": \"single-answerable\",\n \"options\": [\n {\n \"label\": \"Plan first\",\n \"value\": \"ralplan\",\n \"description\": \"Need architecture and test-shape review before execution\"\n },\n {\n \"label\": \"Execute directly\",\n \"value\": \"autopilot\",\n \"description\": \"Requirements are already explicit enough for planning plus execution\"\n },\n {\n \"label\": \"Refine further\",\n \"value\": \"refine\",\n \"description\": \"Clarification is still needed before any handoff\"\n }\n ],\n \"allow_other\": false,\n \"other_label\": \"Other\",\n \"source\": \"deep-interview\"\n}\n```\n\nCanonical bounded multi-select payload:\n\n```json\n{\n \"question\": \"Which non-goals must stay out of scope for the first pass?\",\n \"type\": \"multi-answerable\",\n \"options\": [\n {\n \"label\": \"No UI redesign\",\n \"value\": \"no-ui-redesign\",\n \"description\": \"Keep layout and styling unchanged\"\n },\n {\n \"label\": \"No new dependencies\",\n \"value\": \"no-new-dependencies\",\n \"description\": \"Work within the existing toolchain\"\n },\n {\n \"label\": \"No API contract changes\",\n \"value\": \"no-api-contract-changes\",\n \"description\": \"Preserve external request and response shapes\"\n }\n ],\n \"allow_other\": false,\n \"other_label\": \"Other\",\n \"source\": \"deep-interview\"\n}\n```\n\nCanonical answer-shape reminders:\n\n```json\n{\n \"answer\": {\n \"kind\": \"option\",\n \"value\": \"ralplan\",\n \"selected_labels\": [\"Plan first\"],\n \"selected_values\": [\"ralplan\"]\n }\n}\n```\n\n```json\n{\n \"answer\": {\n \"kind\": \"multi\",\n \"value\": [\"no-new-dependencies\", \"no-api-contract-changes\"],\n \"selected_labels\": [\"No new dependencies\", \"No API contract changes\"],\n \"selected_values\": [\"no-new-dependencies\", \"no-api-contract-changes\"]\n }\n}\n```\n\n### 2c) Score ambiguity\nScore each weighted dimension in `[0.0, 1.0]` with justification + gap.\n\nGreenfield: `ambiguity = 1 - (intent × 0.30 + outcome × 0.25 + scope × 0.20 + constraints × 0.15 + success × 0.10)`\n\nBrownfield: `ambiguity = 1 - (intent × 0.25 + outcome × 0.20 + scope × 0.20 + constraints × 0.15 + success × 0.10 + context × 0.10)`\n\nReadiness gate:\n- `Non-goals` must be explicit\n- `Decision Boundaries` must be explicit\n- A pressure pass must be complete: at least one earlier answer has been revisited with an evidence, assumption, or tradeoff follow-up\n- A practical closure audit must pass: another question would change execution materially, not merely polish wording or chase a narrow edge case\n- If either gate is unresolved, or the pressure pass is incomplete, continue below threshold only with a final closure question that names the unresolved gate and would materially change execution.\n- Treat a low ambiguity score as permission to audit closure, not permission to keep drilling indefinitely. If remaining uncertainty would not change implementation, crystallize the spec instead of opening a new branch.\n- If ambiguity is `<= 0.10`, another user-facing question is allowed only as that final closure question; otherwise crystallize immediately.\n\n### 2d) Report progress\nShow weighted breakdown table, readiness-gate status (`Non-goals`, `Decision Boundaries`), and the next focus dimension.\n\n### 2e) Persist state\nAppend round result and updated scores via `omx state write --input '<json>' --json`. Do not write `{mode}-state.json` directly and do not use the read-only MCP state projection as a writer.\n\n### 2f) Round controls\n- Do not offer early exit before the first explicit assumption probe and one persistent follow-up have happened\n- Apply a **Dialectic Rhythm Guard**: track consecutive non-user fact discoveries and confirmation-style answers (`[from-code][auto-confirmed]`, `[from-code]`, or `[from-research]`). After 3 consecutive non-user or confirmation answers, the next material user-facing round must solicit direct human judgment (`[from-user]`) unless the closure audit says the interview is ready to crystallize.\n- Round 4+: allow explicit early exit with risk warning\n- Soft warning at profile midpoint (e.g., round 3/6/10 depending on profile)\n- Hard cap at profile `max_rounds`; never treat this cap as a desired interview length or quota\n\n## Phase 3: Challenge Modes (assumption stress tests)\n\nUse each mode once when applicable. These are normal escalation tools, not rare rescue moves:\n\n- **Contrarian** (round 2+ or immediately when an answer rests on an untested assumption): challenge core assumptions\n- **Terminologist** (brownfield, whenever a key term is fuzzy, overloaded, or conflicts with repo docs/code): force a canonical meaning against existing project language before implementation\n- **Simplifier** (round 4+ or when scope expands faster than outcome clarity): probe minimal viable scope\n- **Ontologist** (round 5+ and ambiguity > 0.25, or when the user keeps describing symptoms): ask for essence-level reframing\n\nTrack used modes in state to prevent repetition.\n\n## Phase 4: Crystallize Artifacts\n\nWhen threshold is met (or user exits with warning / hard cap):\n\n1. Write interview transcript summary to:\n - `.omx/interviews/{slug}-{timestamp}.md`\n (kept for ralph PRD compatibility)\n2. Write execution-ready spec to:\n - `.omx/specs/deep-interview-{slug}.md`\n\nSpec should include:\n- Metadata (profile, rounds, final ambiguity, threshold, context type)\n- Context snapshot reference/path (for ralplan/team reuse)\n- Prompt-safe initial-context summary when oversized context was provided, plus references to any full source documents\n- Clarity breakdown table\n- Intent (why the user wants this)\n- Desired Outcome\n- In-Scope\n- Out-of-Scope / Non-goals\n- Decision Boundaries (what OMX may decide without confirmation)\n- Constraints\n- Testable acceptance criteria\n- Assumptions exposed + resolutions\n- Pressure-pass findings (which answer was revisited, and what changed)\n- Brownfield evidence vs inference notes for any repository-grounded confirmation questions\n- Docs/Terminology Ledger with inspected repo docs/rules/context, term conflicts, and any doc/code mismatch decisions\n- Scenario/edge-case pressure findings that materially shaped scope or acceptance criteria\n- Optional durable documentation recommendations, explicitly marked opt-in and public-safe; do not include raw private transcript dumps\n- Technical context findings\n- Full or condensed transcript\n\n### Autoresearch specialization\n\nWhen the clarified task is specifically about `$autoresearch`, or the skill is invoked with `--autoresearch`, keep the interview domain-specific and emit skill-consumable artifacts without skipping clarification.\n\n- **Accepted seed inputs:** `topic`, `evaluator`, `keep-policy`, `slug`, existing mission draft text, and prior evaluator examples/templates\n- **Required interview focus:** mission clarity, evaluator readiness, keep policy, slug/session naming, and whether the draft is ready to launch now or should refine further\n- **Canonical artifact path:** `.omx/specs/deep-interview-autoresearch-{slug}.md`\n- **Launch artifact bundle:** `.omx/specs/autoresearch-{slug}/mission.md`, `.omx/specs/autoresearch-{slug}/sandbox.md`, and `.omx/specs/autoresearch-{slug}/result.json`\n- **Launch artifact directory:** `.omx/specs/autoresearch-{slug}/`\n- **Required artifact sections:**\n - `Mission Draft`\n - `Evaluator Draft`\n - `Launch Readiness`\n - `Seed Inputs`\n - `Confirmation Bridge`\n- **Required launch artifacts under `.omx/specs/autoresearch-{slug}/`:**\n - `mission.md`\n - `sandbox.md`\n - `result.json`\n- **Launch-readiness rule:** mark the draft as **not launch-ready** while the evaluator command still contains placeholder markers such as `<...>`, `TODO`, `TBD`, `REPLACE_ME`, `CHANGEME`, or `your-command-here`\n- **Structured result contract:** `result.json` should point to the draft + mission/sandbox artifacts and carry the finalized `topic`, `evaluatorCommand`, `keepPolicy`, `slug`, `launchReady`, and `blockedReasons` fields so `$autoresearch` can consume it directly\n- **Confirmation bridge:** after artifact generation, offer at least `refine further` and `launch`; do not run direct CLI launch or detached/split tmux launch, and only hand off to `$autoresearch` after explicit confirmation\n- **Handoff rule:** downstream execution must preserve the clarified mission intent, evaluator expectations, decision boundaries, and launch-readiness status from this artifact rather than bypassing the draft review step\n\n## Phase 5: Execution Bridge\n\nPresent execution options after artifact generation using explicit handoff contracts. Treat the deep-interview spec as the current requirements source of truth and preserve intent, non-goals, decision boundaries, acceptance criteria, docs/terminology grounding, and any residual-risk warnings across the handoff.\n\n### Optional execution contract foundation\n\nWhen an Autopilot/deep-interview handoff explicitly requires a stride contract, emit it as structured data rather than prose. This is a validation foundation, not a broadness-inference feature: do not infer stride from task length, phase labels, snapshots, or freeform wording.\n\nCanonical location under Autopilot state:\n\n```json\n{\n \"handoff_artifacts\": {\n \"deep_interview\": {\n \"execution_contract_required\": true,\n \"execution_contract\": {\n \"version\": 1,\n \"execution_stride\": \"task\",\n \"source\": \"deep-interview\",\n \"selected_by\": \"user\",\n \"allow_task_shrink\": true,\n \"completion_unit\": \"One focused task\",\n \"stop_condition\": \"Stop after that task is implemented and verified\",\n \"acceptance_coverage_scope\": \"task\",\n \"shrink_policy\": \"allowed\"\n }\n }\n }\n}\n```\n\nStride meanings:\n- `task`: conservative, small-step execution; `allow_task_shrink:true`, `acceptance_coverage_scope:\"task\"`, `shrink_policy:\"allowed\"`.\n- `deliverable`: finish the named deliverable before stopping; `allow_task_shrink:false`, `acceptance_coverage_scope:\"deliverable\"`, `shrink_policy:\"ask_before_shrink\"`.\n- `milestone`: finish the larger approved milestone unless blocked; `allow_task_shrink:false`, `acceptance_coverage_scope:\"milestone\"`, `shrink_policy:\"deny_unless_blocked\"`.\n\nOnly set `execution_contract_required:true` when the selected downstream workflow needs this explicit stride/stop-condition guard. New artifacts must write the canonical snake_case schema shown above under `handoff_artifacts.deep_interview`; runtime readers may accept legacy camelCase field/marker aliases and direct/nested `execution_contract` locations only as compatibility input. If `execution_contract_required` is absent or false, downstream Autopilot compatibility behavior is unchanged.\n\n### Goal-mode follow-ups\n\nInclude these product-facing suggestions when they fit the clarified spec, without removing the existing `$ultragoal`, `$ralplan`, `$autopilot`, and `$team` handoff options:\n\n- **`$ultragoal`** — default goal-mode follow-up for implementation or general goal-oriented follow-up specs that should be converted into durable Codex/OMX goals with sequential completion tracking.\n- **`$autoresearch`** — use when the clarified context is a research project: a research question, reference/literature gathering, evaluator-backed analysis, or professor/critic-style deliverable.\n- **`$performance-goal`** — use when the clarified context is an optimization or performance project with measurable speed, latency, throughput, memory, benchmark, or evaluator criteria.\n\nRecommend `$ultragoal` as the default durable goal-mode follow-up because it supersedes Ralph for goal tracking. Preserve `$team` for coordinated parallel implementation.\n\n### 1. **`$ultragoal` (Default durable execution follow-up)**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md` (optionally accompanied by the transcript/context snapshot for traceability)\n- **Invocation:** `$ultragoal create-goals --brief-file <spec-path>` followed by `$ultragoal complete-goals` in the active execution lane\n- **Consumer Behavior:** Convert the clarified spec into durable goal-mode work. Preserve intent, non-goals, decision boundaries, acceptance criteria, docs/terminology grounding, scenario-pressure findings, and residual-risk warnings as binding story constraints.\n- **Skipped / Already-Satisfied Stages:** Requirement interview, ambiguity clarification, doc/context preflight, and early intent-boundary elicitation\n- **Expected Output:** `.omx/ultragoal/brief.md`, `.omx/ultragoal/goals.json`, `.omx/ultragoal/ledger.jsonl`, implementation evidence, verification evidence, and final cleanup/review-gate evidence\n- **Best When:** The clarified spec is execution-ready or the user explicitly wants durable goal tracking as the next step\n- **Next Recommended Step:** Run the Ultragoal completion loop; launch `$team` only inside an active Ultragoal story when parallel lanes are warranted\n\n### 2. **`$ralplan` (Recommended when architecture/test-shape review is still needed)**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md` (optionally accompanied by the transcript/context snapshot for traceability)\n- **Invocation:** `$ralplan <spec-path>`\n- **Consumer Behavior:** Treat the deep-interview spec as the requirements source of truth. Do not repeat the interview by default; refine architecture/feasibility around the clarified intent and boundaries instead.\n- **Skipped / Already-Satisfied Stages:** Requirements discovery, ambiguity clarification, and early intent-boundary elicitation\n- **Expected Output:** Canonical planning artifacts under `.omx/plans/`, especially `prd-*.md` and `test-spec-*.md`\n- **Best When:** Requirements are clear enough to stop interviewing, but architectural validation / consensus planning is still desirable\n- **Next Recommended Step:** Use the approved planning artifacts with `$ultragoal` as the default durable goal-mode follow-up (optionally with `$team` for parallel lanes); choose `$autoresearch` for research validation or `$performance-goal` for measurable optimization\n\n### 3. **`$autopilot`**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md`\n- **Invocation:** `$autopilot <spec-path>`\n- **Consumer Behavior:** Use the deep-interview spec as the clarified execution brief. Preserve intent, non-goals, decision boundaries, and acceptance criteria as binding context for planning/execution.\n- **Skipped / Already-Satisfied Stages:** Initial requirement discovery and ambiguity reduction\n- **Expected Output:** Planning/execution progress, QA evidence, and validation artifacts produced by autopilot\n- **Best When:** The clarified spec is already strong enough for direct planning + execution without an additional consensus gate\n- **Next Recommended Step:** Continue through autopilot's execution/QA/validation flow; if coordination-heavy execution emerges, prefer `$team` under a leader-owned `$ultragoal` ledger\n\n### 4. **`$team`**\n- **Input Artifact:** `.omx/specs/deep-interview-{slug}.md`\n- **Invocation:** `$team <spec-path>`\n- **Consumer Behavior:** Treat the spec as shared execution context for coordinated parallel work. Preserve the clarified intent, non-goals, decision boundaries, and acceptance criteria as common lane constraints.\n- **Skipped / Already-Satisfied Stages:** Requirement clarification and early ambiguity reduction\n- **Expected Output:** Coordinated multi-agent execution against the shared spec, with final verification evidence and checkpoints in an already-active Ultragoal ledger when applicable\n- **Best When:** The task is large, multi-lane, or blocker-sensitive enough to justify coordinated parallel execution instead of a single persistent loop\n- **Next Recommended Step:** Follow the team verification path when the coordinated execution phase finishes; checkpoint an already-active `$ultragoal` ledger when applicable. Do not start another execution loop solely to verify.\n\n### 5. **Refine further**\n- **Input Artifact:** Existing transcript, context snapshot, and current spec draft\n- **Invocation:** Continue the interview loop\n- **Consumer Behavior:** Re-enter questioning to resolve the highest-leverage remaining uncertainty\n- **Skipped / Already-Satisfied Stages:** None beyond already-captured context\n- **Expected Output:** A lower-ambiguity spec with tighter boundaries and fewer unresolved assumptions\n- **Best When:** Residual ambiguity is still too high, the user wants stronger clarity, or the above-threshold / early-exit warning indicates too much risk to proceed cleanly\n- **Next Recommended Step:** Return to one of the execution handoff contracts above once the spec is sufficiently clarified\n\n**Residual-Risk Rule:** If the interview ended via early exit, hard-cap completion, or above-threshold proceed-with-warning, explicitly preserve that residual-risk state in the handoff so the downstream skill knows it inherited a partially clarified brief.\n\n**IMPORTANT:** Deep-interview is a requirements mode. On handoff, invoke the selected skill using the contract above. **Do NOT implement directly** inside deep-interview.\n\n</Steps>\n\n<Tool_Usage>\n- Use `explore` for codebase fact gathering\n- Use `omx question` as the OMX-native structured user-input tool for each interview round when an attached tmux renderer is available\n- From attached-tmux Bash/tool paths, call it as `OMX_QUESTION_RETURN_PANE=$TMUX_PANE omx question ...` unless an explicit `%pane` return target is already known\n- If the current runtime is outside tmux and cannot render `omx question`, use native structured input when available; otherwise ask exactly one concise plain-text question and wait for the answer\n- After `omx question` returns JSON, prefer `answers[0].answer` / `answers[]`; use legacy `answer` only as a fallback for older records\n- Use `omx state write/read --input '<json>' --json` for resumable mode state through the sole-writer state operations path; the MCP state server is read-only and is not a fallback writer\n- If the interview cannot ask a required `omx question` round, persist the blocker as terminal state with `active: false` and `current_phase: \"blocked\"`; do not write a terminal blocked phase with `active: true`\n- Read/write context snapshots under `.omx/context/`\n- Read applicable repo docs/rules/context during preflight; write durable docs, glossary, ADR, or memory updates only when the user explicitly opts in and the content is public-safe\n- Record whether the oversized-context summary gate is not needed, pending, or satisfied before any scoring or handoff step\n- Save transcript/spec artifacts under `.omx/interviews/` and `.omx/specs/`\n</Tool_Usage>\n\n<Escalation_And_Stop_Conditions>\n- User says stop/cancel/abort -> persist state and stop\n- Ambiguity stalls for 3 rounds (+/- 0.05) -> force Ontologist mode once\n- Max rounds reached -> proceed with explicit residual-risk warning\n- All dimensions >= 0.9 -> allow early crystallization even before max rounds\n</Escalation_And_Stop_Conditions>\n\n<Final_Checklist>\n- [ ] Preflight context snapshot exists under `.omx/context/{slug}-{timestamp}.md`\n- [ ] Oversized initial context, if present, has a prompt-safe summary recorded before ambiguity scoring or downstream handoff\n- [ ] Ambiguity score shown each round\n- [ ] Intent-first stage priority used before implementation detail\n- [ ] Weakest-dimension targeting used within the active stage\n- [ ] At least one explicit assumption probe happened before crystallization\n- [ ] At least one persistent follow-up / pressure pass deepened a prior answer\n- [ ] Challenge modes triggered at thresholds (when applicable)\n- [ ] Transcript written to `.omx/interviews/{slug}-{timestamp}.md`\n- [ ] Spec written to `.omx/specs/deep-interview-{slug}.md`\n- [ ] Brownfield questions use evidence-backed confirmation when applicable\n- [ ] Brownfield preflight inspected applicable repo docs/rules/context before user-facing questions\n- [ ] Fuzzy or conflicting terminology was challenged against repo language/current code behavior when applicable\n- [ ] Scenario-based edge-case grilling was used when boundary ambiguity would materially affect implementation\n- [ ] Durable docs/ADR/memory updates, if any, were explicitly opted into and public-safe\n- [ ] Handoff options provided (`$ultragoal`, `$ralplan`, `$autopilot`, `$team`) plus context-sensitive goal-mode suggestions (`$autoresearch`, `$performance-goal`) when applicable\n- [ ] No direct implementation performed in this mode\n</Final_Checklist>\n\n<Advanced>\n## Suggested Config (optional)\n\nDeep-interview reads runtime defaults from the first existing config source in this order:\n\n1. Repository-local `.omx/config.toml`\n2. Repository-root `omx.toml`\n3. User-global `~/.omx/config.toml`\n\nThis section is currently a deep-interview-specific runtime override surface, not a general replacement for Codex `config.toml` or `.omx-config.json` model/env routing.\nMalformed config files are ignored fail-soft so `$deep-interview` activation can continue with built-in defaults.\nExplicit `--quick`, `--standard`, or `--deep` invocation flags override `defaultProfile`.\n\n```toml\n[omx.deepInterview]\ndefaultProfile = \"standard\"\nquickThreshold = 0.30\nstandardThreshold = 0.20\ndeepThreshold = 0.15\nquickMaxRounds = 5\nstandardMaxRounds = 12\ndeepMaxRounds = 20\nenableChallengeModes = true\n```\n\n## Resume\n\nIf interrupted, rerun `$deep-interview`. Resume from persisted mode state via `omx state read --input '{\"mode\":\"deep-interview\"}' --json`.\n\n## Canonical Autopilot Entry Pipeline\n\n```\nautopilot -> deep-interview -> ralplan -> ultragoal\n```\n\n- Autopilot begins with this independent deep-interview clarity gate; it must not substitute `$plan --interview`.\n- Stage 1 (deep-interview): ambiguity clearance and execution-ready requirements artifact\n- Stage 2 (ralplan): feasibility, architecture, and consensus gate\n- Stage 3 (ultragoal): durable execution, verification, and completion receipts\n</Advanced>\n\n<!-- File: plugins/oh-my-codex/skills/design/SKILL.md (Tokens: ~891 | Category: anthropic-skill) -->\n---\nname: design\ndescription: Canonical repo-local DESIGN.md workflow for product, UI/UX, and frontend decision source of truth\n---\n\n# Design Skill\n\nUse `$design` to discover product and UI evidence, close only design-critical context gaps, and create or refresh the repository’s durable `DESIGN.md` contract. It is a maintained design brief, not a pixel-matching loop or one-off critique.\n\nShared operating, delegation, state, hook, team, cancellation, and verification invariants live in [`templates/AGENTS.md`](../../templates/AGENTS.md). Follow that source instead of duplicating its rules here.\n\n## Use when\n\n- Product, UX, frontend, or design-system decisions need a repo-local source of truth.\n- A feature needs a design brief before a designer lane or implementation.\n- Existing UI, assets, screenshots, or constraints need an actionable design summary.\n\nDo not use it for visual-reference implementation matching (use `$visual-ralph`), screenshot comparison alone, or backend/infrastructure work without user-facing design impact.\n\n## Relationship to `$visual-ralph`\n\n`$design` owns product goals, users, information architecture, visual language, components, accessibility, constraints, and open questions in `DESIGN.md`. `$visual-ralph` owns implementation against an approved visual reference or live-URL baseline, measured verdicts, and pixel-diff evidence. Run `$design` first when both are needed; `DESIGN.md` supports but does not replace the visual verdict target.\n\n## Workflow\n\n### 1. Discover local evidence\n\nInspect and cite existing `DESIGN.md`, design/UX/frontend docs, README/specs/issues, routes/pages/layouts/components/stories, theme and token files, assets, screenshots/mockups, Storybook or Playwright baselines, and accessibility/responsive/i18n/platform constraints. Separate observations from inferences; note absent evidence.\n\n### 2. Interview only missing context\n\nAsk concise questions only for gaps the repository cannot resolve: users/jobs, goals/non-goals, brand personality and forbidden aesthetics, primary flows, accessibility/device/browser targets, or unavailable assets/references. If answers are unavailable, record explicit assumptions and open questions rather than blocking.\n\n### 3. Create or refresh `DESIGN.md`\n\nPreserve useful content, remove contradictions, mark unknowns, and keep decisions actionable. The root file must contain these sections:\n\n# Design\n## Source of truth\nStatus (Draft | Active | Needs refresh), date, product surfaces, evidence reviewed.\n## Brand\nPersonality, trust signals, avoid.\n## Product goals\nGoals, non-goals, success signals.\n## Personas and jobs\nPrimary personas, user jobs, contexts of use.\n## Information architecture\nNavigation, routes/screens, content hierarchy.\n## Design principles\nPrinciples and tradeoffs.\n## Visual language\nColor, typography, spacing, shape/elevation, motion, imagery/iconography.\n## Components\nExisting/new components, variants/states, token ownership.\n## Accessibility\nTarget standard, keyboard/focus, contrast, semantics, reduced motion/sensory concerns.\n## Responsive behavior\nBreakpoints/devices, layout adaptations, touch/hover differences.\n## Interaction states\nLoading, empty, error, success, disabled, offline/slow network where applicable.\n## Content voice\nTone, terminology, microcopy rules.\n## Implementation constraints\nFramework/styling, tokens, performance, compatibility, test/screenshot expectations.\n## Open questions\n`[ ]` question, owner, and impact.\n\n### 4. Apply the contract\n\nBefore UI decisions, cite relevant `DESIGN.md` sections, reuse documented components/tokens, and update the file or add an open question when implementation exposes a contradiction. Do not invent a parallel design-system layer.\n\n### 5. Handoff\n\nFor normal frontend work, provide the relevant sections, repo evidence, and acceptance criteria. For visual-reference, image, or live-URL matching, hand off to `$visual-ralph` with the approved baseline and identify `DESIGN.md` as supporting context only.\n\n## Evidence and completion\n\nComplete only when design docs/assets/components/screenshots were inspected or noted absent; missing context is answered, assumed, or listed; root `DESIGN.md` contains every required section; recommendations cite it; and any Visual Ralph handoff is clearly separated from design governance.\n\nTask: {{ARGUMENTS}}\n\n<!-- File: plugins/oh-my-codex/skills/doctor/SKILL.md (Tokens: ~1530 | Category: anthropic-skill) -->\n---\nname: doctor\ndescription: Diagnose and fix oh-my-codex installation issues\n---\n\n# OMX Doctor\n\nUse this task card to diagnose installation/discovery problems. Shared safety, lifecycle, hook, team, autonomy, and cancellation rules live in `templates/AGENTS.md`. `~/.codex` means `${CODEX_HOME:-~/.codex}` when `CODEX_HOME` is set.\n\n## Run diagnostics\n\n```bash\nomx doctor\nomx doctor --team # include Team runtime checks\nomx doctor --verbose # include detailed check evidence\nomx doctor --force # repair eligible repo artifact ownership issues\nomx doctor --dry-run --force # preview eligible ownership repairs\n```\n\nFor a local source checkout, build first and invoke `node dist/cli/omx.js doctor`. Keep command output and exact paths for the report.\n\n### Plugin cache and version\n\n```bash\nPLUGIN_CACHE_ROOT=\"${CODEX_HOME:-$HOME/.codex}/plugins/cache\"\nCACHE_ENTRIES=$(find \"$PLUGIN_CACHE_ROOT\" -path \"*/oh-my-codex/*\" -mindepth 3 -maxdepth 3 -type d 2>/dev/null)\nif [[ -z \"$CACHE_ENTRIES\" ]]; then\n echo \"Installed plugin cache: none\"\nelse\n while IFS= read -r d; do\n m=$(basename \"$(dirname \"$(dirname \"$d\")\")\"); v=$(basename \"$d\")\n printf 'Installed plugin cache: marketplace=%s version=%s path=%s\\n' \"$m\" \"$v\" \"$d\"\n done <<<\"$CACHE_ENTRIES\"\nfi\nLATEST=$(npm view oh-my-codex version 2>/dev/null)\necho \"Latest npm: $LATEST\"\n```\n\nNo cache is INFO (normal for npm/setup-only installs). A non-`local` cache version differing from `LATEST`, or multiple versions for one marketplace, is WARN. Plugin discovery does not replace npm installation plus `omx setup`; native/runtime wiring remains setup-owned.\n\n### Hooks, AGENTS, and skill roots\n\n```bash\nCODEX_DIR=\"${CODEX_HOME:-$HOME/.codex}\"\nls -la \"$CODEX_DIR/config.toml\" \"$CODEX_DIR/settings.json\" 2>/dev/null\nrg 'keyword-detector|persistent-mode|session-start|stop-continuation' \"$CODEX_DIR/config.toml\" \"$CODEX_DIR/settings.json\" 2>/dev/null || true\nls -la \"$CODEX_DIR/hooks\"/*.sh 2>/dev/null\nls -la \"$CODEX_DIR/AGENTS.md\" 2>/dev/null\ngrep -q \"oh-my-codex Multi-Agent System\" \"$CODEX_DIR/AGENTS.md\" 2>/dev/null && echo \"Has OMX config\" || echo \"Missing OMX config\"\nls -la \"$CODEX_DIR/agents\" \"$CODEX_DIR/commands\" \"$CODEX_DIR/skills\" \"$HOME/.agents/skills\" 2>/dev/null\n```\n\nClassify legacy hook references as **CRITICAL** (duplicate hooks). The scripts `keyword-detector.sh`, `persistent-mode.sh`, `session-start.sh`, and `stop-continuation.sh` are **WARN**. Missing AGENTS.md is **CRITICAL**; missing the OMX marker is **WARN**. `${CODEX_HOME:-~/.codex}/skills` is the canonical user root. `~/.agents/skills` is historical and overlapping trees can duplicate skill entries. OMX files under legacy `agents/` or `commands/` are **WARN**.\n\nWith `--team`, retain any `resume_blocker`, `slow_shutdown`, `delayed_status_lag`, `stale_leader`, or `orphan_tmux_session` diagnostics; failed checks set a non-zero exit status.\n\n## Report contract\n\n```text\n## OMX Doctor Report\n### Summary\n[HEALTHY / ISSUES FOUND]\n### Checks\n| Check | Status | Details |\n| Plugin Version | OK/WARN/INFO | ... |\n| Hook Config (config.toml / legacy settings.json) | OK/CRITICAL | ... |\n| Legacy Scripts (~/.codex/hooks/) | OK/WARN | ... |\n| AGENTS.md | OK/WARN/CRITICAL | ... |\n| Plugin Cache | OK/WARN | ... |\n| Legacy Agents / Commands | OK/WARN | ... |\n| Skills (canonical / historical root) | OK/WARN | ... |\n### Issues Found\n1. ...\n### Recommended Fixes\n...\n```\n\n## Remediation (after user confirmation and confirming each target is OMX-owned)\n\nRemove only confirmed OMX legacy content; preserve unrelated user files:\n\n```bash\n# If settings.json exists, remove only its legacy \"hooks\" section.\nrm -f \"$CODEX_DIR/hooks/keyword-detector.sh\" \"$CODEX_DIR/hooks/persistent-mode.sh\" \"$CODEX_DIR/hooks/session-start.sh\" \"$CODEX_DIR/hooks/stop-continuation.sh\"\nPLUGIN_CACHE_ROOT=\"${CODEX_HOME:-$HOME/.codex}/plugins/cache\"\nfind \"$PLUGIN_CACHE_ROOT\" -path \"*/oh-my-codex\" -type d -prune -exec rm -rf {} +\n```\n\nFor older curl installs, inspect first and remove only directories containing OMX-managed files:\n\n```bash\nls -la \"$CODEX_DIR/agents\" \"$CODEX_DIR/commands\" \"$CODEX_DIR/skills\" \"$HOME/.agents/skills\" 2>/dev/null\n# Optional backups:\n# mv \"$CODEX_DIR/agents\" \"$CODEX_DIR/agents.bak\"\n# mv \"$CODEX_DIR/commands\" \"$CODEX_DIR/commands.bak\"\n# mv \"$HOME/.agents/skills\" \"$HOME/.agents/skills.bak\"\nrm -rf \"$CODEX_DIR/agents\" \"$CODEX_DIR/commands\" \"$HOME/.agents/skills\"\n```\n\nIf AGENTS.md is missing/outdated, fetch the current raw file and write it to `$CODEX_DIR/AGENTS.md`:\n\n```text\nWebFetch(url: \"https://raw.githubusercontent.com/Yeachan-Heo/oh-my-codex/main/docs/AGENTS.md\", prompt: \"Return the complete raw markdown content exactly as-is\")\n```\n\nTo keep only the newest cache version for a selected marketplace:\n\n```bash\nPLUGIN_CACHE_DIR=\"$PLUGIN_CACHE_ROOT/$MARKETPLACE_NAME/oh-my-codex\"\nKEEP_VERSION=$(for d in \"$PLUGIN_CACHE_DIR\"/*; do [[ -d \"$d\" ]] && basename \"$d\"; done | sort -V | tail -1)\n[[ -n \"$KEEP_VERSION\" ]] && find \"$PLUGIN_CACHE_DIR\" -mindepth 1 -maxdepth 1 -type d ! -name \"$KEEP_VERSION\" -exec rm -rf {} +\n```\n\nIf AGENTS.md is missing or stale, refresh it from the current release source, then rerun `omx doctor`. If legacy `~/.agents/skills` overlaps the canonical root, archive/remove that tree only after checking for custom skills. Restart Codex after fixes and report before/after evidence.\n\n## Exit conditions\n\nStop with **HEALTHY** only when required paths, hook/config checks, AGENTS marker, plugin cache status, and (when requested) Team checks pass. Otherwise report **ISSUES FOUND**, exact failed evidence, and the smallest confirmed remediation; do not claim a fix from a recommendation alone.\n\n<!-- File: plugins/oh-my-codex/skills/hud/SKILL.md (Tokens: ~919 | Category: anthropic-skill) -->\n---\nname: \"hud\"\ndescription: \"Show or configure the OMX HUD (two-layer statusline)\"\nrole: \"display\"\nscope: \".omx/**\"\n---\n\n# HUD Skill\n\nThe OMX HUD uses a two-layer architecture:\n\n1. **Layer 1 - Codex built-in statusLine**: Real-time TUI footer showing model, git branch, and context usage. Configured via `[tui] status_line` in `~/.codex/config.toml`. Zero code required.\n\n2. **Layer 2 - `omx hud` CLI command**: Shows OMX-specific orchestration state (ralph, ultrawork, autopilot, team, pipeline, ecomode, turns). Reads `.omx/state/` files.\n\n## Quick Commands\n\n| Command | Description |\n|---------|-------------|\n| `omx hud` | Show current HUD (modes, turns, activity) |\n| `omx hud --watch` | Live-updating display (polls every 1s) |\n| `omx hud --json` | Raw state output for scripting |\n| `omx hud --preset=minimal` | Minimal display |\n| `omx hud --preset=focused` | Default display |\n| `omx hud --preset=full` | All elements |\n\n## Presets\n\n### minimal\n```\n[OMX] ralph:3/10 | turns:42\n```\n\n### focused (default)\n```\n[OMX] ralph:3/10 | ultrawork | team:3 workers | turns:42 | last:5s ago\n```\n\n### full\n```\n[OMX] ralph:3/10 | ultrawork | autopilot:execution | team:3 workers | pipeline:exec | turns:42 | last:5s ago | total-turns:156\n```\n\n## Setup\n\n`omx setup` automatically configures both layers:\n- Adds `[tui] status_line` to `~/.codex/config.toml` (Layer 1)\n- Writes `.omx/hud-config.json` with default preset (Layer 2)\n- Default preset is `focused`; if HUD/statusline changes do not appear, restart Codex CLI once.\n\n## Layer 1: Codex Built-in StatusLine\n\nConfigured in `~/.codex/config.toml`:\n```toml\n[tui]\nstatus_line = [\"model-with-reasoning\", \"git-branch\", \"context-remaining\"]\n```\n\nAvailable built-in items (Codex CLI v0.101.0+):\n`model-name`, `model-with-reasoning`, `current-dir`, `project-root`, `git-branch`, `context-remaining`, `context-used`, `five-hour-limit`, `weekly-limit`, `codex-version`, `context-window-size`, `used-tokens`, `total-input-tokens`, `total-output-tokens`, `session-id`\n\n## Layer 2: OMX Orchestration HUD\n\nThe `omx hud` command reads these state files:\n- `.omx/state/ralph-state.json` - Ralph loop iteration\n- `.omx/state/ultrawork-state.json` - Ultrawork mode\n- `.omx/state/autopilot-state.json` - Autopilot phase\n- `.omx/state/team-state.json` - Team workers\n- `.omx/state/pipeline-state.json` - Pipeline stage\n- `.omx/state/ecomode-state.json` - Ecomode active\n- `.omx/state/hud-state.json` - Last activity (from notify hook)\n- `.omx/metrics.json` - Turn counts\n\n## Configuration\n\nHUD config stored at `.omx/hud-config.json`:\n```json\n{\n \"preset\": \"focused\"\n}\n```\n\n## Color Coding\n\n- **Green**: Normal/healthy\n- **Yellow**: Warning (ralph >70% of max)\n- **Red**: Critical (ralph >90% of max)\n\n## Troubleshooting\n\nIf the TUI statusline is not showing:\n1. Ensure Codex CLI v0.101.0+ is installed\n2. Run `omx setup` to configure `[tui]` section\n3. Restart Codex CLI\n\nIf `omx hud` shows \"No active modes\":\n- This is expected when no workflows are running\n- Start an explicitly requested supported workflow (`$autopilot` or `$ultragoal`) and check again\n\n<!-- File: plugins/oh-my-codex/skills/omx-setup/SKILL.md (Tokens: ~1174 | Category: anthropic-skill) -->\n---\nname: omx-setup\ndescription: Setup and configure oh-my-codex using current CLI behavior\n---\n\n# OMX Setup\n\nUse this task card to install or refresh OMX for the current project and/or user scope. Shared safety, lifecycle, hook, team, autonomy, and cancellation rules live in `templates/AGENTS.md`. Do not infer new CLI behavior from this card; the implementation is authoritative.\n\n## Command and alternatives\n\n```bash\nomx setup [--force] [--merge-agents|--no-merge-agents|--clear-merge-agents-policy] [--dry-run] [--verbose] [--scope <user|project>] [--plugin|--legacy|--install-mode <legacy|plugin>] [--mcp <none|compat>] [--no-mcp|--with-mcp] [--disable-team|--enable-team|--team-mode <enabled|disabled>]\nomx agents-init [path] [--dry-run] [--force] [--verbose]\n```\n\nUse `agents-init` for lightweight AGENTS.md scaffolding only, not a full install.\n\nSupported setup options:\n- `--force`: overwrite/reinstall managed artifacts; transient, not persisted or replayed.\n- `--merge-agents`, `--no-merge-agents`, `--clear-merge-agents-policy`: exact bare selectors (no values/equals). Repeated identical selectors are idempotent; conflicting selectors fail before mutations. Set persists an explicit policy per invoking project root; clear removes it and cannot combine with a set. Merge refreshes managed sections; no-merge only suppresses that branch and is not a preserve mode.\n- `--dry-run`, `--verbose`: preview actions or show per-file/per-step detail.\n- `--scope user|project`: choose user (`~/.codex`, `~/.omx/agents`) or project (`./.codex`, `./.omx/agents`) targets.\n- `--plugin` / `--legacy`: select delivery mode; `--install-mode legacy|plugin` is the canonical scripted spelling. Conflicting mode flags fail.\n- `--mcp none|compat` (plus `--no-mcp` / `--with-mcp`): omit or enable first-party MCP compatibility and shared registry sync.\n- `--disable-team`, `--enable-team`, `--team-mode enabled|disabled`: select Team skill/context generation; conflicting selectors fail.\n\n## Resolve setup\n\n1. Scope: explicit flag, valid persisted `./.omx/setup-scope.json`, TTY choice (default `user`), or non-interactive `user`. Legacy `project-local` migrates to `project`.\n2. Mode: explicit flag, persisted mode when retained, discovered `${CODEX_HOME:-~/.codex}/plugins/cache/**/.codex-plugin/plugin.json` with `name: oh-my-codex` (plugin default), otherwise legacy. TTY reruns summarize saved choices and offer keep/review/reset; non-interactive runs do not block.\n3. Create required directories and atomically persist preferences only after successful setup.\n\n## What setup changes\n\n- Legacy mode installs prompts/native agents/skills and merges full config.toml.\n- Plugin mode archives/removes legacy OMX-managed prompts/skills, refreshes installable native agent TOMLs and stale generated non-installable agents, and keeps setup-owned runtime hooks.\n- Both modes verify Team CLI interop markers in built `dist/cli/team.js`, generate AGENTS defaults only when selected/allowed, and write `./.omx/hud-config.json`; notification hook references are setup-owned outside plugin skill delivery.\n- `AGENTS.md` is `./AGENTS.md`. Without `--force` or `--merge-agents`, interactive runs ask before overwrite and non-interactive runs preserve it. Active-session safeguards may skip writes. Plugin mode may separately prompt for AGENTS and `developer_instructions` defaults; non-interactive runs preserve existing files.\n- Plugin mode enables setup-owned runtime flags (`plugin_hooks`, `goals`, or legacy `hooks`/`codex_hooks` fallback). Project scope uses `CODEX_HOME=./.codex` unless explicitly overridden.\n\n## Verify\n\n```bash\nomx setup --force --verbose\nomx doctor\n```\n\nExpect doctor evidence for prompts and skills in the selected scope, project-root AGENTS.md, `.omx/state`, and CLI-first config in the scope target `config.toml`. First-party MCP and shared registry sync are omitted unless setup used `--mcp compat` (if supported by the installed CLI).\n\nIf using local source, run `npm run build` before `node dist/cli/omx.js setup --force --verbose` and `node dist/cli/omx.js doctor`. If AGENTS was not overwritten or merged, stop the active OMX session and rerun with `--force` or `--merge-agents`; do not edit lifecycle state manually.\n\n## Discovery troubleshooting\n\nIf `$omx-setup` is absent/stale: run `omx setup --verbose`, then `omx doctor`; verify `./.codex/skills/omx-setup/SKILL.md` for project scope or `${CODEX_HOME:-~/.codex}/skills/omx-setup/SKILL.md` for legacy user scope. In plugin mode verify the oh-my-codex plugin is installed/discovered. For duplicates, inspect historical `~/.agents/skills` overlap and follow doctor/setup cleanup guidance.\n\n## Exit contract\n\nReport selected scope/mode, dry-run versus mutation, AGENTS policy, affected roots, and doctor indicators. Stop only after setup completes successfully and verification identifies the expected files/config; on failure preserve the exact command output and rerun the smallest corrective command. Do not claim installation from a dry-run alone.\n\n<!-- File: plugins/oh-my-codex/skills/performance-goal/SKILL.md (Tokens: ~769 | Category: anthropic-skill) -->\n---\nname: performance-goal\ndescription: \"Run an evaluator-gated performance optimization workflow over Codex goal mode with durable OMX artifacts and safe goal handoffs.\"\n---\n\n# Performance Goal Workflow\n\nUse this skill when a user asks OMX to optimize performance and wants a goal-oriented loop rather than a one-off review.\n\n## Contract\n\n- OMX owns durable workflow state under `.omx/goals/performance/<slug>/`.\n- Codex goal mode owns only the active-thread focus/accounting primitive.\n- Shell commands do **not** mutate hidden Codex goal state. They write artifacts and emit model-facing handoff text.\n- No optimization work may start until an evaluator command and pass/fail contract exist.\n- Do not call `update_goal({status: \"complete\"})` until the evaluator has a passing checkpoint and a completion audit proves the objective is done; then call `get_goal` again and pass that fresh snapshot to `omx performance-goal complete --codex-goal-json`.\n\n## CLI\n\nCreate the workflow and evaluator contract:\n\n```sh\nomx performance-goal create \\\n --objective \"Reduce CLI startup latency by 20%\" \\\n --evaluator-command \"npm run perf:startup\" \\\n --evaluator-contract \"PASS when p95 latency improves by 20% and regression tests pass\" \\\n --slug startup-latency\n```\n\nEmit the Codex goal handoff:\n\n```sh\nomx performance-goal start --slug startup-latency\n```\n\nRecord evaluator evidence:\n\n```sh\nomx performance-goal checkpoint --slug startup-latency --status pass --evidence \"benchmark + tests passed\"\nomx performance-goal checkpoint --slug startup-latency --status fail --evidence \"benchmark regressed\"\nomx performance-goal checkpoint --slug startup-latency --status blocked --evidence \"missing fixture\"\n```\n\nComplete only after a passing checkpoint:\n\n```sh\nomx performance-goal complete --slug startup-latency --evidence \"final evaluator evidence\" --codex-goal-json <get_goal-json-or-path>\n```\n\n## Agent Loop\n\n1. Run `omx performance-goal create` if no workflow exists.\n2. Run `omx performance-goal start` and follow the handoff:\n - call `get_goal`;\n - call `create_goal` only when no active goal exists and the objective is explicit;\n - work only against the evaluator contract;\n - after evaluator pass and completion audit, call `update_goal({status: \"complete\"})`, call `get_goal` again, and pass that snapshot to `omx performance-goal complete --codex-goal-json`;\n - after `omx performance-goal complete` succeeds, run `/goal clear` in the Codex UI before starting another goal in this same thread/session; OMX prints this terminal cleanup step but does not invoke hidden clear routes;\n3. Optimize in small reversible patches.\n4. Run the evaluator and related regression tests.\n5. Record each pass/fail/blocker with `checkpoint`.\n6. Complete only when the pass artifact exists and no required work remains.\n\n## Completion Gate\n\nA performance goal is incomplete unless `.omx/goals/performance/<slug>/state.json` contains a `lastValidation.status` of `pass` and `omx performance-goal complete` receives a matching complete Codex `get_goal` snapshot via `--codex-goal-json`. Passing ordinary tests alone is not sufficient unless they are the declared evaluator contract.\n\nLifecycle: `create_goal` starts the Codex thread goal, `update_goal({status: \"complete\"})` marks terminal success after the evaluator and audit pass, and `/goal clear` removes the completed thread goal when another same-thread goal is needed. OMX shell commands and hooks reconcile snapshots and print the cleanup instruction; they must not mutate hidden Codex goal state.\n\n<!-- File: plugins/oh-my-codex/skills/plan/SKILL.md (Tokens: ~906 | Category: anthropic-skill) -->\n---\nname: plan\ndescription: Lightweight planning with optional interview\n---\n\n<Purpose>\nPlan creates concise, actionable work plans. Auto-detects interview vs direct, supports `--interview` for Socratic clarification and `--review` for evaluation.\n</Purpose>\n\n<Use_When>\n- Planning before implementation — \"plan this\", \"let's plan\"\n- Requirements are vague and need scoping — use `--interview`\n- Reviewing an existing plan — `--review`\n</Use_When>\n\n<Do_Not_Use_When>\n- Want direct execution — execute the scoped task directly; use `ultragoal` only for durable goals or `team` for coordinated parallel work\n- Simple focused fix with obvious scope — skip planning\n</Do_Not_Use_When>\n\n<Execution_Policy>\n- Auto-detect interview vs direct; `--interview` forces Socratic mode, `--direct` skips it\n- Ask one question at a time; gather codebase facts first\n- `omx explore` is deprecated. Use normal repository inspection for codebase facts; `omx sparkshell` only for explicit shell-native evidence\n- Plans must be evidence-backed: 80%+ claims cite file/line, 90%+ criteria testable\n- Right-size steps to scope; save to `.omx/plans/`\n</Execution_Policy>\n\n<Steps>\n\n### Mode Selection\n| Mode | Trigger | Behavior |\n|------|---------|----------|\n| Interview | `--interview` or broad request | Socratic requirements gathering |\n| Direct | `--direct` or detailed request | Generate plan immediately |\n| Review | `--review` | Critic evaluation of existing plan |\n\n### Interview (`--interview`)\n1. Classify request; ask one focused question via `omx question`\n2. Gather codebase facts first, then ask informed follow-ups\n3. Build on answers; consult Analyst for hidden requirements\n4. Create plan when user signals readiness\n\n### Direct\n1. Quick analysis (optional Analyst)\n2. Generate plan immediately\n3. Optional Critic review if requested\n\n### Review (`--review`)\n1. Read plan from `.omx/plans/`\n2. Evaluate via Critic; verdict APPROVED/REVISE/REJECT\n3. If author == reviewer, hand off to `$code-review`\n\n### Output\nEvery plan includes: Requirements Summary, Acceptance Criteria (testable), Implementation Steps (with file refs, adaptive count), Risks/Mitigations, Verification. Saved to `.omx/plans/`.\n\nOutcome-first framing: apply outcome-first framing, concise visible updates for multi-step planning. Local overrides for the active workflow branch apply via newer user task updates. If the user says `continue`, continue the current branch instead of restarting.\n\n</Steps>\n\n<Tool_Usage>\n- `omx explore` is deprecated. Use normal repository inspection; `omx sparkshell` only for explicit shell-native evidence\n- Use `omx question` for interview questions; plain text only as fallback\n- Use `ask_codex` with `planner`/`analyst`/`critic` as needed\n</Tool_Usage>\n\n<Escalation_And_Stop_Conditions>\n- Stop interviewing when requirements are clear — do not over-interview\n- Escalate on irreconcilable trade-offs requiring business decision\n- \"just do it\" / \"skip planning\" → hand off to `$ultragoal`\n</Escalation_And_Stop_Conditions>\n\n<Final_Checklist>\n- [ ] Acceptance criteria testable (90%+ concrete)\n- [ ] Claims cite file/line (80%+)\n- [ ] Risks have mitigations, no vague terms\n- [ ] Plan saved to `.omx/plans/`\n</Final_Checklist>\n\n<Advanced>\n## Question Classification\n| Type | Examples | Action |\n|------|----------|--------|\n| Codebase Fact | \"Where is X?\" | Explore first, do not ask |\n| User Preference | \"Priority?\" | Ask via `omx question` |\n| Scope Decision | \"Include Y?\" | Ask user |\n\n## Review Quality Criteria\n| Criterion | Standard |\n|-----------|----------|\n| Clarity | 80%+ claims cite file/line |\n| Testability | 90%+ criteria concrete |\n| Verification | File refs exist |\n</Advanced>\n\n<!-- File: plugins/oh-my-codex/skills/ralplan/SKILL.md (Tokens: ~3558 | Category: anthropic-skill) -->\n---\nname: ralplan\ndescription: Consensus planning stage for Planner -> Architect -> Critic handoff to $ultragoal\n---\n\n# Ralplan (Consensus Planning Alias)\n\nRalplan is the canonical consensus-planning stage used by Autopilot between `$deep-interview` and `$ultragoal`. It drives Planner, Architect, and Critic planning and records their review lifecycle with **RALPLAN-DR structured deliberation** (short mode by default, deliberate mode for high-risk work). Local lifecycle evidence is not host-issued security authority, but ordinary progression to Ultragoal must remain reachable after the execution-ready plan and sequential review evidence are durable; missing host provenance must not terminalize Ralplan or block cancel, clear, or recovery.\n\n## Usage\n\n```\n$ralplan \"task description\"\n```\n\nStandalone advisory planning is explicitly opt-in:\n\n```text\n$ralplan --advisory \"task description\"\n```\n\nAdvisory runs the same sequential Planner → Architect → Critic review lifecycle, binds the plan and both review artifacts to exact bytes and one tracker-backed iteration, then returns to the caller with `active:false`. It is a cooperative workflow pause, not a security fence or permission system. It never emits a `PreToolUse` allow/block decision, never completes the host consensus gate, never authorizes execution, and never suppresses unrelated host behavior. Terminal state must carry explicit `false` values for the consensus gate, host verification, and execution handoff rather than omitting them. A later concrete affirmative execution request may produce non-authoritative routing context, but it does not persist a permission, rewrite terminal evidence, or create an automatic handoff; quotations, code, examples, documentation, questions, modal requests, negations, and vague approval remain classifier negatives. `approved+proven` requires complete lifecycle digests plus post-write revalidation. Administrative abandonment is append-only, idempotent for prepared or committed journals, and records a separate byte-bound admin event without rewriting the original closeout journal. Real enforcement requires an explicit host-issued, host-verified receipt or capability on a non-user-mintable surface; local Advisory files, prompts, session/thread fields, tracker records, and HERDR observability cannot substitute for it. On Darwin, each Advisory evidence artifact is limited to 128 KiB by the pinned-directory reader; other supported platforms allow up to 8 MiB.\n\n## Flags\n\n- `--interactive`: Enables user prompts at key decision points (draft review in step 2 and final approval in step 6). Without this flag the workflow runs fully automated — Planner → Architect → Critic loop — and outputs the final plan without asking for confirmation.\n- `--deliberate`: Forces deliberate mode for high-risk work. Adds pre-mortem (3 scenarios) and expanded test planning (unit/integration/e2e/observability). Without this flag, deliberate mode can still auto-enable when the request explicitly signals high risk (auth/security, migrations, destructive changes, production incidents, compliance/PII, public API breakage).\n- `--advisory`: Standalone only. It cannot be combined with Autopilot, Pipeline, Team, Ralph, Ultragoal, execution flags, or unknown flags. Activation requires canonical session, root thread, and turn identity.\n\n## Ontology-heavy review\n\nFor requirements semantics, taxonomy, prompt/spec design, policy distinctions, or category-risk architecture, cite the `architect` role agent's read-only review as advisory evidence. Its findings can inform the plan or follow-up evidence when explicitly used, but `$ralplan` itself records Architect→Critic lifecycle evidence only, and advisory review is never a durable execution authorization.\n\n## Usage with interactive mode\n\n```\n$ralplan --interactive \"task description\"\n```\n\n## Behavior\n\n## GPT-5.6 Guidance Alignment\n\nUse the shared workflow guidance pattern: outcome-first framing, concise visible updates for multi-step planning, local overrides for the active workflow branch, evidence-backed planning and validation expectations, explicit stop rules, right-sized implementation/PRD shape, and automatic continuation for safe reversible steps. Ask only for material, destructive, credentialed, external-production, or preference-dependent branches.\n\nThis skill runs its own consensus runtime; it does not delegate to a nonexistent Plan consensus mode:\n\n```\nomx ralplan run --task <arguments> [--session <id>]\n```\n\nThe consensus workflow:\n1. **Planner** creates an adaptive plan (right-sized to task scope; do not default to exactly five steps) and a compact **RALPLAN-DR summary** before review. Current `[main]` vs `[planner]` behavior: standalone `$ralplan` may be authored by the active main planning lane unless the caller/runtime supplies a dedicated planner routing record; inside `$autopilot`, state field `planning_routing.owner:\"planner\"` means the initial Planner draft/decomposition must use dedicated `[planner]`. Set `.omx-config.json` `agentModels.planner` to opt into a specific planner model and force dedicated planner ownership for complex Autopilot planning even when `[main]` is not cheap/mini. The RALPLAN-DR summary includes:\n - Principles (3-5)\n - Decision Drivers (top 3)\n - Viable Options (>=2) with bounded pros/cons\n - If only one viable option remains, explicit invalidation rationale for alternatives\n - Deliberate mode only: pre-mortem (3 scenarios) + expanded test plan (unit/integration/e2e/observability)\n2. **User feedback** *(--interactive only)*: If `--interactive` is set, use the structured question UI (`omx question` in attached tmux; native structured input outside tmux when available) to present the draft plan **plus the Principles / Drivers / Options summary** before review (Proceed to review / Request changes / Skip review). Otherwise, automatically proceed to review.\n**Native role-routing preflight:** Keyword routing may already have selected Ralplan, but it is not authority. Run `omx ralplan preflight --json` only when the native task surface reports `role_routing_unavailable` and this workflow attempts adapted Ralplan Planner, Architect, or Critic authority, adapted role-intent, or adapted consensus authority. On `unsupported_documented_leader_proof`, stop before that adapted authority and use a Codex surface with documented root proof or a reviewed alternative workflow. Do not infer root identity from `session_id`, undocumented `thread_id`, session/pointer/transcript/cwd state, absence of child data, or a prompt label. Ordinary native planning, lifecycle, state, status, health, HUD, runtime, setup, install, sync, and unrelated delegation are outside this preflight boundary and remain governed by existing controls.\n\n**Native role-routing rule:** When the native surface exposes `agent_type` role routing, set `agent_type` to an installed OMX role and never omit it for OMX work. When it does not (`role_routing_unavailable`), do not fabricate `agent_type`. On the exact reviewed Codex releases 0.144.5, 0.145.0, 0.146.1, and 0.148.0-alpha.5, adapted Ralplan Planner, Architect, Critic, role-intent, and consensus authority are unavailable because they lack documented root proof; every other version remains unknown and fails closed. Do not silently weaken routing with a prompt role label or inferred carrier. Use a Codex surface with documented root proof or a reviewed alternative workflow for that authority. A direct `omx ralplan role-intent write` attempt is denied with machine reason `unsupported_documented_leader_proof`.\n\n3. **Architect** reviews for architectural soundness and must provide the strongest steelman antithesis, at least one real tradeoff tension, and (when possible) synthesis — **await completion before step 4**. Launch this as a subsequent role-specific `Architect` subagent and pass the full task statement, context snapshot, PRD/test-spec paths, and relevant prior findings; do not substitute an unvalidated reviewer identity or a short improvised reviewer prompt. In deliberate mode, Architect should explicitly flag principle violations.\n4. **Critic** evaluates against quality criteria — run only after step 3 completes. Launch this as a subsequent role-specific `Critic` subagent with the full task statement, context snapshot, PRD/test-spec paths, and the completed Architect review; do not ask the Architect subagent to perform the Critic gate and do not substitute an unvalidated reviewer identity or a short improvised reviewer prompt. Critic must enforce principle-option consistency, fair alternatives, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. In deliberate mode, Critic must reject missing/weak pre-mortem or expanded test plan.\n5. **Re-review loop** (max 5 iterations): Any non-`APPROVE` Critic verdict (`ITERATE` or `REJECT`) MUST run the same full closed loop:\n a. Collect Architect and Critic feedback\n b. Revise the plan with Planner\n c. Return to Architect review\n d. Return to Critic evaluation\n e. Repeat this loop until Critic returns `APPROVE` or 5 iterations are reached\n f. If 5 iterations are reached without `APPROVE`, present the best version to the user\n6. On Critic approval, persist the execution-ready planning artifacts and sequential Architect→Critic evidence. In standalone interactive Ralplan, present the requested future execution lane. Inside Autopilot, the existing explicit `$autopilot` invocation authorizes the supervised transition to its defining next stage, `$ultragoal`; persist an Autopilot-owned `ralplan_execution_handoff` bound to the same session and review cycle.\n7. Record `ralplan_execution_handoff` with `{authorized: true, reason, authorized_at, session_id, review_cycle, source: \"autopilot\"|\"user\"}`. `source:\"autopilot\"` is valid only for a supervised active Autopilot run whose current phase is `ralplan`; it does not claim host-consensus authority.\n8. Transition to `$ultragoal` after the durable plan, sequential approvals, and bound execution handoff exist. Do not implement directly inside Ralplan.\n\n> **Important:** Steps 3 and 4 MUST run sequentially as role-specific subagents. Do NOT issue both agent calls in the same parallel batch. Always await the subsequent `Architect` result before invoking the subsequent `Critic`; their completed approvals establish local lifecycle evidence only and cannot satisfy the durable execution gate.\n\n## Planning/Execution Boundary\n\n`$ralplan` is a planning mode. While ralplan is active and no explicit execution handoff is active, implementation-focused write tools are out of scope. Ralplan may inspect the repository and may write only planning artifacts such as `.omx/context/`, `.omx/plans/`, `.omx/specs/`, and required `.omx/state/` records.\n\nThe canonical flow is:\n\n```\n$ralplan -> local Architect→Critic lifecycle evidence -> bound execution handoff -> $ultragoal\n```\n\nBefore any execution lane begins, ralplan must emit terminal planning state (complete, paused, failed, or waiting for input) and the durable handoff record below. Do not continue from consensus planning into direct code edits in the same ralplan session.\n\n## Durable Consensus Handoff Contract\n\nRalplan is not complete, skippable, or ready for execution merely because `.omx/plans/prd-*.md` and `.omx/plans/test-spec-*.md` exist. Those files are planning artifacts, not consensus evidence.\n\nBefore any Autopilot, Ultragoal, Team, or implementation handoff, persist a durable handoff record that distinguishes:\n\n- `planning_artifacts`: PRD/test-spec paths.\n- `ralplan_architect_review`: the completed Architect review with an approving verdict.\n- `ralplan_critic_review`: the completed Critic review with an approving verdict, recorded only after the Architect review.\n- `ralplan_execution_handoff`: persist `{authorized: true, reason: \"<rationale>\", authorized_at: \"<ISO timestamp>\", session_id: \"<current session>\", review_cycle: <matching lifecycle cycle>, source: \"autopilot\"|\"user\"}`. Autopilot may issue this only for its own supervised `ralplan` phase; standalone Ralplan uses `source:\"user\"`.\n- `ralplan_consensus_gate.complete` records lifecycle completion after the sequential Architect and Critic approvals. It is not a host-security claim. Locally authored JSON/env/prompt/tracker/transcript/receipt-shaped evidence must never be described as host-issued authority.\n\nIf Architect is missing/blocked, keep the workflow in Architect review or report that blocker. If Critic is missing/blocked/non-approving, keep the workflow in Critic/re-review or report the max-iteration outcome. After both reviews approve, execution begins only when the matching `ralplan_execution_handoff` is durable. Existing plan/test-spec files alone are never permission to skip Ralplan or execute.\n\nFollow the Plan skill's full documentation for consensus mode details.\n\n## Goal-Mode Follow-up Suggestions\n\nWhen a bound `ralplan_execution_handoff` permits execution, include product-facing goal-mode suggestions alongside coordinated Team execution. Record the requested lane and persist the handoff without claiming host-issued authority.\n\n- `$ultragoal` — **default goal-mode follow-up** for implementation or general goal-oriented follow-up plans that should become durable Codex/OMX goals with sequential completion tracking.\n- `$autoresearch` — research-project follow-up when the plan centers on a question, literature/reference gathering, evaluator-backed research, or a professor/critic-style research deliverable. (`$autoresearch-goal` was retired to a sunset stub in OMX 0.21.)\n- `$performance-goal` — optimization/performance follow-up when the plan centers on speed, latency, throughput, memory, benchmark, or other measurable performance work.\n\nUse `$ultragoal` for durable goal tracking and `$team` for coordinated parallel implementation. When combined, Ultragoal owns the ledger and Team returns checkpoint-ready execution evidence.\nUse the available-agent-types roster to produce explicit role/staffing allocation, reasoning-by-lane guidance, concrete launch hints (including `omx team` when parallel delivery is justified), and team verification responsibilities for any future receipt-authorized execution path.\n\n## Pre-context Intake\n\nBefore consensus planning or execution handoff, ensure a grounded context snapshot exists:\n\n1. Derive a task slug from the request.\n2. Reuse the latest relevant snapshot in `.omx/context/{slug}-*.md` when available.\n3. If none exists, create `.omx/context/{slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`) with:\n - task statement\n - desired outcome\n - known facts/evidence\n - constraints\n - unknowns/open questions\n - likely codebase touchpoints\n4. If ambiguity remains high, gather brownfield facts first. `omx explore` is deprecated; use normal repository inspection tools/subagents for simple read-only repository lookups and `omx sparkshell` only for explicit shell-native read-only evidence. Then run `$deep-interview --quick <task>` before continuing.\n5. If the plan depends on official docs, version-aware framework guidance, best practices, or external dependency behavior, use `$best-practice-research` as the bounded evidence wrapper and auto-delegate `researcher` for the official/upstream lookup before finalizing the planning handoff so execution does not start from repo-local recall alone.\n6. If a prior `$autoresearch` run exists, treat its approved artifact as evidence for the plan. Read historical artifacts from `$autoresearch-goal` only as compatibility input. Do not include Autoresearch as a final architecture or runtime component unless the user explicitly requested ongoing research automation; otherwise synthesize the evidence into the `$ralplan` ADR, risks, and verification steps.\n\nDo not hand off to execution modes until this intake is complete; if urgency forces progress, explicitly document the risk tradeoffs.\n\n## Routing boundary\n\nOrdinary scoped tasks stay in the direct execution lane described by `templates/AGENTS.md`.\nExplicit workflow requests follow the keyword registry (`src/hooks/keyword-registry.ts`) and their owning skill contracts; this card does not define a second activation table.\nOnce Ralplan is active, preserve the planning/execution and consensus handoff requirements above. A conversational “just do it” is not a substitute for the required review evidence.\n\n## Scenario Examples\n\n**Good:** The user says `continue` after the workflow already has a clear next step. Continue the current branch of work instead of restarting or re-asking the same question.\n\n**Good:** The user changes only the output shape or downstream delivery step (for example `make a PR`). Preserve earlier non-conflicting workflow constraints and apply the update locally.\n\n**Bad:** The user says `continue`, and the workflow restarts discovery or stops before the missing verification/evidence is gathered.\n\n<!-- File: plugins/oh-my-codex/skills/skill/SKILL.md (Tokens: ~1098 | Category: anthropic-skill) -->\n---\nname: skill\ndescription: Manage local skills - list, add, remove, search, edit, setup wizard\nargument-hint: \"<command> [args]\"\n---\n\n# Skill Management\n\nManage local `SKILL.md` files with `/skill` commands. Shared execution, delegation,\nstate, hook, team, cancellation, verification, and escalation invariants live in\n`templates/AGENTS.md`; follow that contract instead of repeating it here.\n\n<Purpose>\nCreate, inspect, validate, update, and organize user- or project-scoped skills.\nKeep each skill specific, actionable, evidence-based, and useful to this codebase.\n</Purpose>\n\n<Use_When>\n- The user asks to list, add, edit, remove, search, inspect, sync, set up, scan, or validate skills.\n- A durable, codebase-specific solution or workflow should be captured as a skill.\n</Use_When>\n\n<Do_Not_Use_When>\n- Use `/learner` to extract a skill from a conversation and `/note` for a short note.\n- Do not use this prompt to change runtime code, catalogs, hooks, or installation logic.\n</Do_Not_Use_When>\n\n## Scopes and commands\n\nCanonical roots are `${CODEX_HOME:-$HOME/.codex}/skills/` (user) and `.codex/skills/`\n(project). A skill lives at `<root>/<name>/SKILL.md`.\n\n| Command | Contract |\n|---|---|\n| `/skill list` | Scan both roots, parse frontmatter, and show name, description, triggers, scope, and quality/usage (`N/A` when unavailable). |\n| `/skill add [name]` | Run the authoring wizard, validate the name, choose scope, create `SKILL.md`, and report its path. |\n| `/skill edit <name>` | Find one scope, show metadata, then update description, triggers, argument hint, body, or rename and report the change. |\n| `/skill remove <name>` | Find the skill, show scope and metadata, confirm explicitly, then remove its directory. |\n| `/skill search <query>` | Case-insensitively search name, description, triggers, and body; rank name/trigger matches first and show context. |\n| `/skill info <name>` | Show parsed metadata, scope, path, and full body; suggest `/skill search` when absent. |\n| `/skill sync` | Compare user/project skills, show user-only/project-only/common entries, and confirm every copy or overwrite. |\n| `/skill setup` | Ensure both roots exist, scan them, then offer add, list, pattern scan, import, or done. |\n| `/skill scan` | Run setup's scan/inventory without its interactive menu. |\n| `/skill validate` | Validate every skill in both roots and report each path's pass/fail result; never rewrite files. |\n\nWith an argument, use direct command mode; without one, use the guided setup menu.\n\n## Authoring contract\n\nAsk for any missing values:\n1. `name`: lowercase letters/digits separated by single hyphens (`[a-z0-9]+(?:-[a-z0-9]+)*`).\n2. `description`: a concise, non-empty one-line purpose.\n3. `triggers`: comma-separated recognition terms.\n4. `argument-hint`: optional invocation arguments.\n5. `scope`: `user` or `project`.\n\nWrite this frontmatter at the start of every skill; optional metadata may add `id`,\n`source`, and `quality` without replacing required fields:\n\n```yaml\n---\nname: <name>\ndescription: <one-line purpose>\ntriggers: [<trigger1>, <trigger2>]\nargument-hint: \"<args>\"\n# optional: id, source, quality\n---\n```\n\nUse an actionable body. The minimum recommended shape is:\n\n```markdown\n# <Skill title>\n\n## Purpose\nWhat durable, codebase-specific outcome does this skill provide?\n\n## When to Activate\nRecognition signals, scope, and explicit non-goals.\n\n## Workflow\n1. Inspect the named files or inputs.\n2. Apply the precise approach and record important assumptions.\n3. Verify observable behavior and report evidence.\n\n## Examples / Gotchas\nConcrete invocation, edge cases, and failure recovery.\n```\n\nPrefer hard-won, non-obvious knowledge over generic programming advice. Include\nexact paths, commands, error text, and expected evidence when they materially help.\n\n## Validation and errors\n\nBefore reporting success, check that the file exists, starts with `---` frontmatter,\nhas non-empty `name` and `description`, uses a valid name, and has a non-empty body.\nReject malformed or unterminated YAML, multiline required scalar values, duplicate\nnames in one scope, missing directories/files, permission failures, and invalid\narguments. Report errors consistently:\n\n```text\n✗ Error: <clear message>\n→ Suggestion: <specific next step>\n```\n\n## Exit contract\n\nEvery command ends with one concise result: `✓` plus the affected skill/path and\nnext action, or `✗` plus the error and suggestion. Preserve files on cancel or\nvalidation-only runs. For add/edit/sync, report changed scope and metadata; for\nlist/search/info/scan/validate, report counts or matched paths and any failures.\n\n<!-- File: plugins/oh-my-codex/skills/team/SKILL.md (Tokens: ~1092 | Category: anthropic-skill) -->\n---\nname: team\ndescription: N coordinated agents on shared task list using tmux-based orchestration\n---\n\n# Team Skill\n\n## When to use\n\nUse only for an explicit `$team` request or `omx team ...` launch that benefits from durable tmux workers, shared task state, mailbox coordination, or worktree isolation. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot`; do not copy its durable rules into this card.\n\n## Inputs and preconditions\n\n- Launch shape: `omx team [N:agent-type] \"<task>\"` (for example `omx team 3:executor \"implement X\"`).\n- Require `tmux -V`, a leader session with `$TMUX`, and the intended `omx` executable. In Codex App/plain non-tmux sessions, explain the runtime boundary instead of pretending Team is available.\n- Before launch, ground the task in a recent `.omx/context/{slug}-*.md`; create a concise snapshot when none exists. Include target, evidence, constraints, unknowns, and likely touchpoints.\n- Do not launch nested Team runs. Pick worker roles deliberately; use `OMX_TEAM_WORKER_CLI=codex|claude|auto` or `OMX_TEAM_WORKER_CLI_MAP=...` only when needed.\n- Per-agent reasoning is set by `agentReasoning`; accepted values are `low`, `medium`, `high`, `xhigh`, and `max`. `max` is passed unchanged and remains capability-dependent. `ultra` is unsupported and is not an alias for `max`.\n- Invalid configured values use the built-in role-default fallback. An explicit raw `-c model_reasoning_effort=...` is opaque and wins. When both sources are present, explicit raw reasoning wins over inherited Team reasoning and environment reasoning. Do not downgrade or retry `max` as `xhigh`; built-in role defaults remain unchanged.\n\n## Operational steps\n\n1. Start the runtime and capture startup evidence: `Team started: <name>`, tmux target, worker panes, and the leader ACK mailbox.\n2. **Current Runtime Behavior:** runtime-owned task files and APIs are the operational interface; the durable ownership and safety rules remain in `templates/AGENTS.md`.\n3. Runtime creates `.omx/state/team/<name>/config.json`, `manifest.v2.json`, `tasks/task-<id>.json`, worker identities/inboxes, mailbox files, and a dispatch queue. Workers receive `OMX_TEAM_WORKER`, `OMX_TEAM_STATE_ROOT`, and `OMX_TEAM_LEADER_CWD`.\n4. Deliver assignments through durable inbox/task state and the CLI API. The worker card defines ACK, claim, transition, mailbox, and idle-status commands.\n5. Prefer these machine-readable operations:\n ```bash\n omx team api send-message --input '{\"team_name\":\"<name>\",\"from_worker\":\"leader-fixed\",\"to_worker\":\"worker-1\",\"body\":\"<short trigger>\"}' --json\n omx team api read-task --input '{\"team_name\":\"<name>\",\"task_id\":\"<id>\"}' --json\n omx team api transition-task-status --input '{\"team_name\":\"<name>\",\"task_id\":\"<id>\",\"from\":\"in_progress\",\"to\":\"completed\",\"claim_token\":\"<token>\"}' --json\n ```\n6. Monitor with `omx team status <name> --json` or `omx team await <name> --timeout-ms 30000 --json`; inspect mailbox/state files when a worker is blocked or stale.\n7. Keep the team running until `pending=0`, `in_progress=0`, and `failed=0` (or an explicitly acknowledged failure path). Run `omx team shutdown <name>` only then, unless the user explicitly aborts.\n8. Verify shutdown evidence and state cleanup. Do not claim completion while workers are still writing.\n\n## Team and Ultragoal\n\nWhen a leader-owned `.omx/ultragoal/goals.json` exists, workers return task evidence only. The leader checkpoints with a fresh Codex `get_goal` snapshot:\n```bash\nomx ultragoal checkpoint --goal-id <id> --status complete --evidence \"<Team evidence>\" --codex-goal-json <fresh-get-goal-json-or-path>\n```\nTeam launch remains an explicit separate action; it does not create hidden Codex goals.\n\n## Dispatch and recovery\n\n- If dispatch reports `worker_notify_failed:<worker>`, inspect `tmux list-panes`, capture the pane, then send one concise trigger and re-check mailbox/state.\n- For Claude panes, do not spam Enter while work is active. Confirm runtime status first.\n- If a worker reports `omx team api ... ENOENT`, check whether shutdown or state deletion happened too early; preserve state until all transitions finish.\n- For a clean retry, kill only known stale worker panes, remove only the exact stale Team root, and relaunch; never kill the leader/HUD pane accidentally.\n\n## Exit and evidence\n\nReport team name, launch command, pane/ACK evidence, task counts, worker verification, failures or blockers, shutdown result, and cleaned state paths. Include any worktree or CLI-map choices and keep final integration/verification in the leader lane.\n\n<!-- File: plugins/oh-my-codex/skills/ultragoal/SKILL.md (Tokens: ~1081 | Category: anthropic-skill) -->\n---\nname: ultragoal\ndescription: Create and execute durable repo-native multi-goal plans over Codex goal mode artifacts.\n---\n\n# Ultragoal Workflow\n\n## When to use\n\nUse for `ultragoal`, `create-goals`, `complete-goals`, durable multi-goal planning, or sequential execution over Codex `/goal`. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot` for state ownership and goal-tool boundaries.\n\n## Inputs and preconditions\n\n- Durable artifacts are `.omx/ultragoal/brief.md`, `.omx/ultragoal/goals.json`, and `.omx/ultragoal/ledger.jsonl`.\n- New plans use aggregate Codex goal mode by default: one stable pointer objective for the plan while OMX tracks individual stories. Use `--codex-goal-mode per-story` only when explicitly requested.\n- Do not call `/goal clear` from shell or this skill. After a completed run, the operator may clear the interactive Codex goal in the Codex UI before another same-thread run.\n\n## Operational steps: create\n\nRun one command, then inspect the generated plan:\n```bash\nomx ultragoal create-goals --brief \"<brief>\"\nomx ultragoal create-goals --brief-file <path>\ncat <brief> | omx ultragoal create-goals --from-stdin\nomx ultragoal create-goals --codex-goal-mode per-story --brief \"<brief>\"\n```\nIf refinement is needed, use explicit supported steering rather than editing durable artifacts by hand.\n\n## Operational steps: execute\n\nRepeat until `omx ultragoal status` reports all goals complete:\n\n1. Run `omx ultragoal complete-goals` and read its handoff.\n2. Call `get_goal`. Call `create_goal` with the printed payload only when no active Codex goal exists; otherwise continue the matching aggregate objective.\n3. Complete one OMX story and audit its objective against real artifacts and verification evidence.\n4. For intermediate aggregate stories, keep the Codex goal active and checkpoint:\n ```bash\n omx ultragoal checkpoint --goal-id <id> --status complete --evidence \"<evidence>\" --codex-goal-json <fresh-get-goal-json-or-path>\n ```\n5. For a blocked/failed story, use `--status blocked|failed` with evidence; resume failed work with `omx ultragoal complete-goals --retry-failed`.\n6. On the final story, complete the final gate below before `update_goal({status: \"complete\"})`; then call `get_goal` again and checkpoint the fresh complete snapshot.\n\n## Explicit steering\n\nUse evidence-backed directives only when the decomposition must change:\n```bash\nomx ultragoal steer --kind add_subgoal --title \"<title>\" --objective \"<objective>\" --evidence \"<evidence>\" --rationale \"<reason>\" --json\nomx ultragoal steer --directive-json ./steering.json --json\n```\nSupported kinds: `add_subgoal`, `split_subgoal`, `reorder_pending`, `revise_pending_wording`, `annotate_ledger`, and `mark_blocked_superseded`. Ordinary prose does not mutate the plan; repeated structured directives dedupe.\n\n## Phase/HUD handoff\n\nAt standalone activation, declare the smallest accurate phase (`planning`, `executing`, `verifying`, `reviewing`, `checkpointing`, or `blocked`):\n```bash\nomx state write --input '{\"mode\":\"ultragoal\",\"active\":true,\"current_phase\":\"planning\"}' --json\n```\nInside Autopilot, keep the parent mode active and set `current_phase:\"ultragoal\"`; persist Ultragoal evidence under `handoff_artifacts.ultragoal` before a code-review handoff. Mark standalone Ultragoal complete only when every durable goal is complete.\n\n## Optional Team bridge\n\nFor parallel story execution, use the separate Team command. The leader records the Ultragoal checkpoint with a fresh `get_goal` snapshot; see the Team skill for the bridge details.\n\n## Final gate and exit evidence\n\nBefore final completion:\n\n1. Run targeted story verification.\n2. Run `ai-slop-cleaner` on changed files, then rerun verification.\n3. Audit every architecture/domain invariant from the brief/spec/accepted steering against implementation, test, and review evidence.\n4. Run `$code-review` through independent `code-reviewer` and `architect` lanes. If review or invariant proof is not clean, do not update the Codex goal; record durable blockers:\n ```bash\n omx ultragoal record-review-blockers --goal-id <id> --title \"Resolve final code-review blockers\" --objective \"<objective>\" --evidence \"<findings>\" --codex-goal-json <active-get-goal-json-or-path>\n ```\n5. If clean, call `update_goal({status: \"complete\"})`, call `get_goal`, and checkpoint with `--quality-gate-json` containing cleaner, verification, review, and architecture-invariant evidence.\n\nReport goal ids/statuses, ledger/checkpoint paths, fresh goal snapshot evidence, review verdicts, and any blocker. Never claim completion from OMX state alone.\n\n<!-- File: plugins/oh-my-codex/skills/ultraqa/SKILL.md (Tokens: ~1472 | Category: anthropic-skill) -->\n---\nname: ultraqa\ndescription: Adversarial dynamic e2e QA workflow - generate hostile scenarios, test, verify, fix, report, and clean up\n---\n\n# UltraQA Task Card\n\nUse this explicit opt-in when a runnable behavior needs adversarial dynamic end-to-end\nQA. Shared operating invariants live in `templates/AGENTS.md`; this card defines the\nQA matrix, evidence contract, and bounded cycling only.\n\n## When to use and inputs\n\n- Use `/ultraqa --tests|--build|--lint|--typecheck|--interactive` or `/ultraqa --custom \"pattern\"` for the corresponding goal; without a structured goal, derive a runnable behavior goal.\n- Inputs: goal, changed scope, acceptance criteria, runnable command/service, existing tests, and relevant state/cleanup paths.\n- Keep outcome-first framing, local overrides for the active workflow branch, and `continue` on the current verified next step.\n- If the user says `continue`, advance the current verified QA step rather than restarting discovery.\n- UltraQA is not satisfied by a shallow build/lint/typecheck/test checklist: exercise requested behavior through adversarial dynamic e2e scenarios whenever it can be run, simulated, or harnessed safely.\n\n## Plan and scenario matrix\n\nBefore commands, record a matrix with scenario id, intent, user/attacker model, setup,\ncommand or harness, expected signal, actual result, fixes, evidence, and cleanup.\nInclude a normal path and relevant hostile classes:\n\n1. **Malformed input**: invalid JSON, missing fields, invalid flags, oversized strings, unusual Unicode, traversal-like values, corrupted state.\n2. **Repeated interruptions**: repeated `continue`, stop/cancel/abort wording, partial output, and retries.\n3. **Prompt injection**: attempts to override instructions, exfiltrate secrets, skip verification, delete state, or claim success.\n4. **Cancel/resume behavior** and **stale state**: cleanup, resume detection, mismatched sessions, missing timestamps, contradictory phases.\n5. **Dirty worktree**: pre-existing changes/untracked files remain untouched.\n6. **Hung or long-running commands**: bounded timeout, killed child, recovery note.\n7. **Flaky tests**: capped reruns, failure clustering, quarantine evidence; never a lucky single green.\n8. **Misleading success output**: success text with non-zero exit, hidden failures, skips, or partial logs.\n\n## Cycle (maximum 5)\n\n1. **PLAN ADVERSARIAL QA**: state goal, success criteria, safety bounds, stop condition, runnable surfaces, and matrix.\n2. **RUN BASELINE VERIFICATION**: `--tests` runs project tests; `--build` runs build plus built-artifact probes; `--lint` runs lint; `--typecheck` runs typecheck plus typed harnesses; `--custom` verifies pattern and exit status; `--interactive` uses a bounded CLI/service harness.\n3. **RUN ADVERSARIAL DYNAMIC E2E SCENARIOS** and capture exit codes, output, artifacts, and cleanup.\n4. **CHECK RESULT**: pass only when baseline, adversarial scenarios, evidence, and cleanup all pass. Otherwise diagnose and fix, then repeat.\n5. **ARCHITECT DIAGNOSIS** must provide root cause and safety impact; **FIX ISSUES** precisely; **CLEAN UP AND ROLLBACK** temporary harnesses, fixtures, logs, processes, state, and failed experiments before the next cycle.\n\nGenerate temporary tests, scripts, fixtures, or harnesses only when useful. Use bounded runtimes,\nproject-native tools, and safe substitutes when a safety boundary blocks a scenario.\nUse absolute repo imports and `pathToFileURL(join(repoRoot, \"dist\", ...)).href`; Never rely on `./dist` from `/tmp`.\nUse a safe file writer with a non-interpolating file-write mechanism; do not use interpolating heredocs for JavaScript assertions.\nSanitize OMX runtime env for isolated probes: keep `OMX_ROOT` and `OMX_STATE_ROOT` unset and run `env -u OMX_ROOT -u OMX_STATE_ROOT`.\nClassify harness setup failures separately: record it as harness debris, fix the harness, and rerun the scenario before declaring a product defect.\n\n## Safety, state, and exit\n\nNo destructive commands, secret exfiltration, credential dumping, production writes, or unbounded process spawning. Use no unbounded waits; preserve unrelated dirty work. If a scenario is unsafe, record it blocked and the safe substitute. Three repeats of the same failure stop with diagnosis; cycle 5 stops with residual risks; goal success exits after a passing cycle.\n\nUse CLI-first lifecycle state and exact commands:\n\n```sh\nomx state write --input '{\"mode\":\"ultraqa\",\"active\":true,\"current_phase\":\"planning\",\"iteration\":1,\"started_at\":\"<now>\",\"scenario_matrix\":[]}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"current_phase\":\"qa\",\"iteration\":<cycle>,\"scenario_matrix\":\"<updated matrix path or summary>\"}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"current_phase\":\"adversarial-e2e\"}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"current_phase\":\"diagnose\"}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"current_phase\":\"fix\"}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"current_phase\":\"cleanup\"}' --json\nomx state write --input '{\"mode\":\"ultraqa\",\"active\":false,\"current_phase\":\"complete\",\"completed_at\":\"<now>\"}' --json\nomx state read --input '{\"mode\":\"ultraqa\"}' --json\nomx state clear --input '{\"mode\":\"ultraqa\"}' --json\n```\n\nOn completion, max cycles, same failure, safety boundary, or environment error, clean\nstate and temporary artifacts. Report cleanup status and clean temporary e2e harnesses.\nNever claim complete without current evidence.\n\n## Evidence/output contract\n\nReturn `# UltraQA Report` with: **Goal and success criteria** (including stop condition\nand safety bounds); **Scenario matrix** (all columns above); **Commands run** (exit code,\npurpose, timeout, key output); **Failures found** (root/user/safety impact); **Fixes\napplied** / **Fixes applied** (files, rationale, scenarios, regression evidence); **Cleanup and rollback**\n(artifacts/processes/worktree before/after); **Residual risks**; and **Evidence**\n(logs, harness output, screenshots/transcripts where relevant, rerun/flake evidence).\n\n## Exit condition\n\n`ULTRAQA COMPLETE: Goal met after N cycles` only follows a passing baseline plus\nadversarial matrix, clean artifacts, and complete evidence. Otherwise return the exact\nbounded status: `ULTRAQA STOPPED: Max cycles`, `ULTRAQA STOPPED: Same failure detected 3 times`,\n`ULTRAQA BLOCKED: ...`, or `ULTRAQA ERROR: ...` with owner and next safe step.\n\n<!-- File: plugins/oh-my-codex/skills/visual-ralph/SKILL.md (Tokens: ~1162 | Category: anthropic-skill) -->\n---\nname: visual-ralph\ndescription: \"Visual Ralph orchestration for frontend UI from generated references, static references, or live URL targets, using $ultragoal with built-in visual verdict and pixel-diff evidence until the implementation matches and leaves a reproducible design system.\"\n---\n\n# Visual Ralph Skill\n\nUse `$visual-ralph` for measured frontend implementation from an approved generated reference, static image, or live-URL baseline. The loop is:\n\n`description / URL -> approved reference -> $ultragoal implementation -> Visual Ralph verdict + pixel diff -> reusable design system`.\n\nFor URL cloning, this skill owns the migrated `$web-clone` use case; preserve URL, viewport, fidelity, and interaction notes here. Do not invoke standalone `$web-clone`.\n\nShared operating, delegation, state, hook, team, cancellation, and verification invariants live in [`templates/AGENTS.md`](../../templates/AGENTS.md). Follow that source instead of duplicating its rules here.\n\n## Use when\n\n- The user wants a web/app UI built or restyled against a visual target.\n- A live URL or generated raster mockup needs measured implementation and pixel-level iteration.\n- The result must leave reusable repo-native tokens/components, not only a matching screenshot.\n\nDo not use it for a durable `DESIGN.md` brief (`$design`), non-visual backend work, comparison-only fixes that can be executed directly, or deterministic SVG/code-native assets.\n\n## Workflow\n\n### 1. Ground the repository\n\nInspect package manager/scripts, frontend framework and routes, styling/token conventions, screenshot tooling, and reusable components. Choose stack-specific commands only when repository evidence supports them.\n\n### 2. Establish a reference\n\nFor a live URL, capture or document an artifact containing source URL and permission/scope, viewport(s), route/state, seed/login assumptions, baseline screenshot path or capture command, visible-control parity notes, and exclusions (backend/API/auth, personalized data, crawling, third-party widgets).\n\nFor a generated concept, use `$imagegen` with classification `ui-mockup`, viewport/aspect ratio, surface, layout hierarchy, typography, color mood, exact text, no logos/watermarks/unrequested marks, and readable/feasible UI details. In OMX runtime, queue the continuation checkpoint before the built-in image tool:\n\n```bash\nomx imagegen continuation <session-id> --artifact <slug-or-filename> --generated-dir \"$CODEX_HOME/generated_images/<session>\" --work-dir \".omx/artifacts/visual-ralph/<slug>\"\n```\n\nCopy the approved reference into `.omx/artifacts/visual-ralph/<slug>/reference.png`; do not leave it only under `$CODEX_HOME/generated_images`.\n\n### 3. Approval gate\n\nStop after generation or URL capture and obtain approval of one reference image/state (or a targeted regeneration/capture adjustment). Before approval, do not implement or invoke `$ultragoal`. After approval, the image/baseline is the visual source of truth; major pivots require an explicit user request.\n\n### 4. Hand off to `$ultragoal`\n\nPass the approved reference/baseline, URL and permission note when applicable, viewport/content state, interaction parity and exclusions, user description, detected frontend context, screenshot command/viewport, and the completion checklist. The active Ultragoal execution lane edits, runs, captures, and iterates after approval until matched or blocked.\n\n### 5. Verdict before every edit\n\nFor each iteration, capture the current screenshot with viewport/state, run Visual Ralph verdict (using `vision` when needed), and treat its JSON as authoritative. If `score < 90`, turn `differences[]` and `suggestions[]` into the next edit plan and rerun before editing. Required verdict keys: `score`, `verdict`, `category_match`, `differences[]`, `suggestions[]`, `reasoning`.\n\n### 6. Secondary diff evidence\n\nUse pixel diff/pixelmatch overlays only to locate hotspots and translate them into edits; they never replace the verdict. Record final reference, screenshot, and diff artifacts for auditability.\n\n### 7. Reusable design system\n\nEncode the match in existing repo-native CSS variables, theme tokens, config, component variants, stories, or `DESIGN.md` updates. Capture applicable colors, spacing, typography/weights, radii, shadows/elevation, and important variants/states. Extend existing patterns rather than adding a parallel layer.\n\n## Completion evidence and stop conditions\n\nDo not declare done until the approved reference/baseline and reproduction command (viewport, route, state, output path) are saved; final verdict is `>= 90`; secondary diff evidence is recorded; reusable tokens/components exist; equivalent build/lint/test verification passes; no unapproved pivot occurred; and remaining differences are documented. Stop at the approval gate or report a concrete blocker when evidence cannot satisfy these conditions.\n\n## Handoff template\n\n```text\n$ultragoal \"Implement the approved frontend reference.\nReference: <workspace reference or URL-derived artifact>\nSource URL and permission/scope: <when applicable>\nViewport/content state: <viewport, route/state, seed/login assumptions>\nInteraction parity and exclusions: <visible controls and known limits>\nRoute/surface: <route or component>\nScreenshot command: <command and viewport>\nRun Visual Ralph verdict before every next edit; pass threshold >= 90.\nUse pixel diff only as secondary evidence.\nExtract reusable tokens/components for colors, spacing, typography, radii, shadows, and variants.\nRun the repository's equivalent verification before completion.\nDo not make major design pivots unless explicitly requested.\"\n```\n\nTask: {{ARGUMENTS}}\n\n<!-- File: plugins/oh-my-codex/skills/wiki/SKILL.md (Tokens: ~438 | Category: anthropic-skill) -->\n---\nname: wiki\ndescription: Persistent markdown project wiki stored under repository omx_wiki with keyword search and lifecycle capture\ntriggers: [\"wiki add\", \"wiki lint\", \"wiki query\", \"wiki read\", \"wiki delete\"]\n---\n\n# Wiki\n\nPersistent, self-maintained markdown knowledge base for project and session knowledge.\n\n## Operations\n\n### Ingest\n```bash\nomx wiki wiki_ingest --input '{\"title\":\"Auth Architecture\",\"content\":\"...\",\"tags\":[\"auth\",\"architecture\"],\"category\":\"architecture\"}' --json\n```\n\n### Query\n```bash\nomx wiki wiki_query --input '{\"query\":\"authentication\",\"tags\":[\"auth\"],\"category\":\"architecture\"}' --json\n```\n\n### Lint\n```bash\nomx wiki wiki_lint --json\n```\n\n### Quick Add\n```bash\nomx wiki wiki_add --input '{\"title\":\"Page Title\",\"content\":\"...\",\"tags\":[\"tag1\"],\"category\":\"decision\"}' --json\n```\n\n### List / Read / Delete\n```bash\nomx wiki wiki_list --json\nomx wiki wiki_read --input '{\"page\":\"auth-architecture\"}' --json\nomx wiki wiki_delete --input '{\"page\":\"outdated-page\"}' --json\nomx wiki wiki_refresh --json\n```\n\n## Categories\n`architecture`, `decision`, `pattern`, `debugging`, `environment`, `session-log`, `reference`, `convention`\n\n## Storage\n- Pages: `omx_wiki/*.md`\n- Index: `omx_wiki/index.md`\n- Log: `omx_wiki/log.md`\n\n## Cross-References\nUse `[[page-name]]` wiki-link syntax to create cross-references between pages.\n\n## Auto-Capture\nAt session end, discoveries can be captured as `session-log-*` pages. Configure via `wiki.autoCapture` in `.omx-config.json`.\n\n## Hard Constraints\n- No vector embeddings — query uses keyword + tag matching only\n- Wiki files are repository project knowledge under `omx_wiki/`; legacy `.omx/wiki/` is read-only compatibility input when no canonical wiki exists\n\n<!-- File: plugins/oh-my-codex/skills/worker/SKILL.md (Tokens: ~712 | Category: anthropic-skill) -->\n---\nname: worker\ndescription: Team worker protocol (ACK, mailbox, task lifecycle) for tmux-based OMX teams\n---\n\n# Worker Skill\n\n## When to use\n\nUse only when the session was started as an OMX Team worker. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot` before acting; it defines the durable ownership and coordination boundaries.\n\n## Inputs and preconditions\n\n- Require `OMX_TEAM_WORKER=<team-name>/worker-<n>`.\n- Resolve this skill from the first existing path:\n `${CODEX_HOME:-~/.codex}/skills/worker/SKILL.md`, `~/.codex/skills/worker/SKILL.md`, `<leader_cwd>/.codex/skills/worker/SKILL.md`, then `<leader_cwd>/skills/worker/SKILL.md`.\n- Resolve the Team state root in this order: `OMX_TEAM_STATE_ROOT`, worker identity `team_state_root`, config/manifest `team_state_root`, local `.omx/state`.\n\n## Operational steps\n\n1. Split the environment into `teamName` and `workerName`; Send a startup ACK before task work:\n ```bash\n omx team api send-message --input '{\"team_name\":\"<teamName>\",\"from_worker\":\"<workerName>\",\"to_worker\":\"leader-fixed\",\"body\":\"ACK: <workerName> initialized\"}' --json\n ```\n2. Read `<team_state_root>/team/<teamName>/workers/<workerName>/inbox.md` and take the first unblocked assignment.\n3. Read `<team_state_root>/team/<teamName>/tasks/task-<id>.json`; APIs use the bare numeric `task_id` (for example `\"1\"`).\n4. Claim before editing:\n ```bash\n omx team api claim-task --input '{\"team_name\":\"<teamName>\",\"task_id\":\"<id>\",\"worker\":\"<workerName>\"}' --json\n ```\n5. Do the assigned work. Do not write task lifecycle fields directly.\n6. Complete or fail through the lifecycle API, from `in_progress` to `completed` or `failed`:\n ```bash\n omx team api transition-task-status --input '{\"team_name\":\"<teamName>\",\"task_id\":\"<id>\",\"from\":\"in_progress\",\"to\":\"completed\",\"claim_token\":\"<token>\",\"result\":\"<evidence>\"}' --json\n ```\n Use `release-task-claim` only to requeue a blocked task to `pending`.\n7. Check and acknowledge mailbox messages:\n ```bash\n omx team api mailbox-list --input '{\"team_name\":\"<teamName>\",\"worker\":\"<workerName>\"}' --json\n omx team api mailbox-mark-delivered --input '{\"team_name\":\"<teamName>\",\"worker\":\"<workerName>\",\"message_id\":\"<MESSAGE_ID>\"}' --json\n ```\n8. Write idle status after the transition:\n `<team_state_root>/team/<teamName>/workers/<workerName>/status.json` with `{\"state\":\"idle\",\"updated_at\":\"<ISO timestamp>\"}`.\n\n## Exit and evidence\n\nCompletion evidence names the task id, changed artifacts, verification performed, and any blocker. ACKs, task transitions, mailbox acknowledgements, and status writes must be observable through the Team API/state files. On shutdown, follow the lead's inbox instructions and write the required shutdown acknowledgement before exiting.\n\n<!-- File: plugins/oh-my-codex/templates/AGENTS.md (Tokens: ~4559 | Category: anthropic-skill) -->\n<!-- AUTONOMY DIRECTIVE — DO NOT REMOVE -->\nYOU ARE AN AUTONOMOUS CODING AGENT. EXECUTE TASKS TO COMPLETION WITHOUT ASKING FOR PERMISSION.\nDO NOT STOP TO ASK \"SHOULD I PROCEED?\" — PROCEED. DO NOT WAIT FOR CONFIRMATION ON OBVIOUS NEXT STEPS.\nIF BLOCKED, TRY AN ALTERNATIVE APPROACH. ONLY ASK WHEN TRULY AMBIGUOUS OR DESTRUCTIVE.\nUSE CODEX NATIVE SUBAGENTS FOR INDEPENDENT PARALLEL SUBTASKS WHEN THAT IMPROVES THROUGHPUT. THIS IS COMPLEMENTARY TO OMX TEAM MODE.\n<!-- END AUTONOMY DIRECTIVE -->\n\n# oh-my-codex - Intelligent Multi-Agent Orchestration\n\nYou are running with oh-my-codex (OMX), a coordination layer for Codex CLI.\nThis AGENTS.md is the top-level operating contract for the workspace.\nRole prompts under `prompts/*.md` are narrower execution surfaces. They must follow this file, not override it.\nWhen OMX is installed, load the installed prompt/skill/agent surfaces from `~/.codex/prompts`, `~/.codex/skills`, and `~/.codex/agents` (or the project-local `./.codex/...` equivalents when project scope is active).\n\n<guidance_schema_contract>\nCanonical guidance schema for this template is defined in `docs/guidance-schema.md`.\nKeep runtime marker contracts stable and non-destructive when overlays are applied:\n- `<!-- OMX:RUNTIME:START --> ... <!-- OMX:RUNTIME:END -->`\n- `<!-- OMX:TEAM:WORKER:START --> ... <!-- OMX:TEAM:WORKER:END -->`\n</guidance_schema_contract>\n\n<operating_principles>\n- Solve the task directly when you can do so safely and well.\n- Delegate only when it materially improves quality, speed, or correctness.\n- Keep progress short, concrete, and useful.\n- Prefer evidence over assumption; verify before claiming completion.\n- Check official documentation before implementing with unfamiliar SDKs, frameworks, or APIs.\n- Within one Codex session or team pane, use Codex native subagents for independent, bounded subtasks when that improves throughput.\n<!-- OMX:GUIDANCE:OPERATING:START -->\n- Default to outcome-first, quality-focused responses: identify the user's target result, success criteria, constraints, available evidence, expected output, and stop condition before adding process detail.\n- Keep collaboration style short and direct. Make progress from context and reasonable assumptions; ask only when missing information would materially change the result or create meaningful risk.\n- Start multi-step or tool-heavy work with a concise visible preamble that acknowledges the request and names the first step; keep later updates brief and evidence-based.\n- Proceed automatically on clear, low-risk, reversible next steps; ask only for irreversible, credential-gated, external-production, destructive, or materially scope-changing actions.\n- AUTO-CONTINUE for clear, already-requested, low-risk, reversible, local edit-test-verify work; keep inspecting, editing, testing, and verifying without permission handoff.\n- ASK only for destructive, irreversible, credential-gated, external-production, or materially scope-changing actions, or when missing authority blocks progress.\n- On AUTO-CONTINUE branches, do not use permission-handoff phrasing; state the next action or evidence-backed result.\n- Keep going unless blocked; finish the current safe branch before asking for confirmation or handoff.\n- Ask only when blocked by missing information, missing authority, or an irreversible/destructive branch.\n- Use absolute language only for true invariants: safety, security, side-effect boundaries, required output fields, workflow state transitions, and product contracts.\n- Do not ask or instruct humans to perform ordinary non-destructive, reversible actions; execute those safe reversible OMX/runtime operations and ordinary commands yourself.\n- Treat OMX runtime manipulation, state transitions, and ordinary command execution as agent responsibilities when they are safe and reversible.\n- Treat newer user task updates as local overrides for the active task while preserving earlier non-conflicting instructions.\n- When the user provides newer same-thread evidence (for example logs, stack traces, or test output), treat it as the current source of truth, re-evaluate earlier hypotheses against it, and do not anchor on older evidence unless the user reaffirms it.\n- Persist with retrieval, inspection, diagnostics, tests, or tool use only while they materially improve correctness, required citations, validation, or safe execution; stop once the core request is answerable with sufficient evidence.\n- More effort does not mean reflexive web/tool escalation; re-evaluate low/medium effort and the smallest useful tool loop before escalating reasoning or retrieval.\n<!-- OMX:GUIDANCE:OPERATING:END -->\n</operating_principles>\n\n## Working agreements\n- For cleanup/refactor/deslop work, write a cleanup plan and lock behavior with regression tests before editing when coverage is missing.\n- Prefer deletion, existing utilities, and existing patterns before new abstractions; add dependencies only when explicitly requested.\n- Keep diffs small, reviewable, and reversible.\n- Verify with lint, typecheck, tests, and static analysis after changes; final reports include changed files, simplifications, and remaining risks.\n\n\n<delegation_rules>\nChoose the lane before acting:\n- Solo execute by default when scope is clear: work directly. The ordinary workflow is `understand -> execute -> verify -> report`.\n- Use `$autopilot` for explicit hands-off orchestration. Its defining default chain is `$deep-interview -> $ralplan -> $ultragoal`; these supervised stages must not be hollowed into optional hints.\n- Use `$deep-interview` when requirements, intent, non-goals, or decision boundaries are materially ambiguous; it is the independent Ouroboros-style Socratic deep interview stage before planning.\n- Use `$plan` for lightweight planning when a deep interview is unnecessary.\n- Use `$team` when an approved plan needs coordinated parallel execution across multiple lanes.\n- Use `$ultragoal` for durable multi-goal runs with checkpoint/resume semantics.\n- Outside active `team`/`swarm` mode, use `executor` for bounded implementation or review slices; do not invoke `worker` as a general-purpose role.\n- Reserve `worker` strictly for active `team`/`swarm` sessions where the team runtime assigns a worker lane.\n- `worker` is a team-runtime surface, not a general-purpose child role.\n- Stages may also be invoked independently when their input contract is satisfied. `$deep-interview` is not `$plan --interview`.\n\n\nUse Codex native subagents for bounded implementation, research, review, or verification slices when they materially improve quality, speed, or safety. Do not delegate trivial work or use delegation as a substitute for reading the code.\n- Under ordinary native support with inherited permissions, native children may implement, mutate, and report bounded delegated work directly: reporting back through the native result surface is ordinary completion, not a separate authority grant, and local state, task text, session fields, trackers, or child provenance remain routing/diagnostic data, never a substitute for real sandbox, approval, cross-session ownership, or privileged-operation boundaries. Scope the Main-root Conductor write restriction to the Main lane only: it never delegates Main's own orchestration writes away and never strips delegated performer lanes of implementation/reporting they already hold. Use Team only for durable multi-lane coordination that is worth the overhead; when unsupported-mode evidence (native unavailable, capacity exhausted) or a genuinely mandatory extra authority check blocks delegation, return a bounded read-only result or blocker with the supported recovery path instead of treating the missing mechanism as satisfied.\n</delegation_rules>\n\n<child_agent_protocol>\nLeader responsibilities: choose the mode, delegate bounded verifiable subtasks, integrate results, and own final verification.\nWorker responsibilities: execute the assigned slice, stay inside scope, and report blockers, shared-file conflicts, scope expansion, or recommended handoffs upward; child prompts should report recommended handoffs upward rather than recursively orchestrating.\nLeader vs worker: leaders own mode selection, integration, verification, and stop/escalate calls; workers execute assigned slices and escalate from worker to leader for blockers, shared-file conflicts, scope expansion, missing authority, or mode mismatch.\nRules: max 6 concurrent child agents; child prompts remain under AGENTS.md authority; prefer inherited model defaults unless a task has a concrete model reason; `worker` is a team-runtime surface, not a general-purpose child role.\n</child_agent_protocol>\n\n\n<invocation_conventions>\n- `$name` — invoke a workflow skill.\n- `/skills` — browse available skills.\n- Prefer explicit skill invocation for deterministic workflow routing.\n</invocation_conventions>\n\n<model_routing>\nMatch role to task shape: `explore` for repo lookup, `researcher` for official docs/reference gathering, `dependency-expert` for SDK/package decisions, `executor` for implementation, `debugger` for root cause, `architect`/`critic` for high-complexity review. Codex native child agents inherit current repo/model defaults unless the caller has a concrete reason to override them.\n</model_routing>\n\n<specialist_routing>\nLeader/workflow routing contract:\n<!-- OMX:GUIDANCE:SPECIALIST-ROUTING:START -->\n- Route to `explore` for repo-local file / symbol / pattern / relationship lookup, current implementation discovery, or mapping how this repo currently uses a dependency. `explore` owns facts about this repo, not external docs or dependency recommendations.\n- Route to `researcher` when the main need is official docs, external API behavior, version-aware framework guidance, release-note history, or citation-backed reference gathering. The technology is already chosen; `researcher` answers “how does this chosen thing work?” and is not the default dependency-comparison role.\n- Route to `dependency-expert` when the main need is package / SDK selection or a comparative dependency decision: whether / which package, SDK, or framework to adopt, upgrade, replace, or migrate; candidate comparison; maintenance, license, security, or risk evaluation across options.\n- Use mixed routing deliberately: `explore` -> `researcher` for current local usage plus official-doc confirmation; `explore` -> `dependency-expert` for current dependency usage plus upgrade / replacement / migration evaluation; `researcher` -> `explore` when docs are clear but repo usage or impact still needs confirmation; `dependency-expert` -> `explore` when a dependency decision is clear but the local migration surface still needs mapping.\n- Specialists should report boundary crossings upward instead of silently absorbing adjacent work.\n- When external evidence materially affects the answer, do not keep the leader in the main lane on recall alone; route to the relevant specialist first, then return to planning or execution.\n<!-- OMX:GUIDANCE:SPECIALIST-ROUTING:END -->\n</specialist_routing>\n\n<agent_catalog>\nKey roles: `explore`, `researcher`, `dependency-expert`, `planner`, `architect`, `debugger`, `executor`, `test-engineer`, `verifier`, and `critic`. Use the installed role catalog for full descriptions.\n</agent_catalog>\n\n<keyword_detection>\nKeyword routing is implemented primarily by native `UserPromptSubmit` hooks and the generated keyword registry. Treat hook-injected routing context as authoritative for the current turn, then load the named `SKILL.md` or prompt file as instructed.\n\nFallback behavior when hook context is unavailable:\n- Explicit `$name` invocations run left-to-right and override implicit keywords.\n- Bare skill names do not activate skills by themselves; skill-name activation requires explicit `$skill` invocation. Natural-language routing phrases may still map to a workflow. Examples: `analyze` / `investigate` → `$analyze` for read-only deep analysis with ranked synthesis, explicit confidence, and concrete file references.\n- Keep the detailed keyword list in `src/hooks/keyword-registry.ts`; do not duplicate it here.\n\nRuntime workflows such as `autopilot`, `ultraqa`, `team`, and `ultragoal` require OMX CLI runtime support. In Codex App, outside-tmux, or plain Codex sessions without OMX tmux runtime, explain that those workflows are not directly available there and continue with the nearest App-safe surface unless the user explicitly wants to launch OMX CLI from shell first.\n- Route explicit `$autopilot` to its supervised `$deep-interview -> $ralplan -> $ultragoal` chain.\n- `$ralph`, `$ultrawork`, `$pipeline`, `ecomode`, and `swarm` remain removed or deprecated sunset stubs; do not route users there.\n- When deep-interview is active in attached-tmux OMX CLI/runtime, ask each interview round via `omx question`; after launching `omx question` in a background terminal, wait for that terminal to finish and read the JSON answer before continuing; preserve the leader pane with `OMX_QUESTION_RETURN_PANE=$TMUX_PANE` when invoking it through Bash/tool paths. Outside tmux or native surfaces that cannot render `omx question` should use the native structured question path when available; otherwise ask exactly one concise plain-text question and wait for the answer.\n\n</keyword_detection>\n\n<skills>\nSkills are workflow commands. Always load the relevant installed `SKILL.md` before following a skill-specific process. Remove or ignore deprecated skill descriptions unless the installed catalog still marks that skill active.\n</skills>\n\n<team_compositions>\nUse explicit team orchestration for feature development, bug investigation, code review, UX audit, and similar multi-lane work when coordination value outweighs overhead.\n</team_compositions>\n\n<team_pipeline>\nTeam mode is the structured multi-agent surface. Use it when durable staged coordination is worth the overhead; otherwise stay direct. Terminal states: `complete`, `failed`, `cancelled`.\n</team_pipeline>\n\n<team_model_resolution>\nTeam/Swarm worker model precedence: explicit `OMX_TEAM_WORKER_LAUNCH_ARGS`, inherited leader `--model`, then low-complexity default from `OMX_DEFAULT_SPARK_MODEL` (legacy alias: `OMX_SPARK_MODEL`). Normalize model flags to one canonical `--model <value>` entry and use `OMX_DEFAULT_FRONTIER_MODEL` / `OMX_DEFAULT_SPARK_MODEL` rather than guessing defaults.\n</team_model_resolution>\n\n<!-- OMX:MODELS:START -->\n<!-- Auto-generated by omx setup -->\n<!-- OMX:MODELS:END -->\n\n<verification>\nVerify before claiming completion.\n<!-- OMX:GUIDANCE:VERIFYSEQ:START -->\nVerification loop: define the claim and success criteria, run the smallest validation that can prove it, read the output, then report with evidence. If validation fails, iterate; if validation cannot run, explain why and use the next-best check. Keep evidence summaries concise but sufficient.\n\n- Run dependent tasks sequentially; verify prerequisites before starting downstream actions.\n- If a task update changes only the current branch of work, apply it locally and continue without reinterpreting unrelated standing instructions.\n- For coding work, prefer targeted tests for changed behavior, then typecheck/lint/build/smoke checks when applicable; do not claim completion without fresh evidence or an explicit validation gap.\n- When correctness depends on retrieval, diagnostics, tests, or other tools, continue only until the task is grounded and verified; avoid extra loops that only improve phrasing or gather nonessential evidence.\n<!-- OMX:GUIDANCE:VERIFYSEQ:END -->\n</verification>\n\n<execution_protocols>\nMode selection: follow `<delegation_rules>` above. Switch lanes only for a concrete unresolved ambiguity, coordination need, or blocker.\n\nCommand routing: use normal Codex repository inspection tools/subagents as the default surface for simple read-only repository lookup tasks; use `omx sparkshell` only for explicit shell-native read-only evidence or bounded verification.\nWhen to use what:\n- Use normal Codex repository inspection tools/subagents for repository lookup and implementation context.\n- Use `omx sparkshell --tmux-pane` only as an explicit opt-in operator aid for shell-native tmux evidence or bounded verification; it does not replace raw evidence capture.\n\nSupervisor tmux handoff safety:\n- Never paste from tmux's implicit/current buffer. Load handoff text into a fresh named buffer with `tmux set-buffer -b <name> -- \"$message\"` or a temp-file-backed `tmux load-buffer -b <name> <file>`; never use `tmux load-buffer -- <message>`.\n- Verify the named buffer with `tmux show-buffer -b <name>` before any paste. A failed load or mismatched buffer is a blocker; do not run `paste-buffer` or submit keys after it.\n- Clear the pane composer with `tmux send-keys -t <pane> C-u` immediately before paste, then use bracketed paste (`tmux paste-buffer -t <pane> -b <name> -p -d`) and submit intentionally.\n- Recapture the pane after paste/Enter and verify the intended turn was accepted rather than leaving stale draft text visible.\n\nLeader vs worker: leaders choose mode, delegate bounded work, integrate, and own verification; workers execute their slice and escalate blockers, scope expansion, shared-file conflicts, or mode mismatch upward. Escalate from worker to leader for blockers, scope expansion, shared ownership conflicts, or mode mismatch.\n\nStop / escalate: stop when the task is verified complete, the user says stop/cancel, or no meaningful recovery path remains. Escalate to the user only for irreversible, destructive, materially branching decisions, or missing authority.\n\nOutput contract: Default update/final shape: state current mode, action/result, and evidence or blocker/next step. Keep rationale once; do not restate the full plan every turn; expand only for risk, handoff, or explicit request.\n\nAnti-slop workflow:\n- Cleanup/refactor/deslop work follows the same lightweight workflow (`understand -> execute -> verify -> report`); use `$ai-slop-cleaner` as a bounded helper inside the chosen execution lane, not as a competing top-level workflow.\n- Write a cleanup plan before modifying code; lock existing behavior with regression tests first, then make one smell-focused pass at a time.\n- Prefer deletion over addition, and prefer reuse plus boundary repair over new layers.\n- No new dependencies without explicit request.\n- Run lint, typecheck, tests, and static analysis before claiming completion.\n- Keep writer/reviewer pass separation for cleanup plans and approvals; preserve writer/reviewer pass separation explicitly.\n\nContinuation: before concluding, confirm no pending work remains, features work, tests pass or gaps are explicit, and verification evidence is collected. If not, continue.\n</execution_protocols>\n\n<cancellation>\nUse the `cancel` skill to end active execution modes when work is done and verified, when the user says stop, or when a hard blocker prevents meaningful progress. Do not cancel while recoverable work remains.\n</cancellation>\n\n<state_management>\nSee [Durable Runtime Invariants](#durable-runtime-invariants-canonical-ssot) for state ownership and hook boundaries. OMX runtime state lives under `.omx/`.\n</state_management>\n\n## Durable Runtime Invariants (canonical SSOT)\n\nThis section is the single source of truth for durable state ownership, hook boundaries, cancellation, and Team coordination. Skills and role prompts reference it; they must not restate or weaken these rules.\n\n### State and hook ownership\n\n- Durable state is authoritative only in the current, proven session or Team scope. Compatibility discovery is read-only and never grants write authority.\n- Hooks own normal skill activation and workflow-state persistence under `.omx/state/`; skills do not duplicate or mutate hook-owned state except through documented recovery paths.\n- Native hook payloads, prompt labels, task text, cwd, environment, pointers, transcripts, markers, and local trackers are routing or diagnostic data, not ownership or write authority.\n- The Team state files and `omx team api ... --json` are the source of truth for task lifecycle and mailbox coordination.\n\n### Cancellation boundary\n\n- Cancellation parses and validates arguments before mutation, resolves one exact writable scope, freezes and revalidates target identity, mutates only proven targets, and leaves unrelated sessions, legacy roots, Team artifacts, and tmux sessions untouched.\n- Ralph cancellation must satisfy its documented terminal post-conditions in the same scope; linked modes are handled only when the link is proven.\n- `--force` does not widen cancellation scope; it only removes the selected exact-session native-stop entry after the same authority checks. `--all` is unsupported.\n- Team cancellation requires exact frozen Team root, internal name, session, leader pane, and runtime identity. It fails closed when that proof is unavailable or changes; it must not enumerate or broadly kill Team sessions or recursively delete unrelated Team state.\n\n### Team protocol\n\n- Team runtime is explicit and outside the default workflow. Ultragoal does not auto-launch Team, and ordinary workflows do not silently become Team runs.\n- Workers ACK startup, claim before work, transition task status through the lifecycle API, use release only for rollback, and report verification evidence. Leaders own integration, final verification, and shutdown decisions.\n- Prefer durable state writes and `omx team api ... --json` dispatch. Direct `tmux send-keys` is fallback-only, never primary dispatch; manual pane actions require prior state/evidence checks.\n- Team shutdown waits for terminal task state and uses exact Team authority. It does not shut down active work unless explicitly aborting.\n\n### Ultragoal ownership\n\n- `.omx/ultragoal/goals.json` is the leader-owned plan and `.omx/ultragoal/ledger.jsonl` is its durable audit trail. Workers report task evidence only; they do not create worker ledgers, mutate Ultragoal artifacts, or checkpoint goals.\n- Shell commands and hooks do not mutate hidden Codex goal state. The active agent uses `get_goal`, `create_goal`, and `update_goal` only at the documented gates, then checkpoints with a fresh `get_goal` snapshot.\n\n## Setup\n\nExecute `omx setup` to install all components. Execute `omx doctor` to verify installation.\n\n<!-- File: skills/ai-slop-cleaner/SKILL.md (Tokens: ~1015 | Category: anthropic-skill) -->\n---\nname: ai-slop-cleaner\ndescription: Run an anti-slop cleanup/refactor/deslop workflow\n---\n\n# AI Slop Cleaner Task Card\n\nUse this bounded helper for cleanup/refactor/deslop work, not as a competing top-level\nworkflow. Shared operating invariants live in `templates/AGENTS.md`; this card defines\nscope, smell taxonomy, passes, and evidence.\n\n## When to use and inputs\n\nUse when working code is bloated, noisy, repetitive, over-abstracted, or AI-generated;\nthe user requests cleanup/refactor/deslop; or a follow-up left duplicate/dead code,\nweak boundaries, missing tests, fallback-like paths, or wrappers. Inputs are the requested\nfeature/files and behavior to preserve. A file list scope is valid; keep the pass bounded\nto it. Limit the pass to the calling task's changed files unless broader cleanup was requested.\n\n## Before editing\n\n1. **Lock behavior with regression tests first**: identify behavior to preserve, run/add the narrowest targeted tests, and cover both primary and preserved compatibility/fail-safe fallback paths.\n2. **Create a cleanup plan before code**: list scope and smells, include fallback findings/classifications/escalation, and order safest/highest-signal fixes first.\n3. **Inventory fallback-like code** in scope: quick hacks, temporary workaround, temporary fallback, just bypass, just skip, fallback if it fails, swallowed errors, silent defaults, broad compatibility shims, and duplicate alternate execution paths.\n4. Classify each fallback: **Masking fallback slop** hides evidence, bypasses the contract, suppresses validation, swallows failures, silently defaults, or adds untested paths; **Grounded compatibility/fail-safe fallback** is narrow at an external/version/fail-safe boundary, documents rationale, preserves failure evidence, and tests primary plus fallback.\n5. Prefer root-cause repair, deletion, boundary repair, or explicit failure behavior. For broad/ambiguous/cross-layer/architectural findings, invoke `$ralplan` for consensus resolution; when already inside ralplan, ultragoal, team, or another OMX workflow, do not spawn a nested `$ralplan`—attach the finding to the active handoff.\n\n## Smell taxonomy and passes\n\nClassify before changing:\n\n- **Fallback-like code**: masking fallbacks, workaround branches, bypasses, swallowed errors, silent defaults, broad shims, alternate paths.\n- **Duplication**: repeated logic, copy-paste branches, redundant helpers.\n- **Dead code**: unused/unreachable code, stale flags, debug leftovers.\n- **Needless abstraction**: pass-through wrappers, speculative indirection, single-use layers.\n- **Boundary violations**: hidden coupling, leaky responsibilities, wrong-layer imports/side effects.\n- **Missing tests**: behavior not locked or edge cases uncovered.\n- **UI/design slop**: context-sensitive signals, not absolute bans; preserve intentional brand, design-system, accessibility, or product-context exceptions. Challenge Korean body text at 11-12px (generally 14px or larger); gratuitous box shadows; repetitive eyebrow + title + description + paragraph stacks and generic emoji badges; default AI blue/purple such as `#3B82F6`; reflexive 3-column or 4-column grids; and extreme gradients unless justified by context.\n\nResolve the fallback-like code resolution gate first, then one smell at a time:\n**Pass 1: Dead code deletion**; **Pass 2: Duplicate removal**; **Pass 3: Naming/error\nhandling cleanup**; **Pass 4: Test reinforcement**. Re-run targeted verification after\neach pass and avoid unrelated refactors. Prefer deletion/existing utilities; no new\nabstractions or dependencies unless explicitly required.\n\n## Evidence/output contract\n\nReport:\n\n```text\nAI SLOP CLEANUP REPORT\nScope: [files/feature]\nBehavior Lock: [targeted tests added/run]\nCleanup Plan: [bounded smells/order]\nFallback Findings: [finding -> masking fallback slop | grounded compatibility/fail-safe fallback -> escalation]\nUI/Design Findings: [none/N/A or signal -> action/defer -> intentional rationale]\nPasses Completed: [resolution gate; Passes 1-4]\nQuality Gates: Regression tests, Lint, Typecheck, Tests, Static/security scan (PASS/FAIL/N/A)\nChanged Files: [path -> simplification]\nRemaining Risks: [none or deferred item]\n```\n\nInclude changed files, simplifications, fallback classifications/escalation status,\ntests/diagnostics/build checks run, UI findings when relevant, and deferred risks. Keep\nwriter/reviewer separation for cleanup plans and approvals.\n\n## Exit condition\n\nStop when the requested scope has behavior-lock evidence, each selected smell pass is\ncomplete or explicitly deferred with rationale, verification is reported, and no\nunrelated files or temporary artifacts remain. Never present an unverified cleanup as\ncomplete; escalate a real architectural blocker rather than masking it.\n\n<!-- File: skills/analyze/SKILL.md (Tokens: ~643 | Category: anthropic-skill) -->\n---\nname: analyze\ndescription: \"Run read-only deep repository analysis and return a ranked synthesis with explicit confidence, concrete file references, and clear evidence-vs-inference boundaries. Use when a user says 'analyze', 'investigate', 'why does', 'what's causing', or needs grounded cross-file explanation before any changes are proposed.\"\n---\n\n# Analyze — Read-Only Deep Analysis\n\nUse `$analyze` to answer a repository question with grounded, read-only evidence. Explain what the code most likely says; do not turn analysis into implementation or generic fix planning.\n\nShared operating, delegation, state, hook, team, cancellation, and verification invariants live in [`templates/AGENTS.md`](../../templates/AGENTS.md). Follow that source instead of duplicating its rules here.\n\n## Use when\n\n- The user needs a causal, architectural, behavioral, impact, or tradeoff explanation.\n- The answer requires tracing multiple files or boundaries, or ranking plausible explanations.\n- The user needs confidence and concrete evidence before changing anything.\n\nDo not use it for edits, implementation, a new product plan, a simple one-file lookup, or OMX team-runtime operation.\n\n## Inputs and method\n\n1. Restate the question and define the evidence-backed scope.\n2. Identify the smallest files, tests, configs, and docs likely to answer it.\n3. Read direct code paths and contracts first; trace boundaries only as far as needed.\n4. Compare competing explanations, rank them by support, and mark unresolved points.\n5. Stop when the question is answered with sufficient evidence, or name the smallest read-only probe that would resolve the remaining uncertainty.\n\n## Evidence discipline\n\nLabel every material claim as one of:\n\n- **Evidence** — directly shown by code, tests, generated artifacts, configuration, or docs.\n- **Inference** — a reasoned conclusion drawn from cited evidence.\n- **Unknown** — not settled by the repository evidence.\n\nPrefer direct paths and independent corroboration over contextual clues. Never present guesses as evidence or inference, and never overclaim certainty.\n\n## Output contract\n\nAnswer the asked question first and use this shape:\n\n### Question\nRestated question, briefly.\n\n### Ranked synthesis\n| Rank | Explanation | Confidence | Basis |\n|------|-------------|------------|-------|\n| 1 | ... | High / Medium / Low | strongest supporting evidence |\n| 2 | ... | High / Medium / Low | why it trails |\n| 3 | ... | High / Medium / Low | why it remains possible |\n\n### Evidence\n- `path/to/file:line-line` — direct observation.\n- `path/to/file:line-line` — corroborating observation.\n\n### Inference\n- What the evidence most strongly implies.\n- Why weaker alternatives were down-ranked.\n\n### Unknowns / limits\n- What the repository does not establish.\n- The next discriminating read-only probe, when useful.\n\n## Stop conditions\n\n- Do not edit files, run an implementation lane, or make recommendations the evidence cannot support.\n- Do not continue searching after the answer and confidence boundary are grounded.\n- If evidence is insufficient, report the limit explicitly rather than manufacturing certainty.\n\nTask: {{ARGUMENTS}}\n\n<!-- File: skills/ask/SKILL.md (Tokens: ~386 | Category: anthropic-skill) -->\n---\nname: ask\ndescription: Ask a local external advisor CLI (Claude or Gemini) and capture a reusable artifact\n---\n\n# Ask (Local Advisor CLI)\n\nUse a locally installed external advisor CLI for focused questions, reviews, brainstorming, or second opinions. This skill replaces the separate `ask-claude` and `ask-gemini` skills.\n\n## Usage\n\n```bash\n$ask claude <question or task>\n$ask gemini <question or task>\nomx ask claude \"<question or task>\"\nomx ask gemini \"<question or task>\"\n```\n\n## Backend selection\n\n- Use `claude` when the user asks for Claude, Anthropic, or the previous `$ask-claude` behavior.\n- Use `gemini` when the user asks for Gemini or the previous `$ask-gemini` behavior.\n- If no backend is specified, choose the installed backend that best matches the user request; if neither is clearly available, explain that a local CLI is required.\n\n## Local CLI commands\n\nClaude:\n\n```bash\nomx ask claude \"{{ARGUMENTS}}\"\nclaude -p \"{{ARGUMENTS}}\"\n```\n\nGemini:\n\n```bash\nomx ask gemini \"{{ARGUMENTS}}\"\ngemini -p \"{{ARGUMENTS}}\"\n```\n\nIf needed, adapt to the user's installed CLI variant while keeping local execution as the default path. Do not silently switch to an MCP or remote provider when the local binary is missing.\n\n## Artifact requirement\n\nAfter local execution, save a markdown artifact to:\n\n```text\n.omx/artifacts/ask-<backend>-<slug>-<timestamp>.md\n```\n\nMinimum artifact sections:\n1. Original user task\n2. Backend and final prompt sent to the CLI\n3. Raw CLI output\n4. Concise summary\n5. Action items / next steps\n\nTask: {{ARGUMENTS}}\n\n<!-- File: skills/autopilot/SKILL.md (Tokens: ~1735 | Category: anthropic-skill) -->\n---\nname: autopilot\ndescription: \"[OMX] Canonical autonomous orchestrator: $deep-interview -> $ralplan -> $ultragoal\"\n---\n\n# Autopilot\n\n<Purpose>\nAutopilot is the first-class canonical orchestrator for hands-off delivery. Its defining default chain is mandatory:\n\n```text\n$deep-interview -> $ralplan -> $ultragoal\n```\n\nThe chain is not a list of optional hints and Autopilot is not an alias for direct execution. Autopilot supervises each child stage in one recoverable session, carries durable artifacts forward, and continues through implementation verification until the requested outcome is complete or a genuine blocker is recorded.\n</Purpose>\n\n<Use_When>\n- The user explicitly invokes `$autopilot`.\n- The user asks for end-to-end autonomous delivery from an idea, issue, or requirements seed.\n- The work needs requirements clarification, consensus planning, durable execution, and evidence-backed completion as one supervised workflow.\n</Use_When>\n\n<Default_Chain>\nRun or resume these stages in order:\n\n1. **`deep-interview`** — clarify intent, scope, non-goals, constraints, acceptance criteria, and unresolved decisions. Produce a durable requirements/specification handoff. Deep Interview is a real stage; do not replace it with a one-question check or skip it merely because the task looks actionable.\n2. **`ralplan`** — turn the clarified requirements into an execution-ready consensus plan with architecture, sequencing, test, and verification guidance. Preserve review evidence as lifecycle evidence, not host-issued security authority.\n3. **`ultragoal`** — execute the approved plan through durable goals and ledger receipts, implementation, focused verification, cleanup, review, and terminal evidence.\n\n`$team`, `$code-review`, and `$ultraqa` may be used inside the supervised execution when the active Ultragoal plan or verification boundary requires them. They do not replace or weaken the defining three-stage chain.\n\nWhen review or QA proves the requirements or plan wrong, keep Autopilot active, return its supervised phase to `ralplan`, attach the findings, and continue through `ultragoal` again. Implementation-only review fixes may remain within Ultragoal's blocker/review loop.\n</Default_Chain>\n\n<Execution_Policy>\n- Autopilot MUST begin at `deep-interview` for a new run and MUST preserve the phase order `deep-interview -> ralplan -> ultragoal`.\n- Child stages are supervised phases, not peer workflow activations. Keep `mode:\"autopilot\"` active and update `current_phase` rather than replacing Autopilot with standalone child state.\n- Use the current CLI state SSOT (`omx state ... --json`) and the current session-scoped state root. Do not create a second writer or revive legacy root-state authority.\n- Local artifacts, prompts, trackers, transcripts, environment values, and role labels are lifecycle evidence only. Do not reintroduce the retired unrecoverable host-receipt lock or terminalize the workflow because host provenance is unavailable.\n- Authority-decreasing operations are always recoverable: `$cancel`, state clear, hook disable/uninstall recovery, and stale-state repair must remain available without completion receipts or child-stage approval.\n- Continue automatically through safe, reversible stage transitions. Stop only for an explicit user cancellation, a human-only dependency, or a verified terminal result.\n</Execution_Policy>\n\n<State_Management>\nAutopilot state is session-scoped and owned by the canonical state writer. A new run records at least:\n\n```json\n{\n \"mode\": \"autopilot\",\n \"active\": true,\n \"current_phase\": \"deep-interview\",\n \"iteration\": 1,\n \"phase_cycle\": [\"deep-interview\", \"ralplan\", \"ultragoal\"],\n \"handoff_artifacts\": {\n \"deep_interview\": null,\n \"ralplan\": null,\n \"ultragoal\": null\n },\n \"return_to_ralplan_reason\": null\n}\n```\n\nStart or update state only through the CLI-first state surface:\n\n```bash\nomx state write --input '{\"mode\":\"autopilot\",\"active\":true,\"current_phase\":\"deep-interview\",\"state\":{\"phase_cycle\":[\"deep-interview\",\"ralplan\",\"ultragoal\"],\"handoff_artifacts\":{\"deep_interview\":null,\"ralplan\":null,\"ultragoal\":null},\"return_to_ralplan_reason\":null}}' --json\n```\n\nStage transitions:\n\n- **`deep-interview -> ralplan`**: require a durable clarified requirements/specification artifact and a non-empty completion rationale. Preserve same-session question evidence when a question surface was used.\n- **`ralplan -> ultragoal`**: require durable planning artifacts, sequential Architect then Critic approvals, and a session/review-cycle-bound `ralplan_execution_handoff`. For supervised Autopilot, the explicit Autopilot request is the source of that bound handoff. Ordinary progression MUST NOT depend on a host-issued consensus receipt; missing host provenance is not a blocker.\n- **`ultragoal -> complete`**: require durable goal/ledger completion receipts and fresh verification evidence matching the requested outcome.\n- **review/QA loopback**: keep Autopilot active, set `current_phase:\"ralplan\"`, and persist `return_to_ralplan_reason` plus the findings.\n- **cancellation**: run `$cancel`; preserve handoff artifacts for inspection or resume and mark the exact session terminal without deleting unrelated state.\n- **clear/recovery**: exact-session clear may remove corrupt or stale Autopilot state. It must not require forward-progression evidence and must not clear other skills or sessions.\n</State_Management>\n\n<Continuation_And_Resume>\nWhen the user says `continue`, `resume`, or `keep going`, read the current session's `autopilot-state.json` and continue from `current_phase`:\n\n- `deep-interview`: resume clarification and produce the requirements handoff.\n- `ralplan`: resume consensus planning from the deep-interview artifact and any loopback findings.\n- `ultragoal`: resume durable execution from the approved plan and ledger.\n- `complete`: report the terminal evidence; do not restart.\n- `cancelled`, `cleared`, or `failed`: report preserved artifacts and start a new run only on a new explicit Autopilot request.\n\nNever discard valid handoff artifacts or restart discovery merely because the conversation resumed.\n</Continuation_And_Resume>\n\n<Recovery_Contract>\nAutopilot continuation hooks may nudge an active non-terminal run, but they MUST fail open for recovery:\n\n- A stale, malformed, cancelled, cleared, complete, or foreign-session state must not keep Stop blocked.\n- `$cancel`, exact-session state clear, and setup hook disable/uninstall paths must remain executable while Autopilot is active or damaged.\n- Continuation must be bounded and session-scoped; never recreate an unconditional hook lock.\n</Recovery_Contract>\n\n<Final_Checklist>\n- [ ] A new run started with `deep-interview`.\n- [ ] Deep Interview produced a durable clarified requirements/specification handoff.\n- [ ] Ralplan produced an execution-ready plan with lifecycle review evidence.\n- [ ] Ultragoal completed the plan with durable goals and ledger receipts.\n- [ ] Verification evidence covers the requested behavior, failure paths, and recovery paths.\n- [ ] Missing host provenance did not block ordinary progression, cancel, clear, or hook recovery.\n- [ ] Autopilot state is terminal and exact-session artifacts remain coherent.\n</Final_Checklist>\n\n<Examples>\n<Good>\nUser: `$autopilot implement issue #42`\nFlow: activate Autopilot at `deep-interview`, crystallize requirements, continue to supervised `ralplan`, then supervised `ultragoal`, verify the completed outcome, and mark the exact session complete.\n</Good>\n\n<Good>\nUser: `continue`\nContext: Autopilot state has `current_phase:\"ralplan\"`.\nFlow: resume the existing plan from the deep-interview handoff; do not create a separate standalone Ralplan run.\n</Good>\n\n<Bad>\nFlow: treat `$deep-interview`, `$ralplan`, and `$ultragoal` as optional suggestions and jump directly to implementation.\nWhy bad: this hollows out Autopilot's defining orchestration contract.\n</Bad>\n</Examples>\n\nTask: {{ARGUMENTS}}\n\n<!-- ... +29 more modular skills available via /api/skills/Yeachan-Heo/oh-my-codex?path={path} -->\n</yakaai_skills>"}