oh-my-codex 0.15.3 → 0.16.0

package/skills/tdd/SKILL.md

@@ -1,106 +1,10 @@
 ---
 name: tdd
-description: Test-Driven Development enforcement skill - write tests first, always
+description: TDD deprecated shim
 ---
 
-# TDD Mode
+# TDD deprecated
 
-[TDD MODE ACTIVATED]
+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
-Before first MCP tool use, call `ToolSearch("mcp")` to discover deferred MCP tools.
-Use `mcp__x__ask_codex` with `agent_role: "tdd-guide"`.
-If ToolSearch finds no MCP tools, fall back to the `test-engineer` agent.
-
-**Remember:** The discipline IS the value. Shortcuts destroy the benefit.
+Task: {{ARGUMENTS}}

package/skills/team/SKILL.md

@@ -156,7 +156,7 @@ Important:
 - Worker panes are independent full Codex/Claude CLI sessions
 - Workers may run in separate git worktrees (`omx team --worktree[=<name>]`) while sharing one team state root
 - Worker ACKs go to `mailbox/leader-fixed.json`
-- Notify hook updates worker heartbeat and nudges leader during active team mode
+- Notify hook updates worker heartbeat and sends lifecycle-driven leader nudges (for example resolved native worker Stop/all-idle or stale-leader evidence) during active team mode; deprecated worker stall/progress heuristics are not operator-facing guidance.
 - Submit routing uses this CLI resolution order per worker trigger:
   1) explicit worker CLI provided by runtime state (persisted on worker identity/config),
   2) `OMX_TEAM_WORKER_CLI_MAP` entry for that worker index,
@@ -221,7 +221,11 @@ sleep 30 && omx team status <team-name>
 
 Repeat that check while the team stays active, or use `omx team await <team-name> --timeout-ms 30000 --json` when event-driven waiting is a better fit.
 
-If the leader gets a stale/team-stalled nudge, immediately run `omx team status <team-name>` before taking any manual intervention.
+If the leader gets a stale, lifecycle, or all-idle nudge, immediately run `omx team status <team-name>` before taking any manual intervention. Deprecated worker stall/progress nudges should not be treated as an active runtime contract.
+
+### Deprecated worker stall/progress knobs
+
+`OMX_TEAM_PROGRESS_STALL_MS` and `OMX_TEAM_WORKER_TURN_STALL_MS` are legacy compatibility/test-only names for the retired worker stall/progress nudge path. Do not recommend them as operator tuning knobs for active team runs; resolved native worker Stop, all-idle, mailbox, and stale-leader evidence are the supported leader wakeup signals.
 
 ## Message Dispatch Policy (CLI-first, state-first)
 

package/skills/trace/SKILL.md

@@ -1,33 +1,10 @@
 ---
 name: trace
-description: Show agent flow trace timeline and summary
+description: Trace deprecated shim
 ---
 
-# Agent Flow Trace
+# Trace deprecated
 
-[TRACE MODE ACTIVATED]
+Hard-deprecated. Do not invoke or route this skill. Use maintained OMX trace/runtime inspection surfaces directly when trace evidence is needed.
 
-## Objective
-
-Display the flow trace showing how hooks, keywords, skills, agents, and tools interacted during this session.
-
-## Instructions
-
-1. **Use `trace_timeline` MCP tool** to show the chronological event timeline
-   - Call with no arguments to show the latest session
-   - Use `filter` parameter to focus on specific event types (hooks, skills, agents, keywords, tools, modes)
-   - Use `last` parameter to limit output
-
-2. **Use `trace_summary` MCP tool** to show aggregate statistics
-   - Hook fire counts
-   - Keywords detected
-   - Skills activated
-   - Mode transitions
-   - Tool performance and bottlenecks
-
-## Output Format
-
-Present the timeline first, then the summary. Highlight:
-- **Mode transitions** (how execution modes changed)
-- **Bottlenecks** (slow tools or agents)
-- **Flow patterns** (keyword -> skill -> agent chains)
+Task: {{ARGUMENTS}}

