oh-my-codex 0.20.3 → 0.21.0

package/skills/build-fix/SKILL.md

@@ -1,10 +0,0 @@
----
-name: build-fix
-description: Build Fix deprecated shim
----
-
-# Build Fix deprecated
-
-Hard-deprecated. Do not invoke or route this skill. Build failures should be handled by the active execution, debugging, or verification workflow.
-
-Task: {{ARGUMENTS}}

package/skills/deepsearch/SKILL.md

@@ -1,10 +0,0 @@
----
-name: deepsearch
-description: Deepsearch deprecated shim
----
-
-# Deepsearch deprecated
-
-Hard-deprecated. Do not invoke or route this skill. Use `$analyze` for deep repository analysis or `omx explore` for fast repo-local lookup.
-
-Task: {{ARGUMENTS}}

package/skills/ecomode/SKILL.md

@@ -1,114 +0,0 @@
----
-name: ecomode
-description: Ecomode deprecated shim
----
-
-# Ecomode deprecated
-
-Hard-deprecated. Do not invoke or route this skill. Use `$ultrawork` directly for maintained high-throughput execution workflows.
-
-## What Ecomode Does
-
-Overrides default model selection to prefer cheaper tiers:
-
-| Default Tier | Ecomode Override |
-|--------------|------------------|
-| THOROUGH | STANDARD, THOROUGH only if essential |
-| STANDARD | LOW first, STANDARD if needed |
-| LOW | LOW - no change |
-
-## What Ecomode Does NOT Do
-
-- **Persistence**: Use `ralph` for "don't stop until done"
-- **Parallel Execution**: Use `ultrawork` for parallel agents
-- **Delegation Enforcement**: Always active via core orchestration
-
-## Combining Ecomode with Other Modes
-
-Ecomode is a modifier that combines with execution modes:
-
-| Combination | Effect |
-|-------------|--------|
-| `eco ralph` | Ralph loop with cheaper agents |
-| `eco ultrawork` | Parallel execution with cheaper agents |
-| `eco autopilot` | Full autonomous with cost optimization |
-
-## Ecomode Routing Rules
-
-**ALWAYS prefer lower tiers. Only escalate when task genuinely requires it.**
-
-| Decision | Rule |
-|----------|------|
-| DEFAULT | Start with LOW tier for most tasks |
-| UPGRADE | Escalate to STANDARD when LOW tier fails or task requires multi-file reasoning |
-| AVOID | THOROUGH tier - only for planning/critique if essential |
-
-## Agent Selection in Ecomode
-
-**FIRST ACTION:** Before delegating any work, read the agent reference file:
-```
-Read file: references/agent-tiers.md
-```
-This provides the complete agent tier matrix, MCP tool assignments, and selection guidance.
-
-**Ecomode preference order:**
-
-```
-// PREFERRED - Use for most tasks
-use /prompts:executor for this scoped task
-use /prompts:explore for this scoped task
-use /prompts:architect for this scoped task
-
-// FALLBACK - Only if LOW fails
-use /prompts:executor for this scoped task
-use /prompts:architect for this scoped task
-
-// AVOID - Only for planning/critique if essential
-use /prompts:planner for this scoped task
-```
-
-## Delegation Enforcement
-
-Ecomode maintains all delegation rules from core protocol with cost-optimized routing:
-
-| Action | Delegate To | Model |
-|--------|-------------|-------|
-| Code changes | executor | LOW / STANDARD |
-| Analysis | architect | LOW |
-| Search | explore | LOW |
-| Documentation | writer | LOW |
-
-### Background Execution
-Long-running commands (install, build, test) run in background. Maximum 20 concurrent.
-
-## Token Savings Tips
-
-1. **Batch similar tasks** to one agent instead of spawning many
-2. **Use explore (LOW tier)** for file discovery, not architect
-3. **Prefer LOW-tier executor routing** for simple changes - only upgrade if it fails
-4. **Use writer (LOW tier)** for all documentation tasks
-5. **Avoid THOROUGH-tier agents** unless the task genuinely requires deep reasoning
-
-## Disabling Ecomode
-
-Ecomode can be completely disabled via config. When disabled, all ecomode keywords are ignored.
-
-Set in `~/.codex/.omx-config.json`:
-```json
-{
-  "ecomode": {
-    "enabled": false
-  }
-}
-```
-
-## State Management
-
-Use the CLI-first state surface (`omx state ... --json`) for ecomode lifecycle state. If explicit MCP compatibility tools are already available, equivalent `omx_state` calls are optional compatibility, not the default.
-
-- **On activation**:
-  `omx state write --input '{"mode":"ecomode","active":true}' --json`
-- **On deactivation/completion**:
-  `omx state write --input '{"mode":"ecomode","active":false}' --json`
-- **On cancellation/cleanup**:
-  run `$cancel` (which should call `omx state clear --input '{"mode":"ecomode"}' --json`)

