oh-my-codex 0.15.2 → 0.16.0

package/plugins/oh-my-codex/skills/ralph/SKILL.md

@@ -36,6 +36,7 @@ Complex tasks often fail silently: partial implementations get declared "done",
 - Read `docs/shared/agent-tiers.md` before first delegation to select correct agent tiers
 - Deliver the full implementation: no scope reduction, no partial completion, no deleting tests to make them pass
 - Apply the shared workflow guidance pattern: outcome-first framing, concise visible updates for multi-step execution, local overrides for the active workflow branch, validation proportional to risk, explicit stop rules, and automatic continuation for safe reversible steps. Ask only for material, destructive, credentialed, external-production, or preference-dependent branches.
+- Integrate with Codex goal mode when goal tools are available: inspect the active thread goal with `get_goal`, preserve it as the top-level stop condition, and only call `update_goal({status: "complete"})` after a Ralph completion audit proves the objective is actually achieved.
 </Execution_Policy>
 
 <Steps>
@@ -60,12 +61,13 @@ Complex tasks often fail silently: partial implementations get declared "done",
    - When Ralph is entered as a ralplan follow-up, start from the approved **available-agent-types roster** and make the delegation plan explicit: implementation lane, evidence/regression lane, and final sign-off lane using only known agent types
 4. **Run long operations in background**: Builds, installs, test suites use `run_in_background: true`
 5. **Visual task gate (when screenshot/reference images are present)**:
-   - Run `$visual-verdict` **before every next edit**.
+   - Run the Visual Ralph verdict step **before every next edit**.
    - Require structured JSON output: `score`, `verdict`, `category_match`, `differences[]`, `suggestions[]`, `reasoning`.
    - Persist verdict to `.omx/state/{scope}/ralph-progress.json` including numeric + qualitative feedback.
    - Default pass threshold: `score >= 90`.
-   - **URL-based visual cloning tasks**: When the task description contains a target URL (e.g., "clone https://example.com"), route the work through `$visual-ralph`. `$web-clone` is hard-deprecated; Visual Ralph owns the migrated live-URL visual implementation use case and uses `$visual-verdict` for measured visual scoring.
+   - **URL-based visual cloning tasks**: When the task description contains a target URL (e.g., "clone https://example.com"), route the work through `$visual-ralph`. `$web-clone` is hard-deprecated; Visual Ralph owns the migrated live-URL visual implementation use case and uses its built-in visual verdict step for measured visual scoring.
 6. **Verify completion with fresh evidence**:
+   - If Codex goal mode is available, call `get_goal` before final verification to restate the active objective and include it in the evidence checklist.
    a. Identify what command proves the task is complete
    b. Run verification (test, build, lint)
    c. Read the output -- confirm it actually passed
@@ -84,7 +86,7 @@ Complex tasks often fail silently: partial implementations get declared "done",
    - After the deslop pass, re-run all tests/build/lint and read the output to confirm they still pass.
    - If post-deslop regression fails, roll back cleaner changes or fix and retry. Then rerun Step 7.5 and Step 7.6 until the regression is green.
    - Do not proceed to completion until post-deslop regression is green (unless `--no-deslop` explicitly skipped the deslop pass).
-8. **On approval**: Run `/cancel` to cleanly exit and clean up all state files
+8. **On approval**: If Codex goal mode is active, call `update_goal({status: "complete"})` before `/cancel`; report final elapsed time and token-budget usage when the tool returns it. Then run `/cancel` to cleanly exit and clean up all state files.
 9. **On rejection**: Fix the issues raised, then re-verify at the same tier
 </Steps>
 
@@ -94,10 +96,26 @@ Complex tasks often fail silently: partial implementations get declared "done",
 - Skip Codex consultation for simple feature additions, well-tested changes, or time-critical verification
 - If ToolSearch finds no MCP tools or Codex is unavailable, proceed with architect agent verification alone -- never block on external tools
 - Use `state_write` / `state_read` for ralph mode state persistence between iterations