package/skills/ultragoal/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: ultragoal
+description: Create and execute durable repo-native multi-goal plans over Codex goal mode artifacts.
+---
+
+# Ultragoal Workflow
+
+Use when the user asks for `ultragoal`, `create-goals`, `complete-goals`, durable multi-goal planning, or sequential execution over Codex `/goal`.
+
+## Purpose
+
+`ultragoal` turns a brief into repo-native artifacts and then drives one goal at a time through Codex goal tools:
+
+- `.omx/ultragoal/brief.md`
+- `.omx/ultragoal/goals.json`
+- `.omx/ultragoal/ledger.jsonl`
+
+## Create goals
+
+1. Run one of:
+   - `omx ultragoal create-goals --brief "<brief>"`
+   - `omx ultragoal create-goals --brief-file <path>`
+   - `cat <brief> | omx ultragoal create-goals --from-stdin`
+2. Inspect `.omx/ultragoal/goals.json` and refine if needed.
+
+## Complete goals
+
+Loop until `omx ultragoal status` reports all goals complete:
+
+1. Run `omx ultragoal complete-goals`.
+2. Read the printed handoff.
+3. Call `get_goal`.
+4. If no active Codex goal exists, call `create_goal` with the printed payload.
+5. Complete that single goal only.
+6. Run a completion audit against the objective and real artifacts/tests.
+7. When complete, call `update_goal({status: "complete"})`, then call `get_goal` again for a fresh completion snapshot.
+8. Checkpoint the durable ledger with that snapshot:
+   `omx ultragoal checkpoint --goal-id <id> --status complete --evidence "<evidence>" --codex-goal-json <get_goal-json-or-path>`
+9. If blocked or failed, checkpoint failure:
+   `omx ultragoal checkpoint --goal-id <id> --status failed --evidence "<blocker/evidence>"`
+10. Resume failed goals with `omx ultragoal complete-goals --retry-failed`.
+
+## Constraints
+
+- The shell command cannot directly invoke Codex interactive `/goal`; it emits a model-facing handoff for the active Codex agent.
+- Never call `create_goal` when `get_goal` reports a different active goal.
+- Never call `update_goal` unless the current goal is actually complete.
+- Completion checkpoints require read-only Codex snapshot reconciliation: pass fresh `get_goal` JSON/path with `--codex-goal-json`; shell commands and hooks must not mutate Codex goal state.
+- Treat `ledger.jsonl` as the durable audit trail; checkpoint after every success or failure.

package/skills/visual-ralph/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: visual-ralph
-description: "Visual Ralph orchestration for frontend UI from generated references, static references, or live URL targets, using $ralph with $visual-verdict and pixel-diff evidence until the implementation matches and leaves a reproducible design system."
+description: "Visual Ralph orchestration for frontend UI from generated references, static references, or live URL targets, using $ralph with built-in visual verdict and pixel-diff evidence until the implementation matches and leaves a reproducible design system."
 ---
 
 # Visual Ralph Skill
@@ -11,7 +11,7 @@ Use this skill when the user wants Codex to build or restyle frontend UI through
 
 Create a measured frontend delivery loop from either a generated reference, a static reference, or a live URL:
 
-`user description / live URL -> approved visual reference -> $ralph implementation -> $visual-verdict + pixel diff -> reproducible design system`.
+`user description / live URL -> approved visual reference -> $ralph implementation -> Visual Ralph verdict + pixel diff -> reproducible design system`.
 
 For live URL cloning requests, Visual Ralph owns the migrated `$web-clone` use case. Do not route new URL-driven website cloning work to `$web-clone`; preserve the URL, viewport, fidelity requirements, and interaction notes inside the Visual Ralph loop.
 
@@ -29,7 +29,7 @@ This is an orchestration skill. It composes existing skills and must not add run
 
 - The user only wants design critique or general frontend advice; use `$frontend-ui-ux` or a designer lane.
 - The task is a non-visual backend/API implementation with no UI reference target.