package/skills/ecomode/references/agent-tiers.md

@@ -1,61 +0,0 @@
-# Agent Tiers
-
-This file defines practical tier guidance for OMX agent routing.
-
-## Mental Model
-
-OMX now separates three concepts:
-
-- `role`: what the agent is responsible for (`executor`, `planner`, `architect`)
-- `tier`: how much reasoning/cost to spend (`LOW`, `STANDARD`, `THOROUGH`)
-- `posture`: how the role behaves (`frontier-orchestrator`, `deep-worker`, `fast-lane`)
-- `exactModel`: optional role pin that bypasses tier defaults when a role needs a
-  specific model contract.
-
-Use role to choose responsibility, tier to choose depth, and posture to choose operating style.
-
-## Tiers
-
-- `LOW`:
-  Fast lookups and narrow checks.
-  Use for simple exploration, style checks, and lightweight doc edits.
-  Typical roles: `explore`, `style-reviewer`, `writer`.
-
-- `STANDARD`:
-  Default tier for implementation, debugging, and normal verification.
-  Typical roles: `executor`, `debugger`, `test-engineer`, `quality-reviewer`.
-
-- `THOROUGH`:
-  Use for architectural, security-sensitive, or high-impact multi-file work.
-  Typical roles: `architect`, `critic`, `security-reviewer`, `executor`.
-  Note: `deep-executor` is deprecated; route implementation to `executor`.
-
-## Selection Rules
-
-1. Start at `STANDARD` for most code changes.
-2. Use `LOW` only when the task is bounded and non-invasive.
-3. Escalate to `THOROUGH` for:
-   - security/auth/trust-boundary changes
-   - architectural decisions with system-wide impact
-   - large refactors across many files
-4. For Ralph completion checks, use at least `STANDARD` architect verification.
-
-## Posture Guidance
-
-- `frontier-orchestrator`:
-  - Best for steerable frontier models and leader-style roles.
-  - Prioritizes intent classification, delegation, verification, and architectural judgment.
-  - Typical roles: `planner`, `analyst`, `architect`, `critic`, `code-reviewer`.
-  - Ralplan keeps `planner` and `architect` in this posture but pins them to
-    exact `gpt-5.6-sol` with role-specific reasoning; the `critic` consensus gate stays
-    on the frontier lane.
-
-- `deep-worker`:
-  - Best for implementation-heavy roles that should carry work to completion.
-  - Prioritizes direct execution, minimal diffs, and strict verification.
-  - Typical roles: `executor`, `debugger`, `test-engineer`, `build-fixer`.
-
-- `fast-lane`:
-  - Best for cheap/fast models used for triage, search, and narrow synthesis.
-  - Prioritizes quick routing, concise search, and escalation over deep autonomous work.
-  - Typical roles: `explore`, `writer`, and lightweight research/search specialists.

package/skills/frontend-ui-ux/SKILL.md

@@ -1,16 +0,0 @@
----
-name: frontend-ui-ux
-description: Deprecated compatibility shim for frontend UI/UX work; use $design or $visual-ralph
----
-
-# Frontend UI/UX compatibility shim
-
-Hard-deprecated. Do not invoke or route this skill for new work.
-
-Use `$design` when the task needs product/design context, UX guidance, frontend planning, design-system alignment, or a repo-local `DESIGN.md` source of truth.
-
-Use `$visual-ralph` when the task needs implementation against an approved generated/static/live-URL visual reference with screenshot capture, Visual Ralph verdict scoring, and pixel-diff evidence.
-
-This file exists only to preserve the public/catalog-visible `frontend-ui-ux` compatibility contract while canonical design guidance is handled by `$design` and measured visual implementation is handled by `$visual-ralph`.
-
-Task: {{ARGUMENTS}}