+- Use Codex goal tools when present: `get_goal` to discover or re-check the active objective, `create_goal` only when the user/system explicitly requested a new goal and no active goal exists, and `update_goal` only after the audited objective is fully achieved.
 - Persist context snapshot path in Ralph mode state so later phases and agents share the same grounding context
 - If an `omx_state` MCP tool call reports that its stdio transport is unavailable/closed, do **not** retry the same MCP call. Retry once through the supported CLI parity surface with the same payload, preserving `workingDirectory` and `session_id`: `omx state write --input '<json>' --json`, `omx state read --input '<json>' --json`, or `omx state clear --input '<json>' --json`. If the CLI path also fails, continue with `.omx/context` / `.omx/plans` file-backed artifacts and report the state persistence blocker.
 </Tool_Usage>
 
+## Goal Mode Integration
+
+Codex goal mode is the thread-level completion contract for long-running Ralph work. Ralph state tracks workflow mechanics; goal mode tracks whether the user objective is truly done. When the goal tools are available:
+
+1. Call `get_goal` during intake or before the first execution loop when the prompt/hook says an active thread goal exists.
+2. If no goal exists, call `create_goal` only when the user or system explicitly asked for goal tracking; otherwise continue with Ralph state alone.
+3. Treat `goal.objective` as binding acceptance scope. Newer user updates can refine the current branch, but do not silently narrow the goal.
+4. Before completion, perform a prompt-to-artifact checklist and completion audit against real evidence:
+   - restate the objective as deliverables/success criteria
+   - map every prompt requirement, named workflow (`$ralplan`, `$ralph`), file, command, test, gate, and deliverable to evidence
+   - inspect the actual files, command output, state, and tests behind each checklist item
+   - identify missing, weakly verified, or uncovered requirements and continue if any remain
+5. Call `update_goal({status: "complete"})` only when the audit shows no required work remains. Do not use passing tests, Ralph state, or architect approval as proxy proof unless they cover the whole goal.
+6. If goal tools are unavailable, keep working through Ralph state and mention the missing goal-mode evidence in the final report.
+
 ## State Management
 
 Use the `omx_state` MCP server tools (`state_write`, `state_read`, `state_clear`) for Ralph lifecycle state.
@@ -177,6 +195,7 @@ Why bad: These are independent tasks that should run in parallel, not sequential
 - [ ] Fresh build output shows success
 - [ ] lsp_diagnostics shows 0 errors on affected files
 - [ ] Architect verification passed (STANDARD tier minimum)
+- [ ] Codex goal-mode completion audit passed, and `update_goal({status: "complete"})` was called when an active goal exists
 - [ ] ai-slop-cleaner pass completed on changed files (or --no-deslop specified)
 - [ ] Post-deslop regression tests pass
 - [ ] `/cancel` run for clean state cleanup

package/plugins/oh-my-codex/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/plugins/oh-my-codex/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/plugins/oh-my-codex/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/prompts/api-reviewer.md

@@ -5,7 +5,7 @@ argument-hint: "task description"
 <identity>
 You are API Reviewer. Your mission is to ensure public APIs are well-designed, stable, backward-compatible, and documented.
 You are responsible for API contract clarity, backward compatibility analysis, semantic versioning compliance, error contract design, API consistency, and documentation adequacy.
-You are not responsible for implementation optimization (performance-reviewer), style (style-reviewer), security (security-reviewer), or internal code quality (quality-reviewer).
+You are not responsible for implementation optimization (performance-reviewer), style (style-reviewer), security (code-reviewer), or internal code quality (quality-reviewer).
 
 Breaking API changes silently break every caller. These rules exist because a public API is a contract with consumers -- changing it without awareness causes cascading failures downstream.
 </identity>

package/prompts/code-reviewer.md

@@ -123,6 +123,8 @@ APPROVE / REQUEST CHANGES / COMMENT
 
 **Good:** The user says `make a PR` after review is done. Treat that as downstream context; keep the review verdict grounded in evidence.
 
+**Good:** The user says `merge if CI green` during review. Treat that as downstream context; do not merge from the reviewer lane, and keep the verdict scoped to review evidence.
+
 **Bad:** The user says `continue`, and you restate the first issue instead of completing the review.
 </scenario_handling>
 

package/prompts/performance-reviewer.md

@@ -5,7 +5,7 @@ argument-hint: "task description"
 <identity>
 You are Performance Reviewer. Your mission is to identify performance hotspots and recommend data-driven optimizations.
 You are responsible for algorithmic complexity analysis, hotspot identification, memory usage patterns, I/O latency analysis, caching opportunities, and concurrency review.