-- The user already supplied a final static reference image and only needs comparison/fixes; hand directly to `$ralph` with `$visual-verdict` guidance.
+- The user already supplied a final static reference image and only needs comparison/fixes; hand directly to `$ralph` with Visual Ralph verdict guidance.
 - The requested output is a deterministic SVG/vector/code-native asset rather than a raster reference.
 
 ## Workflow
@@ -90,20 +90,20 @@ Invoke `$ralph` with:
 
 Ralph may iterate autonomously after approval. It should edit code, run the app, capture screenshots, and keep improving until the approved reference is matched or a real blocker exists.
 
-### 5. Use `$visual-verdict` before every next edit
+### 5. Use Visual Ralph verdict before every next edit
 
 For each visual iteration:
 1. Capture the current generated screenshot with recorded viewport/state.
-2. Run `$visual-verdict` comparing the approved reference and generated screenshot.
+2. Run the Visual Ralph verdict step comparing the approved reference and generated screenshot. Use the `vision` agent for image understanding when needed.
 3. Treat the JSON verdict as authoritative.
 4. If `score < 90`, convert `differences[]` and `suggestions[]` into the next edit plan.
 5. Rerun before the next edit.
 
-Required verdict shape is inherited from `$visual-verdict`: `score`, `verdict`, `category_match`, `differences[]`, `suggestions[]`, and `reasoning`.
+Required verdict shape: `score`, `verdict`, `category_match`, `differences[]`, `suggestions[]`, and `reasoning`.
 
 ### 6. Use pixel diff only as secondary debug evidence
 
-When mismatch diagnosis is hard, generate a pixel diff or pixelmatch overlay to locate hotspots. Pixel diff does not replace `$visual-verdict`; it only helps translate visual hotspots into concrete edits.
+When mismatch diagnosis is hard, generate a pixel diff or pixelmatch overlay to locate hotspots. Pixel diff does not replace the Visual Ralph verdict; it only helps translate visual hotspots into concrete edits.
 
 Record final diff evidence with the reference/screenshot artifacts so the result can be audited.
 
@@ -126,7 +126,7 @@ Prefer existing token/component patterns. Do not introduce a new design-system l
 Do not declare done until all are true:
 - Approved reference image or URL-derived reference artifact is saved in the workspace.
 - Screenshot reproduction command, viewport, route, seed/state, and output paths are documented.
-- `$visual-verdict` final score is `>= 90` against the approved reference.
+- Visual Ralph verdict final score is `>= 90` against the approved reference.
 - Pixel diff or overlay evidence is recorded as secondary debug evidence.
 - Design-system tokens/components are repo-native and reusable.
 - Build/lint/test or the repo's equivalent verification passes.
@@ -143,7 +143,7 @@ Viewport/content state: <viewport, route/state, seed/login assumptions>
 Interaction parity notes: <visible controls and known exclusions>
 Route/surface: <route or component>
 Screenshot command: <command and viewport>
-Use $visual-verdict before every next edit; pass threshold score >= 90.
+Use the Visual Ralph verdict step before every next edit; pass threshold score >= 90.
 Use pixel diff only as secondary debug evidence.
 Extract reusable design tokens/components for colors, spacing, typography, radii, shadows, and key variants.
 Run build/lint/test before completion.

package/skills/visual-verdict/SKILL.md

@@ -1,76 +1,10 @@
 ---
 name: visual-verdict
-description: Structured visual QA verdict for screenshot-to-reference comparisons
+description: Visual Verdict deprecated skill
 ---
 
-<Purpose>
-Use this skill to compare generated UI screenshots against one or more reference images and return a strict JSON verdict that can drive the next edit iteration.
-</Purpose>
+# Visual Verdict deprecated
 
-<Use_When>
-- The task includes visual fidelity requirements (layout, spacing, typography, component styling)
-- You have a generated screenshot and at least one reference image
-- You need deterministic pass/fail guidance before continuing edits
-</Use_When>
+Hard-deprecated. Do not invoke or route this skill. Use `$visual-ralph` directly; visual verdict scoring is part of that workflow.
 
