oh-my-codex 0.15.3 → 0.16.0

package/plugins/oh-my-codex/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.

package/plugins/oh-my-codex/skills/omx-setup/SKILL.md

@@ -60,7 +60,7 @@ Supported setup flags (current implementation):
   - `project`: local directories (`./.codex`, `./.codex/skills`, `./.omx/agents`)
 - User-scope skill delivery targets:
   - `legacy`: keep installing/updating OMX skills in the resolved user skill root
-  - `plugin`: rely on Codex plugin discovery for bundled skills and archive/remove legacy OMX-managed prompts/skills/native agents; setup still installs native Codex hooks and `codex_hooks = true` because plugins do not carry hooks.
+  - `plugin`: rely on Codex plugin discovery for bundled skills and archive/remove legacy OMX-managed prompts/skills/native agents; setup still installs native Codex hooks and setup-owned runtime feature flags (`codex_hooks = true`, `goals = true`) because plugins do not carry hooks or enable Codex goal mode by themselves.
 - Migration hint: in `user` scope, if historical `~/.agents/skills` still exists alongside `${CODEX_HOME:-~/.codex}/skills`, current setup prints a cleanup hint. **Why the paths differ**: `${CODEX_HOME:-~/.codex}/skills/` is the path current Codex CLI natively loads as its skill root; `~/.agents/skills/` was the skill root in an older Codex CLI release before `~/.codex` became the standard home directory. OMX writes only to the canonical `${CODEX_HOME:-~/.codex}/skills/` path. When both directories exist simultaneously, Codex discovers skills from both trees and may show duplicate entries in Enable/Disable Skills. Archive or remove `~/.agents/skills/` to resolve this.
 - If persisted scope is `project`, `omx` launch automatically uses `CODEX_HOME=./.codex` unless user explicitly overrides `CODEX_HOME`.
 - Plugin mode prompts separately for optional AGENTS.md defaults and optional `developer_instructions` defaults. If `developer_instructions` already exists, setup asks before overwriting it; non-interactive runs preserve it.
@@ -74,7 +74,7 @@ Use this map when reconciling setup behavior or debugging a confusing install:
 | Surface | Owner | Notes |
 | --- | --- | --- |
 | `./.omx/setup-scope.json` | `omx setup` | Persists setup scope and user-scope skill delivery mode. TTY reruns summarize it and offer keep/review/reset. |
-| `~/.codex/config.toml` / `./.codex/config.toml` | `omx setup` generated blocks + user edits | Setup refreshes OMX-managed blocks while preserving supported manual content. |
+| `~/.codex/config.toml` / `./.codex/config.toml` | `omx setup` generated blocks + user edits | Setup refreshes OMX-managed blocks while preserving supported manual content; setup-owned runtime feature flags include `multi_agent`, `child_agents_md`, `codex_hooks`, and `goals`. |
 | `~/.codex/hooks.json` / `./.codex/hooks.json` | `omx setup` shared ownership | Setup owns OMX native hook wrappers and preserves user-owned hooks. |
 | prompts, skills, native agents | `omx setup` or Codex plugin delivery | Legacy mode installs local files; plugin mode relies on plugin discovery for bundled skills and archives/removes legacy OMX-managed prompt/native-agent copies. |
 | `AGENTS.md` | `omx setup` with overwrite safety | Generated defaults or managed refreshes are guarded by force/session checks. |

package/plugins/oh-my-codex/skills/performance-goal/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: performance-goal
+description: "Run an evaluator-gated performance optimization workflow over Codex goal mode with durable OMX artifacts and safe goal handoffs."
+---
+
+# Performance Goal Workflow
+
+Use this skill when a user asks OMX to optimize performance and wants a goal-oriented loop rather than a one-off review.
+
+## Contract
+
+- OMX owns durable workflow state under `.omx/goals/performance/<slug>/`.
+- Codex goal mode owns only the active-thread focus/accounting primitive.
+- Shell commands do **not** mutate hidden Codex goal state. They write artifacts and emit model-facing handoff text.
+- No optimization work may start until an evaluator command and pass/fail contract exist.
+- Do not call `update_goal({status: "complete"})` until the evaluator has a passing checkpoint and a completion audit proves the objective is done; then call `get_goal` again and pass that fresh snapshot to `omx performance-goal complete --codex-goal-json`.
+
+## CLI
+
+Create the workflow and evaluator contract:
+
+```sh
+omx performance-goal create \
+  --objective "Reduce CLI startup latency by 20%" \
+  --evaluator-command "npm run perf:startup" \
+  --evaluator-contract "PASS when p95 latency improves by 20% and regression tests pass" \
+  --slug startup-latency
+```
+
+Emit the Codex goal handoff:
+
+```sh
+omx performance-goal start --slug startup-latency
+```
+
+Record evaluator evidence:
+
+```sh
+omx performance-goal checkpoint --slug startup-latency --status pass --evidence "benchmark + tests passed"
+omx performance-goal checkpoint --slug startup-latency --status fail --evidence "benchmark regressed"
+omx performance-goal checkpoint --slug startup-latency --status blocked --evidence "missing fixture"
+```
+
+Complete only after a passing checkpoint:
+
+```sh
+omx performance-goal complete --slug startup-latency --evidence "final evaluator evidence" --codex-goal-json <get_goal-json-or-path>
+```
+
+## Agent Loop
+
+1. Run `omx performance-goal create` if no workflow exists.
+2. Run `omx performance-goal start` and follow the handoff:
+   - call `get_goal`;
+   - call `create_goal` only when no active goal exists and the objective is explicit;
+   - work only against the evaluator contract;
+   - after evaluator pass and completion audit, call `update_goal({status: "complete"})`, call `get_goal` again, and pass that snapshot to `omx performance-goal complete --codex-goal-json`;
+3. Optimize in small reversible patches.
+4. Run the evaluator and related regression tests.
+5. Record each pass/fail/blocker with `checkpoint`.
+6. Complete only when the pass artifact exists and no required work remains.
+
+## Completion Gate
+
+A performance goal is incomplete unless `.omx/goals/performance/<slug>/state.json` contains a `lastValidation.status` of `pass` and `omx performance-goal complete` receives a matching complete Codex `get_goal` snapshot via `--codex-goal-json`. Passing ordinary tests alone is not sufficient unless they are the declared evaluator contract.

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

@@ -114,7 +114,7 @@ Jumping into code without understanding requirements leads to rework, scope cree
 2. Evaluate via Critic using `ask_codex` with `agent_role: "critic"`
 3. For cleanup/refactor/anti-slop work, verify that the artifact includes a cleanup plan, regression tests or an explicit test gap, smell-by-smell passes, and quality gates.
 4. Return verdict: APPROVED, REVISE (with specific feedback), or REJECT (replanning required)
-5. If the current context authored the artifact, hand the review to `/review`, `critic`, `quality-reviewer`, `security-reviewer`, or `verifier` as appropriate.
+5. If the current context authored the artifact, hand the review to `$code-review`, `critic`, `quality-reviewer`, or `verifier` as appropriate.
 
 ### Plan Output Format
 

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/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}}