-You are not responsible for code style (style-reviewer), logic correctness (quality-reviewer), security (security-reviewer), or API design (api-reviewer).
+You are not responsible for code style (style-reviewer), logic correctness (quality-reviewer), security (code-reviewer), or API design (api-reviewer).
 
 Performance issues compound silently until they become production incidents. These rules exist because an O(n^2) algorithm works fine on 100 items but fails catastrophically on 10,000.
 </identity>

package/prompts/quality-reviewer.md

@@ -5,7 +5,7 @@ argument-hint: "task description"
 <identity>
 You are Quality Reviewer. Your mission is to catch logic defects, anti-patterns, and maintainability issues in code.
 You are responsible for logic correctness, error handling completeness, anti-pattern detection, SOLID principle compliance, complexity analysis, and code duplication identification.
-You are not responsible for style nitpicks (style-reviewer), security audits (security-reviewer), performance profiling (performance-reviewer), or API design (api-reviewer).
+You are not responsible for style nitpicks (style-reviewer), security audits (code-reviewer), performance profiling (performance-reviewer), or API design (api-reviewer).
 
 Logic defects cause production bugs. Anti-patterns cause maintenance nightmares. These rules exist because catching an off-by-one error or a God Object in review prevents hours of debugging later.
 </identity>

package/prompts/quality-strategist.md

@@ -38,7 +38,7 @@ Passing tests are necessary but insufficient for release quality. Without strate
 | Regression risk models | Interactive testing (qa-tester) |
 | Release readiness assessment | Evidence validation (verifier) |
 | Quality KPIs and trends | Code quality review (code-reviewer) |
-| Test depth recommendations | Security review (security-reviewer) |
+| Test depth recommendations | Security review (code-reviewer) |
 | Quality process governance | Performance review (performance-reviewer) |
 
 - Never recommend "test everything" — always prioritize by risk
@@ -177,7 +177,7 @@ Default final-output shape: outcome-first and evidence-dense; include the result
 | Test results / coverage | test-engineer | Assess current quality signal |
 | Interactive test findings | qa-tester | Assess behavioral quality |
 | Evidence artifacts | verifier | Validate claims |
-| Review findings | code-reviewer, security-reviewer | Assess code-level risks |
+| Review findings | code-reviewer, code-reviewer | Assess code-level risks |
 
 ## Artifact Types
 

package/prompts/style-reviewer.md

@@ -5,7 +5,7 @@ argument-hint: "task description"
 <identity>
 You are Style Reviewer. Your mission is to ensure code formatting, naming, and language idioms are consistent with project conventions.
 You are responsible for formatting consistency, naming convention enforcement, language idiom verification, lint rule compliance, and import organization.
-You are not responsible for logic correctness (quality-reviewer), security (security-reviewer), performance (performance-reviewer), or API design (api-reviewer).
+You are not responsible for logic correctness (quality-reviewer), security (code-reviewer), performance (performance-reviewer), or API design (api-reviewer).
 
 Inconsistent style makes code harder to read and review. These rules exist because style consistency reduces cognitive load for the entire team.
 </identity>

package/prompts/test-engineer.md

@@ -5,7 +5,7 @@ argument-hint: "task description"
 <identity>
 You are Test Engineer. Your mission is to design test strategies, write tests, harden flaky tests, and guide TDD workflows.
 You are responsible for test strategy design, unit/integration/e2e test authoring, flaky test diagnosis, coverage gap analysis, and TDD enforcement.
-You are not responsible for feature implementation (executor), code quality review (quality-reviewer), security testing (security-reviewer), or performance benchmarking (performance-reviewer).
+You are not responsible for feature implementation (executor), code quality review (quality-reviewer), security testing (code-reviewer), or performance benchmarking (performance-reviewer).
 
 Tests are executable documentation of expected behavior. These rules exist because untested code is a liability, flaky tests erode team trust in the test suite, and writing tests after implementation misses the design benefits of TDD. Good tests catch regressions before users do.
 </identity>

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

@@ -12,7 +12,7 @@ Reduce AI-generated slop with a regression-tests-first, smell-by-smell cleanup w
 Use this skill when:
 - A code path works but feels bloated, noisy, repetitive, or over-abstracted
 - A user asks to “cleanup”, “refactor”, or “deslop” AI-generated output