-<Inputs>
-- `reference_images[]` (one or more image paths)
-- `generated_screenshot` (current output image)
-- Optional: `category_hint` (e.g., `hackernews`, `sns-feed`, `dashboard`)
-</Inputs>
-
-<Output_Contract>
-Return **JSON only** with this exact shape:
-
-```json
-{
-  "score": 0,
-  "verdict": "revise",
-  "category_match": false,
-  "differences": ["..."],
-  "suggestions": ["..."],
-  "reasoning": "short explanation"
-}
-```
-
-Rules:
-- `score`: integer 0-100
-- `verdict`: short status (`pass`, `revise`, or `fail`)
-- `category_match`: `true` when the generated screenshot matches the intended UI category/style
-- `differences[]`: concrete visual mismatches (layout, spacing, typography, colors, hierarchy)
-- `suggestions[]`: actionable next edits tied to the differences
-- `reasoning`: 1-2 sentence summary
-
-<Threshold_And_Loop>
-- Target pass threshold is **90+**.
-- If `score < 90`, continue editing and rerun `$visual-verdict` before any further code edits in the next iteration.
-- Persist the verdict in `.omx/state/{scope}/ralph-progress.json` with both:
-  - numeric signal (`score`, threshold pass/fail)
-  - qualitative signal (`reasoning`, `suggestions`, `next_actions`)
-</Threshold_And_Loop>
-
-<Debug_Visualization>
-When mismatch diagnosis is hard:
-1. Keep `$visual-verdict` as the authoritative decision.
-2. Use pixel-level diff tooling (pixel diff / pixelmatch overlay) as a **secondary debug aid** to localize hotspots.
-3. Convert pixel diff hotspots into concrete `differences[]` and `suggestions[]` updates.
-</Debug_Visualization>
-
-<Example>
-```json
-{
-  "score": 87,
-  "verdict": "revise",
-  "category_match": true,
-  "differences": [
-    "Top nav spacing is tighter than reference",
-    "Primary button uses smaller font weight"
-  ],
-  "suggestions": [
-    "Increase nav item horizontal padding by 4px",
-    "Set primary button font-weight to 600"
-  ],
-  "reasoning": "Core layout matches, but style details still diverge."
-}
-```
-</Example>
+Task: {{ARGUMENTS}}

package/skills/web-clone/SKILL.md

@@ -1,24 +1,10 @@
 ---
 name: web-clone
-description: "DEPRECATED: URL-driven website cloning has moved into $visual-ralph; use $visual-ralph for live-URL visual implementation workflows."
+description: Web Clone deprecated shim
 ---
 
-# Web Clone Skill (Hard Deprecated)
+# Web Clone deprecated
 
-`$web-clone` is hard-deprecated. Do not start new work through this skill.
+Hard-deprecated. Do not invoke or route this skill. Use `$visual-ralph` directly for live-URL visual implementation and visual QA workflows.
 
-## Migration
-
-Use `$visual-ralph` for the migrated live-URL use case. Visual Ralph now owns URL-driven visual implementation loops alongside generated-image and static-reference workflows:
-
-- live URL or website cloning request -> `$visual-ralph`
-- generated mockup/reference request -> `$visual-ralph` with `$imagegen`
-- static screenshot/reference comparison -> `$ralph` with `$visual-verdict`
-
-## Behavior
-
-If this skill is selected by older routing, stop the standalone web-clone pipeline and reroute the task to `$visual-ralph` instead. Preserve the user's target URL, fidelity requirements, viewport constraints, and functional parity notes in the Visual Ralph handoff.
-
-## Rationale
-
-The URL extraction, visual iteration, and implementation verification responsibilities are now part of Visual Ralph's broader visual-delivery workflow. Keeping a second standalone cloning skill would split guidance and make verification behavior drift.
+Task: {{ARGUMENTS}}