package/skills/help/SKILL.md

@@ -1,10 +0,0 @@
----
-name: help
-description: Help deprecated skill
----
-
-# Help deprecated
-
-Hard-deprecated. Do not invoke or route this skill. Use `$omx-setup`, `omx setup`, or `omx doctor` directly for setup, install, and troubleshooting guidance.
-
-Task: {{ARGUMENTS}}

package/skills/note/SKILL.md

@@ -1,10 +0,0 @@
----
-name: note
-description: Note deprecated shim
----
-
-# Note deprecated
-
-Hard-deprecated. Do not invoke or route this skill. Use OMX persistent memory/notepad surfaces directly when notes are required.
-
-Task: {{ARGUMENTS}}

package/skills/prometheus-strict/README.md

@@ -1,35 +0,0 @@
-# Prometheus Strict
-
-`$prometheus-strict` is a clean-room OMX planning skill for rigorous interview-driven planning before execution.
-
-It is inspired by the high-level OMO Prometheus concept only. It does not copy OMO source text, prompts, runtime code, or workflow implementation.
-
-Credit: Inspired by OMO Prometheus (`code-yeongyu/oh-my-openagent`), reimplemented from concept under MIT.
-
-## Roles
-
-- **Metis** clarifies requirements, constraints, non-goals, and acceptance criteria.
-- **Momus** challenges assumptions, scope, handoff risks, and missing verification.
-- **Oracle** synthesizes the approved plan and recommends the OMX-native handoff.
-
-## OMX Handoff
-
-Prometheus Strict is planning-only by default. It should hand off to:
-
-1. `$ultragoal` for durable goal execution.
-2. `$team` only when the Oracle plan identifies independent parallel lanes.
-
-## Non-Goals
-
-- No hook implementation.
-- No Sisyphus or `start-work` port.
-- No direct implementation unless a downstream execution workflow is explicitly invoked.
-- No verbatim source copying from the inspiration project.
-
-## Expected Output
-
-The skill returns a Prometheus Strict Plan with clarified requirements, resolved critique, an Oracle execution plan, a verification matrix, an optional durable artifact path under `.omx/plans/prometheus-strict/`, and clean-room credit.
-
-## Durable Plan Artifacts
-
-When the plan should survive handoff or review, write the final Oracle synthesis to `.omx/plans/prometheus-strict/<slug>.md` and include that path in the plan before invoking `$ultragoal` or `$team`. Inline-only plans may set the artifact path to `N/A - inline plan only`.

package/skills/prometheus-strict/SKILL.md

