Oh My Codex (OMX)

The prometheus-strict skill is a clean-room, interview-driven planner designed for high-precision task planning. It follows a rigorous multi-stage process to ensure clarity and robustness before execution. The workflow involves:

1. Intake and Safety Bounds: Establishing the initial scope and constraints.
2. Metis Interview: An iterative process of checklist clearance to clarify requirements.
3. Momus Challenge: A bounded retry phase where the plan is challenged to find weaknesses.
4. Oracle Synthesis: A two-pass phase consisting of initial synthesis followed by self-verification.
5. Post-Plan Gap Check: A final re-invocation of the Metis process to ensure no gaps remain.
6. Handoff: Passing the verified plan to the $ultragoal or the designated $team.

Use this skill when you require a highly structured, verified plan that minimizes ambiguity and maximizes safety through iterative questioning and challenging.

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>"

The showcase includes several distinct optimization demos:

1. OMX self-optimization: Demonstrates a self-hosted code optimization loop where autoresearch removes unnecessary shell-outs from OMX.

   • Mission: missions/in-action-cat-shellout-demo/
   • Evaluator: scripts/eval-in-action-cat-shellout-demo.js

2. Kaggle-style tabular ML: Model-family and hyperparameter search on a deterministic tabular classification benchmark.

   • Mission: missions/ml-kaggle-model-optimization/
   • Evaluator: scripts/eval-ml-kaggle-model-optimization.py

3. Noisy high-dimensional Bayes-opt: Black-box optimization with noise and limited budget. Successful runs switch from random search to subspace-aware fixed-kernel GP.

   • Mission: missions/noisy-bayesopt-highdim/
   • Evaluator: scripts/eval-noisy-bayesopt-highdim.py

4. Latent subspace discovery: A variant of Bayes-opt where structure is hidden through latent directions.

   • Mission: missions/noisy-latent-subspace-discovery/
   • Evaluator: scripts/eval-noisy-latent-subspace-discovery.py

5. Adaptive sorting optimization: Algorithm-engineering optimization using weighted comparison/move costs on a mixed-distribution sorting benchmark.

   • Mission: missions/adaptive-sort-optimization/
   • Evaluator: scripts/eval-adaptive-sort-optimization.py

The OMX Wiki is a compiled markdown knowledge layer designed specifically for agentic retrieval workflows. Unlike traditional vector-first RAG (Retrieval-Augmented Generation), the wiki is built to be 'search-first' and 'markdown-first'.

Key characteristics:

• Commit-friendly: Knowledge is stored under the omx_wiki/ directory within your repository, making it visible to both humans and agents.
• Source-visible: It is intended to be reviewed and committed alongside code changes.
• No Vector Embeddings: It does not require vector embeddings to function, relying instead on structured markdown and search-based retrieval.

Retrieval Model: Agents query wiki pages first. If the wiki evidence is weak or missing, the system falls back to a broader repository search. Note that omx explore is deprecated; users should prefer the wiki workflow combined with standard Codex repository inspection.

Prometheus Strict is a rigorous, clean-room planning workflow in OMX designed to create high-fidelity plans before any code execution begins. It is used to separate planning voices (Metis, Momus, and Oracle) to ensure requirements are unambiguous and risks are mitigated.

Use When:

• The task is high-stakes and a shallow plan could lead to incorrect work.
• Requirements are partially known, but acceptance criteria, boundaries, risks, or validation methods are incomplete.
• You require a strict interview process before execution.
• You need a durable plan (stored in .omx/plans/prometheus-strict/) for a future $ultragoal story or a $team split.

Do Not Use When:

• The user requests immediate implementation of a clear, low-risk change (use the normal executor path).
• The task is a simple repository lookup or explanation (use explore or analyze).
• You need adversarial execution QA after code changes (use $ultraqa).

Ultrawork is a parallel execution engine designed for high-throughput task completion. It provides parallelism, context discipline, and smart delegation guidance.

Note: Ultrawork is a component, not a standalone persistence or verification mode. It does not provide durable goal tracking, tmux worker lifecycle management, or long-running completion guarantees.

Use Ultrawork when:

• Multiple independent tasks can run simultaneously.
• The user requests parallel execution (e.g., via ulw or ultrawork).
• The task benefits from concurrent execution combined with lightweight evidence before wrap-up.
• You need a direct-tool lane plus optional background evidence lanes without entering a full team or durable goal workflow.

Do NOT use Ultrawork when:

• Durable goal tracking is needed (use ultragoal).
• Coordinated tmux workers or shared task state is required (use team).
• A full autonomous pipeline is required (use autopilot).
• The legacy persistent single-owner loop is explicitly requested (use ralph).
• The task is purely sequential with no parallelism opportunity.

Overview

ultragoal is a durable, repo-native multi-goal workflow that layers over Codex's native goal mode. While Codex goal mode tracks the active thread focus via model tools (get_goal, create_goal, update_goal), Ultragoal manages the long-range plan and state within the repository files.

Mental Model: Aggregate vs. Per-Story

• Aggregate Codex Goal Mode (Default): Codex receives a single, high-level objective for the entire Ultragoal run. OMX manages the individual story states (e.g., G001, G002) and the audit ledger. This prevents the need for impossible same-thread transitions between multiple Codex goals.
• Per-Story Mode: One Codex thread is used per story. This is a legacy or explicitly requested mode for users who want a dedicated Codex context for every sub-goal.

Important Constraint: Goal Clearing

Ultragoal cannot call Codex /goal clear. If you finish an Ultragoal run and want to start a new one in the same thread, you must manually run /goal clear in the Codex UI before calling create_goal. Otherwise, get_goal may report the previous completed objective, blocking the new run.

Ralph is a persistence loop designed for tasks that require guaranteed completion and architect-level verification. Unlike standard executor agents that might provide a 'best effort' one-shot fix, Ralph wraps execution with session persistence, automatic retries, and mandatory verification steps to prevent silent failures like partial implementations or skipped tests.

Use Ralph when:

• You need guaranteed task completion with verification.
• You use trigger phrases like "ralph", "don't stop", "must complete", or "keep going until done".
• The work requires multiple iterations and needs to persist across retries.
• The task benefits from parallel execution followed by a final architect sign-off.

Do NOT use Ralph when:

• You want a fully autonomous pipeline from idea to code (use autopilot).
• You want to explore or plan before committing (use plan).
• You need a quick one-shot fix (delegate to an executor agent).
• You want manual control over the completion process (use ultrawork directly).