-- Follow-up implementation left duplicate code, dead code, weak boundaries, missing tests, or unnecessary wrapper layers
+- Follow-up implementation left duplicate code, dead code, weak boundaries, missing tests, fallback-like code, or unnecessary wrapper layers
 - You need a disciplined cleanup workflow without broad rewrites
 
 ## GPT-5.5 Guidance Alignment
@@ -34,22 +34,35 @@ Use this skill when:
    - Identify the behavior that must not change
    - Add or run targeted regression tests before editing cleanup candidates
    - If behavior is currently untested, create the narrowest test coverage needed first
+   - For fallback-like code, cover the primary path and any preserved compatibility/fail-safe fallback before cleanup
 
 2. **Create a cleanup plan before code**
    - List the specific smells to remove
    - Bound the pass to the requested files/scope
    - If a file list scope is provided, keep the pass restricted to that changed-files list
+   - Include fallback findings, classifications, and escalation status in the plan
    - Order fixes from safest/highest-signal to riskiest
    - Do not start coding until the cleanup plan is explicit
 
-3. **Categorize issues before editing**
+3. **Inventory fallback-like code before editing**
+   - Search the requested scope for fallback-like detection signals: 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
+   - Classify each finding before changing it:
+     - **Masking fallback slop** — hides errors or evidence, bypasses the primary contract, suppresses tests or validation, swallows failures, silently defaults, or adds untested alternate paths
+     - **Grounded compatibility/fail-safe fallback** — is scoped to an external/version/fail-safe boundary, documents the rationale, preserves failure evidence, and has regression tests for both the primary and fallback behavior
+   - Prefer root-cause repair, deletion, boundary repair, or explicit failure behavior before preserving fallback paths
+   - For broad, ambiguous, cross-layer, or architectural fallback-like code, invoke `$ralplan` for consensus resolution before edits
+   - Recursion guard: when already inside ralplan, ralph, team, or another OMX workflow, do not spawn a nested `$ralplan`; record the finding and attach it to the active ralplan, leader, or plan handoff instead
+
+4. **Categorize issues before editing**
+   - **Fallback-like code** — masking fallbacks, workaround branches, bypasses, swallowed errors, silent defaults, broad shims, alternate execution paths
    - **Duplication** — repeated logic, copy-paste branches, redundant helpers
    - **Dead code** — unused code, unreachable branches, stale flags, debug leftovers
    - **Needless abstraction** — pass-through wrappers, speculative indirection, single-use helper layers
    - **Boundary violations** — hidden coupling, leaky responsibilities, wrong-layer imports or side effects
    - **Missing tests** — behavior not locked, weak regression coverage, gaps around edge cases
 
-4. **Execute passes one smell at a time**
+5. **Execute passes one smell at a time**
+   - **Fallback-like code resolution gate** — remove masking fallback slop, repair root causes, or escalate ambiguous cases before continuing
    - **Pass 1: Dead code deletion**
    - **Pass 2: Duplicate removal**
    - **Pass 3: Naming/error handling cleanup**
@@ -57,7 +70,7 @@ Use this skill when:
    - Re-run targeted verification after each pass
    - Avoid bundling unrelated refactors into the same edit set
 
-5. **Run quality gates**
+6. **Run quality gates**
    - Regression tests stay green
    - Lint passes
    - Typecheck passes
@@ -66,9 +79,10 @@ Use this skill when:
    - Diff stays minimal and scoped
    - No new abstractions or dependencies unless explicitly required
 
-6. **Finish with an evidence-dense report**
+7. **Finish with an evidence-dense report**
    - Changed files
    - Simplifications made
+   - Fallback findings, classifications, and escalation status
    - Tests/diagnostics/build checks run
    - Remaining risks
    - Residual follow-ups or consciously deferred cleanup
@@ -82,8 +96,10 @@ AI SLOP CLEANUP REPORT
 Scope: [files or feature area]
 Behavior Lock: [targeted regression tests added/run]
 Cleanup Plan: [bounded smells and order]
+Fallback Findings: [none, or finding -> masking fallback slop / grounded compatibility/fail-safe fallback -> escalation status]
 
 Passes Completed:
+- Fallback-like code resolution gate - [root-cause repair, explicit failure behavior, preserved grounded fallback, or ralplan handoff]
 1. Pass 1: Dead code deletion - [concise fix]
 2. Pass 2: Duplicate removal - [concise fix]
 3. Pass 3: Naming/error handling cleanup - [concise fix]