@@ -1,219 +0,0 @@
----
-name: prometheus-strict
-description: "[OMX] Clean-room interview-driven planner: Metis clarifies, Momus challenges, Oracle synthesizes, then hands off to $ultragoal/$team."
-argument-hint: "<goal or problem statement>"
----
-
-# Prometheus Strict
-
-Clean-room OMX planning workflow inspired by the high-level OMO Prometheus concept only. This skill does not copy implementation, prompts, wording, control flow, or runtime code from OMO. It reimplements the idea under this repository's MIT-licensed skill conventions.
-
-Credit: Inspired by OMO Prometheus (`code-yeongyu/oh-my-openagent`), reimplemented from concept under MIT.
-
-<Purpose>
-Prometheus Strict creates a rigorous plan before execution when ambiguity is still risky. It separates three planning voices: Metis clarifies requirements, Momus challenges assumptions and validation gaps, and Oracle synthesizes the handoff-ready OMX-native plan.
-
-The output is a planning-only artifact for `$ultragoal` and, when independent lanes are justified, `$team`. When a durable artifact is useful, store or request the final plan under `.omx/plans/prometheus-strict/`.
-</Purpose>
-
-<Use_When>
-- The task is important enough that a shallow plan could produce wrong work.
-- Requirements are partially known but acceptance criteria, boundaries, risks, or validation are incomplete.
-- The user wants a strict interview before execution.
-- A future `$ultragoal` story needs durable scope, tests, and handoff sequencing.
-- A team split may be needed, but the lanes are not yet safe to assign.
-</Use_When>
-
-<Do_Not_Use_When>
-- The user asks for immediate implementation of a clear, low-risk change; use the normal executor path.
-- The task is only a repository lookup or explanation; use `explore`/`analyze` as appropriate.
-- The user needs adversarial execution QA after code changes; use `$ultraqa`.
-- The user wants hook behavior, Sisyphus behavior, or a `start-work` port. Those are explicit non-goals.
-</Do_Not_Use_When>
-
-<Why_This_Exists>
-OMX already has `$plan`, `$ralplan`, and `$deep-interview`. Prometheus Strict exists for a narrower case: an explicit clean-room strict-planning lane with named clarification, critique, and synthesis roles, plus a durable `.omx/plans/prometheus-strict/` handoff contract. It is not a replacement for execution workflows.
-</Why_This_Exists>
-
-<Execution_Policy>
-- Stay planning-only. Do not edit source code during this skill unless the user starts a separate execution workflow afterward.
-- Preserve clean-room boundaries. Do not copy or imitate OMO wording, source, prompts, runtime behavior, or control flow.
-- Keep non-goals visible: No hook implementation. No Sisyphus/start-work port. No automatic external-production actions.
-- Ask high-leverage questions as a batched round when the answers materially change scope, safety, or validation. Reserve one-at-a-time questioning only for dependent question chains where the next question depends on the previous answer.
-- If a safe assumption is available, state it and continue.
-- Use repository reads when needed to make paths, tests, and handoff commands concrete.
-- During Metis planning, run pre-question research fan-out for every non-trivial intent unless the task is trivial, the cited spec is self-contained, or cached evidence already covers the same surface; use `explore` for repo facts and the exact cheap `gpt-5.6-terra` `researcher` lane for external docs / OSS references before asking the user. Prometheus Strict may fan out up to `2 explore + 4 researcher` agents per round so breadth comes from more citation-focused mini researchers while Metis/Momus/Oracle keep stronger judgment roles.
-- Recommend `$team` only when Oracle identifies independent, bounded, verifiable lanes.
-
-### Structured Question Surface
-
-Every Metis/Momus/Oracle question to the user MUST go through the surface-appropriate structured question path. Plain prose questioning is the last fallback, not the default.
-
-- In attached-tmux OMX runtime, use `omx question` as the OMX-owned structured question surface (this is the `AskUserQuestion` equivalent for Prometheus Strict). From attached-tmux Bash/tool paths, prefix the command with `OMX_QUESTION_RETURN_PANE=$TMUX_PANE` (or a concrete `%pane` value) so the leader-pane return target is preserved.
-- **Batch independent high-leverage questions into a single `questions[]` array call**: scope, constraints, non-goals, deliverables, safety bounds, and acceptance criteria are normally independent and MUST be batched into one structured form so the user answers them in a single panel. Reserve one-at-a-time only for dependent question chains where the next question depends on the previous answer.
-- Wait for the `omx question` JSON answer before checking the clearance rule, asking another round, or handing off; prefer `answers[]` / `answers[i].answer`, and use the legacy top-level `answer` only as a compatibility fallback. After every `answers[]` batch, run at least **two gap-fill passes** before another question or handoff: Pass 1 assimilates user answers into the checklist; Pass 2 re-scans repo context, prior turns, research fan-out evidence, and conservative defaults to absorb non-CRITICAL residual gaps.
-- Minimum two emitted question rounds: when Metis emits any user-facing question round, do not hand off after Round 1 unless hostility/`<turn_aborted>` or the round-5 cap forces exit; handoff is allowed only after Round 2 has been emitted and processed. Zero-question complete-checklist handoff remains valid when no questions were emitted.
-- Between-round planning must actively use evidence: after Round 1 answers and the two gap-fill passes, refresh or reuse `<research_fan_out>` explore/researcher evidence, re-run spec prefill, and build Round 2 from residual CRITICAL gaps only.
-- Outside tmux, use the native structured input tool when one is available.
-- When neither structured surface can render (non-tmux Codex CLI, piped runs, CI), list the round's independent questions as a numbered prose block (`Q1: ... Q2: ... Q3: ...`) and wait for all answers in one user turn; do not split into separate round-trips.
-- Multiple interview rounds ARE expected when clearance is not yet reached; each round is one batched form (or its prose fallback), never split across forms.
-
-### Checklist Clearance
-
-The interview is governed by deterministic checklist clearance, not by subjective "feels enough" judgement. Exit the Metis interview loop when the 6-item checklist is fully YES: objective / scope IN+OUT / acceptance / test strategy / handoff target / no outstanding CRITICAL. Each item is evaluated with the tri-state defined in `<Turn_Termination_Rules>`.
-
-Cap interview rounds at **5** to prevent runaway. If checklist clearance is not reached by round 5, hand the remaining UNKNOWN items to Oracle as explicitly carried-forward `<unresolved_blocker>` entries.
-
-**Hostility / non-answer exit**: if the user's responses for a round contain refusal signals (1-2 character non-answers, dismissive `알아서` / "you decide" / "whatever" patterns, profanity-laden responses, or a `<turn_aborted>` on the prior turn), the round invalidates the answers — it does NOT advance any checklist item to YES, exits the interview loop immediately, and routes the unresolved gaps either to `<silent_absorption>` (for dismissive delegation) or back to the user via `hostility_exit` (for anger / aborted turns). See `prometheus-strict-metis` `<hostility_detection>` for the full pattern list and routing rules.
-</Execution_Policy>
-
-<Turn_Termination_Rules>
-Every Prometheus Strict turn ends with EXACTLY ONE of the following terminations. Bare summaries and "I think we're done" are forbidden.
-
-The 6-item checklist is: objective / scope IN+OUT / acceptance / test strategy / handoff target / no outstanding CRITICAL. A checklist item is YES when it is USER_ANSWERED ∪ ABSORBED_WITH_CITATION ∪ INFERRED_FROM_SPEC. Only UNKNOWN (no answer, no citation, no spec inference) counts as NO.
-
-- (a) `omx question` batch: use when at least one CRITICAL question survives `<gap_triage>` and `<self_review>`. The batch is the round; the turn waits for `answers[]` before continuing.
-- (b) explicit handoff: use when the 6-item checklist is fully YES. Hand off Metis → Momus after clearance, Momus → Oracle after critique, and Oracle → user or `<unresolved_blocker>` carry-forward after Pass 2 synthesis.
-- (c) stop-blocker: use when hostility/`<turn_aborted>` is detected via `<hostility_detection>` with subtype `hostility_exit`, or when the next action is destructive, credential-gated, external-production, and cannot be defaulted safely.
-
-Edge cases:
-1. Zero-questions-but-complete-checklist → option (b) explicit handoff. Do not emit an empty `omx question` form.
-2. Round-5-cap with incomplete checklist → option (a) emit one more question batch with surviving UNKNOWN items annotated, OR option (b) handoff with UNKNOWN items carried forward to Oracle as `<unresolved_blocker>` entries.
-3. Hostility/`<turn_aborted>` → option (c) for anger, profanity, or aborted-turn via `hostility_exit`; option (b) for dismissive-delegation (`알아서` / "you decide") with absorbed gaps annotated.
-</Turn_Termination_Rules>
-
-<Steps>
-### 1. Intake and Safety Bounds
-
-Restate the target result, known constraints, deliverables, validation expectations, and stop condition. Identify whether this turn is planning-only or whether the user also requested downstream execution.
-
-If the prompt contains destructive, credential-gated, external-production, or materially scope-changing decisions, hold those decisions for explicit user confirmation. Otherwise, continue through the planning loop.
-
-### 2. Metis Interview (Iterative, Checklist Clearance)
-
-Use `prometheus-strict-metis` as the interview voice. When native subagents are available, invoke the dedicated agent; otherwise run the same role in-context without editing files.
-
-Metis discovers success criteria, non-goals, evidence versus assumptions, required artifacts, likely execution lanes, and missing decisions. Before the first user-facing question batch, Metis must actively fan out repo/external research per intent: `explore` maps local surfaces and exact `gpt-5.6-terra` `researcher` lanes gather official/upstream or OSS-reference evidence. Research-heavy intents use more cheap researchers rather than downgrading Metis/Momus/Oracle judgment.
-
-Run the interview as a bounded loop:
-
-1. Identify every currently-UNKNOWN checklist item and every CRITICAL question whose answers would materially change scope, safety, or validation.
-2. Batch the round's independent questions into a single Structured Question Surface call (`questions[]` array, or numbered prose fallback outside tmux).
-3. Collect the structured `answers[]`, then run **Gap-fill Pass 1 — answer assimilation**: update evidence vs. assumption and mark checklist items YES only when USER_ANSWERED, ABSORBED_WITH_CITATION, or INFERRED_FROM_SPEC.
-4. Run **Gap-fill Pass 2 — residual adversarial scan**: re-check every remaining UNKNOWN against repo context, prior turns, research fan-out evidence, framework/industry defaults, and conservative reversible defaults; absorb non-CRITICAL gaps with citations/assumptions and leave only CRITICAL blockers.
-5. Run **between-round planning** after Round 1: refresh or reuse `<research_fan_out>` explore/researcher evidence, re-run spec prefill, and prepare Round 2 from residual CRITICAL gaps only.
-6. Evaluate the 6-item checklist (`<Turn_Termination_Rules>` tri-state) only after BOTH gap-fill passes and the minimum two emitted question rounds gate; exit when ALL YES and either no questions were emitted or Round 2 has been emitted and processed.
-7. If checklist clearance is not reached, or only Round 1 has been processed, return to step 1 with the next round. Cap at 5 rounds; on cap, carry remaining UNKNOWN items forward to Oracle as explicit `<unresolved_blocker>` entries.
-
-### 3. Momus Challenge (Bounded Retry)
-
-Use `prometheus-strict-momus` as the adversarial critique voice. When native subagents are available, invoke the dedicated agent; otherwise run the same role in-context without editing files.
-
-Momus challenges underspecified acceptance criteria, unsafe assumptions, hidden destructive steps, overbroad scope, missing verification, ownership conflicts, and `$ultragoal`/`$team` handoff ambiguity.
-
-**Bounded retry contract**: after Oracle synthesizes in §4, re-invoke Momus on the synthesized plan to verify that Oracle's resolutions did not introduce new risks (scope addition without matching verification, lane split that creates dependency cycles, safety reinforcement that contradicts stop conditions). Repeat the Momus → Oracle re-synthesis cycle up to **3 times total**. If blocking objections remain after the 3rd cycle, mark them as carried-forward in the final plan and proceed to §5.
-
-### 4. Oracle Synthesis (Two-Pass: Synthesis + Self-Verification)
-
-Use `prometheus-strict-oracle` as the synthesis voice. When native subagents are available, invoke the dedicated agent; otherwise run the same role in-context without editing files.
-
-**Pass 1 — Synthesis.** Oracle produces the final objective, scope and non-goals, accepted assumptions, resolved critique, sequenced steps or lanes, verification matrix, rollback/escalation conditions, and recommended OMX handoff.
-
-**Pass 2 — Self-Verification (machine-checkable acceptance contract).** Oracle re-reads its own Pass 1 output and asserts:
-
-- Every claim in the verification matrix has an explicit evidence source (test/build/lint/e2e/doc).
-- Every step lists its owner / lane / executor; no shared-file conflicts between parallel lanes.
-- Stop, rollback, and acceptance criteria are mutually consistent (no acceptance criterion is satisfied by a state that also triggers rollback).
-- No destructive, credential-gated, or external-production step is unauthorized.
-- The handoff command is concrete (callable verbatim) and points at an existing workflow (`$ultragoal`, `$team`, or `none`).
-- Clean-room credit is preserved.
-
-If any Pass 2 check fails, Oracle MUST loop back to Pass 1 to repair before emitting the plan. Cap Pass 1 ↔ Pass 2 cycles at **3**; on cycle 3 failure, emit the plan with the failing gates annotated as carried-forward and escalate to the user.
-
-### 5. Post-Plan Gap Check (Metis Re-Invocation)
-
-Before handing off, re-invoke `prometheus-strict-metis` on the finalized Oracle plan with a single charge: identify ambiguities that surfaced **only after** the plan was rendered — for example, new lane assignments that overlap, verification matrix gaps revealed by stop conditions, acceptance criteria that contradict the rollback contract.
-
-If post-plan Metis surfaces any blocking gap, return to §4 Pass 1 with the new question. Otherwise proceed to §6.
-
-### 6. Handoff
-
-Prometheus Strict stops with a plan unless the user explicitly invokes or authorizes the next workflow. Prefer this sequence:
-
-```text
-$ultragoal "<Oracle plan summary or .omx/plans/prometheus-strict/<slug>.md>"
-$team <N>:executor "execute the approved Ultragoal story in parallel lanes"  # only when warranted
-```
-</Steps>
-
-<Tool_Usage>
-- Use read-only repository inspection to verify referenced files, commands, and existing conventions.
-- Treat Metis research fan-out as part of planning, not execution: dispatch `explore` / exact `gpt-5.6-terra` `researcher` evidence-gathering before question generation for non-trivial intents, then re-prefill and ask only surviving CRITICAL gaps.
-- Use `prometheus-strict-metis`, `prometheus-strict-momus`, and `prometheus-strict-oracle` sequentially; do not fan out implementation work from this skill.
-- Use `$ultragoal` only as the recommended execution handoff after the plan is ready.
-- Use `$team` only when parallel lanes are independent and verifiable.
-</Tool_Usage>
-
-## State Management
-
-Prometheus Strict does not own a long-running runtime loop. If a durable planning artifact is needed, write the final plan to `.omx/plans/prometheus-strict/<slug>.md`. Draft-only or inline plans may set the artifact path to `N/A - inline plan only`.
-
-Do not create hook state, Sisyphus state, or `start-work` compatibility state for this skill.
-
-<Final_Checklist>
-- [ ] Target result is explicit.
-- [ ] Scope and non-goals are explicit.
-- [ ] Acceptance criteria are measurable.
-- [ ] Metis interview loop reached checklist clearance only after the mandatory two gap-fill passes following every `answers[]` batch and, if any question round was emitted, after the minimum two emitted question rounds gate; otherwise the 5-round cap was reached with UNKNOWN items carried forward as `<unresolved_blocker>` entries.
-- [ ] Momus objections are resolved or carried forward as explicit blockers, with at most 3 Momus → Oracle re-synthesis cycles consumed.
-- [ ] Oracle plan includes a verification matrix.
-- [ ] Oracle Pass 2 self-verification completed; every machine-checkable contract item passes or is annotated as carried-forward.
-- [ ] Post-plan Metis gap check produced no blocking objections (or all are carried forward).
-- [ ] Handoff recommends `$ultragoal` and `$team` only when warranted.
-- [ ] Clean-room credit is preserved.
-- [ ] No hook implementation or Sisyphus/start-work port was introduced.
-</Final_Checklist>
-
-<Advanced>
-## Output Contract
-
-If writing a durable plan file, store this markdown at `.omx/plans/prometheus-strict/<slug>.md` and reference that path in the handoff.
-
-```markdown
-## Prometheus Strict Plan
-
-### Target Result
-- <one-sentence objective>
-
-### Clarified Requirements (Metis)
-- <requirement / acceptance criterion>
-
-### Critique Resolved (Momus)
-- <risk or objection> -> <resolution>
-
-### Oracle Execution Plan
-1. <sequenced step or lane>
-
-### Verification Matrix
-| Claim | Required evidence | Owner/lane |
-| --- | --- | --- |
-| <claim> | <test/build/lint/e2e/doc evidence> | <owner> |
-
-### Artifact
-- Durable plan path: `.omx/plans/prometheus-strict/<slug>.md` or `N/A - inline plan only`
-
-### Handoff
-- Recommended next workflow: <$ultragoal / $team / direct execution / none>
-- Stop condition: <what proves the plan is ready or why it is blocked>
-
-### Clean-Room Credit
-Inspired by OMO Prometheus (`code-yeongyu/oh-my-openagent`), reimplemented from concept under MIT.
-```
-
-## Failure and Escalation
-
-Escalate instead of planning when a necessary answer cannot be inferred safely, the next step is destructive or credential-gated, required repository context is unavailable, or the user asks for behavior outside the non-goals.
-</Advanced>
-
-Original task:
-{{PROMPT}}

