oh-my-codex 0.15.2 → 0.16.0

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