@@ -99,6 +115,11 @@ Quality Gates:
 Changed Files:
 - [path] - [simplification]
 
+Fallback Review:
+- Findings: [fallback-like findings detected]
+- Classification: [masking fallback slop | grounded fallback]
+- Escalation Status: [none | raised to leader/ralplan | no escalation]
+
 Remaining Risks:
 - [none or short deferred item]
 ```
@@ -112,3 +133,7 @@ Remaining Risks:
 **Bad:** Start rewriting architecture before protecting behavior with tests.
 
 **Bad:** Collapse multiple smell categories into one large refactor with no intermediate verification.
+
+**Bad:** Keep a `fallback if it fails` branch that silently defaults after a swallowed error instead of fixing the root cause or making failure explicit.
+
+**Good:** A version-specific compatibility shim is narrow, documented, preserves error evidence, has primary and fallback regression tests, and is reported as a grounded compatibility/fail-safe fallback.

package/skills/ask/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: ask
+description: Ask a local external advisor CLI (Claude or Gemini) and capture a reusable artifact
+---
+
+# Ask (Local Advisor CLI)
+
+Use 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.
+
+## Usage
+
+```bash
+$ask claude <question or task>
+$ask gemini <question or task>
+omx ask claude "<question or task>"
+omx ask gemini "<question or task>"
+```
+
+## Backend selection
+
+- Use `claude` when the user asks for Claude, Anthropic, or the previous `$ask-claude` behavior.
+- Use `gemini` when the user asks for Gemini or the previous `$ask-gemini` behavior.
+- 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.
+
+## Local CLI commands
+
+Claude:
+
+```bash
+omx ask claude "{{ARGUMENTS}}"
+claude -p "{{ARGUMENTS}}"
+```
+
+Gemini:
+
+```bash
+omx ask gemini "{{ARGUMENTS}}"
+gemini -p "{{ARGUMENTS}}"
+```
+
+If 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.
+
+## Artifact requirement
+
+After local execution, save a markdown artifact to:
+
+```text
+.omx/artifacts/ask-<backend>-<slug>-<timestamp>.md
+```
+
+Minimum artifact sections:
+1. Original user task
+2. Backend and final prompt sent to the CLI
+3. Raw CLI output
+4. Concise summary
+5. Action items / next steps
+
+Task: {{ARGUMENTS}}

package/skills/ask-claude/SKILL.md

@@ -1,61 +1,10 @@
 ---
 name: ask-claude
-description: Ask Claude via local CLI and capture a reusable artifact
+description: Ask Claude deprecated skill
 ---
 
-# Ask Claude (Local CLI)
+# Ask Claude deprecated
 
-Use the locally installed Claude CLI as a direct external advisor for focused questions, reviews, or second opinions.
-
-## Usage
-
-```bash
-/ask-claude <question or task>
-```
-
-## Routing
-
-### Preferred: Local CLI execution
-Run Claude through the canonical OMX CLI command path (no MCP routing):
-
-```bash
-omx ask claude "{{ARGUMENTS}}"
-```
-
-Exact non-interactive Claude CLI command from `claude --help`:
-
-```bash
-claude -p "{{ARGUMENTS}}"
-# equivalent: claude --print "{{ARGUMENTS}}"
-```
-
-If needed, adapt to the user's installed Claude CLI variant while keeping local execution as the default path.
-
-Legacy compatibility entrypoints (`./scripts/ask-claude.sh`, `npm run ask:claude -- ...`) are transitional wrappers.
-
-### Missing binary behavior
-If `claude` is not found, do **not** switch to MCP.
-Instead:
-1. Explain that local Claude CLI is required for this skill.
-2. Ask the user to install/configure Claude CLI.
-3. Provide a quick verification command:
-
-```bash
-claude --version
-```
-
-## Artifact requirement
-After local execution, save a markdown artifact to:
-
-```text
-.omx/artifacts/claude-<slug>-<timestamp>.md
-```
-
-Minimum artifact sections:
-1. Original user task
-2. Final prompt sent to Claude CLI
-3. Claude output (raw)
-4. Concise summary
-5. Action items / next steps
+Hard-deprecated. Do not invoke or route this skill. Use `$ask claude <question>` or `omx ask claude "<question>"` directly for new advisor workflows.
 
 Task: {{ARGUMENTS}}

package/skills/ask-gemini/SKILL.md

@@ -1,61 +1,10 @@
 ---
 name: ask-gemini
-description: Ask Gemini via local CLI and capture a reusable artifact
+description: Ask Gemini deprecated skill
 ---
 
-# Ask Gemini (Local CLI)
+# Ask Gemini deprecated
 
-Use the locally installed Gemini CLI as a direct external advisor for brainstorming, design feedback, and second opinions.
-
-## Usage
-
-```bash
-/ask-gemini <question or task>
-```
-
-## Routing
-
-### Preferred: Local CLI execution
-Run Gemini through the canonical OMX CLI command path (no MCP routing):
-
-```bash
-omx ask gemini "{{ARGUMENTS}}"
-```
-
-Exact non-interactive Gemini CLI command from `gemini --help`:
-
-```bash
-gemini -p "{{ARGUMENTS}}"
-# equivalent: gemini --prompt "{{ARGUMENTS}}"
-```
-
-If needed, adapt to the user's installed Gemini CLI variant while keeping local execution as the default path.
-
-Legacy compatibility entrypoints (`./scripts/ask-gemini.sh`, `npm run ask:gemini -- ...`) are transitional wrappers.
-
-### Missing binary behavior
-If `gemini` is not found, do **not** switch to MCP.
-Instead:
-1. Explain that local Gemini CLI is required for this skill.
-2. Ask the user to install/configure Gemini CLI.
-3. Provide a quick verification command:
-
-```bash
-gemini --version
-```
-
-## Artifact requirement
-After local execution, save a markdown artifact to:
-
-```text
-.omx/artifacts/gemini-<slug>-<timestamp>.md
-```
-
-Minimum artifact sections:
-1. Original user task
-2. Final prompt sent to Gemini CLI
-3. Gemini output (raw)
-4. Concise summary
-5. Action items / next steps
+Hard-deprecated. Do not invoke or route this skill. Use `$ask gemini <question>` or `omx ask gemini "<question>"` directly for new advisor workflows.
 
 Task: {{ARGUMENTS}}

package/skills/autoresearch-goal/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: autoresearch-goal
+description: Durable professor-critic research workflow over Codex goal mode without reviving deprecated omx autoresearch
+---
+
+# Autoresearch Goal
+
+Use this workflow when a research mission should be bound to Codex goal-mode focus while OMX remains the durable state owner.
+
+## Boundary
+- Do **not** use or revive the deprecated `omx autoresearch` direct launch surface.
+- Do **not** claim shell commands mutate hidden Codex `/goal` state.
+- Do **not** edit upstream `../../codex` or add dependencies.
+- Use `get_goal`, `create_goal`, and `update_goal({status: "complete"})` only through the active Codex thread when those tools are available.
+
+## Artifacts
+`omx autoresearch-goal` writes:
+- `.omx/goals/autoresearch/<slug>/mission.json`
+- `.omx/goals/autoresearch/<slug>/rubric.md`
+- `.omx/goals/autoresearch/<slug>/ledger.jsonl`
+- `.omx/goals/autoresearch/<slug>/completion.json`
+
+## Flow
+1. Create the mission and professor-critic rubric:
+   `omx autoresearch-goal create --topic "..." --rubric "..." --critic-command "..."`
+2. Emit the model-facing handoff:
+   `omx autoresearch-goal handoff --slug <slug>`
+3. In the active Codex thread, call `get_goal`; call `create_goal` only if no active goal exists and the printed payload is the intended objective.
+4. Research iteratively against the rubric. Record every critic outcome:
+   `omx autoresearch-goal verdict --slug <slug> --verdict <pass|fail|blocked> --evidence "..."`
+5. Completion is blocked until professor-critic validation records `verdict=pass`. After the mission audit passes, call `update_goal({status: "complete"})`, call `get_goal` again, then run:
+   `omx autoresearch-goal complete --slug <slug> --codex-goal-json <get_goal-json-or-path>`
+6. Treat the completion command as read-only reconciliation plus durable OMX state update; hooks and shell commands must not mutate Codex goal state.
+
+## Completion gate
+A passing professor-critic artifact and a matching complete Codex `get_goal` snapshot are required. Assistant prose, partial tests, or a failed/blocked verdict are not sufficient.