package/skills/ralph-init/SKILL.md

@@ -1,10 +0,0 @@
----
-name: ralph-init
-description: Ralph Init deprecated skill
----
-
-# Ralph Init deprecated
-
-Hard-deprecated. Do not invoke or route this skill. Use `$ralph` directly after PRD/test-spec planning is complete.
-
-Task: {{ARGUMENTS}}

package/skills/review/SKILL.md

@@ -1,10 +0,0 @@
----
-name: review
-description: Deprecated standalone review skill
----
-
-# Review deprecated
-
-Hard-deprecated. Do not invoke or route this skill. Use `$code-review` directly for implementation review, or `$plan --review` only when explicitly reviewing an existing planning artifact.
-
-Task: {{ARGUMENTS}}

package/skills/security-review/SKILL.md

@@ -1,10 +0,0 @@
----
-name: security-review
-description: Deprecated standalone security review skill
----
-
-# Security Review deprecated
-
-Hard-deprecated. Do not invoke or route this skill. Use `$code-review` directly for new review workflows when security concerns are in scope.
-
-Task: {{ARGUMENTS}}

package/skills/swarm/SKILL.md

@@ -1,12 +0,0 @@
----
-name: swarm
-description: Deprecated compatibility shim for team execution
----
-
-# Swarm compatibility shim
-
-Hard-deprecated. Do not invoke or route this skill for new work.
-
-Use `$team` or `omx team` directly for coordinated multi-agent execution. This file exists only to preserve the public/catalog-visible `swarm` skill contract while Team mode owns coordinated execution.
-
-Task: {{ARGUMENTS}}

package/skills/tdd/SKILL.md

@@ -1,104 +0,0 @@
----
-name: tdd
-description: TDD deprecated shim
----
-
-# TDD deprecated
-
-Hard-deprecated. Do not invoke or route this skill. Keep test-first discipline inside the active implementation workflow and verify with the project test suite.
-
-## The Iron Law
-
-**NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST**
-
-Write code before test? DELETE IT. Start over. No exceptions.
-
-## Red-Green-Refactor Cycle
-
-### 1. RED: Write Failing Test
-- Write test for the NEXT piece of functionality
-- Run test - MUST FAIL
-- If it passes, your test is wrong
-
-### 2. GREEN: Minimal Implementation
-- Write ONLY enough code to pass the test
-- No extras. No "while I'm here."
-- Run test - MUST PASS
-
-### 3. REFACTOR: Clean Up
-- Improve code quality
-- Run tests after EVERY change
-- Must stay green
-
-### 4. REPEAT
-- Next failing test
-- Continue cycle
-
-## Enforcement Rules
-
-| If You See | Action |
-|------------|--------|
-| Code written before test | STOP. Delete code. Write test first. |
-| Test passes on first run | Test is wrong. Fix it to fail first. |
-| Multiple features in one cycle | STOP. One test, one feature. |
-| Skipping refactor | Go back. Clean up before next feature. |
-
-## Commands
-
-Before each implementation:
-```bash
-# Run the project's test command - should have ONE new failure
-```
-
-After implementation:
-```bash
-# Run the project's test command - new test should pass, all others still pass
-```
-
-## Output Format
-
-When guiding TDD:
-
-```
-## TDD Cycle: [Feature Name]
-
-### RED Phase
-Test: [test code]
-Expected failure: [what error you expect]
-Actual: [run result showing failure]
-
-### GREEN Phase
-Implementation: [minimal code]
-Result: [run result showing pass]
-
-### REFACTOR Phase
-Changes: [what was cleaned up]
-Result: [tests still pass]
-```
-
-## External Model Consultation (Preferred)
-
-The tdd-guide agent SHOULD consult Codex for test strategy validation.
-
-### Protocol
-1. **Form your OWN test strategy FIRST** - Design tests independently
-2. **Consult for validation** - Cross-check test coverage strategy
-3. **Critically evaluate** - Never blindly adopt external suggestions
-4. **Graceful fallback** - Never block if tools unavailable
-
-### When to Consult
-- Complex domain logic requiring comprehensive test coverage
-- Edge case identification for critical paths
-- Test architecture for large features
-- Unfamiliar testing patterns
-
-### When to Skip
-- Simple unit tests
-- Well-understood testing patterns
-- Time-critical TDD cycles
-- Small, isolated functionality
-
-### Tool Usage
-Prefer native `test-engineer` consultation or CLI-backed ask surfaces when available. Optional MCP compatibility ask tools may be used only when already enabled. If consultation tools are unavailable, fall back to the `test-engineer` agent.
-
-**Remember:** The discipline IS the value. Shortcuts destroy the benefit.

package/skills/trace/SKILL.md

@@ -1,10 +0,0 @@
----
-name: trace
-description: Trace deprecated shim
----
-
-# Trace deprecated
-
-Hard-deprecated. Do not invoke or route this skill. Use maintained OMX trace/runtime inspection surfaces directly when trace evidence is needed.
-
-Task: {{ARGUMENTS}}