oh-my-customcodex 0.4.1 → 0.4.3

package/README.md

@@ -13,7 +13,7 @@
 
 **[한국어 문서 (Korean)](./README_ko.md)**
 
-49 agents. 114 skills. 22 rules. One command.
+49 agents. 116 skills. 22 rules. One command.
 
 ```bash
 npm install -g oh-my-customcodex && cd your-project && omcustomcodex init
@@ -134,7 +134,7 @@ Each agent declares its tools, model, memory scope, and limitations in YAML fron
 
 ---
 
-### Skills (114)
+### Skills (116)
 
 | Category | Count | Includes |
 |----------|-------|----------|
@@ -147,7 +147,7 @@ Each agent declares its tools, model, memory scope, and limitations in YAML fron
 | Package | 3 | npm-publish, npm-version, npm-audit |
 | Optimization | 3 | optimize-analyze, optimize-bundle, optimize-report |
 | Security | 3 | adversarial-review, cve-triage, jinja2-prompts |
-| Other | 10 | codex-exec, claude-native, vercel-deploy, skills-sh-search, result-aggregation, writing-clearly-and-concisely, and more |
+| Other | 12 | codex-exec, claude-native, visual-ralph, visual-verdict, vercel-deploy, skills-sh-search, result-aggregation, writing-clearly-and-concisely, and more |
 
 Skills use a 3-tier scope system: `core` (universal), `harness` (agent/skill maintenance), `package` (project-specific).
 
@@ -286,7 +286,7 @@ your-project/
 │   ├── contexts/               # 4 shared context files
 │   └── ontology/               # Knowledge graph for RAG
 ├── .agents/
-│   └── skills/                 # 114 installed skill modules
+│   └── skills/                 # 116 installed skill modules
 └── guides/                     # 40 reference documents
 ```
 

package/dist/cli/index.js

@@ -3091,7 +3091,7 @@ var init_package = __esm(() => {
     workspaces: [
       "packages/*"
     ],
-    version: "0.4.1",
+    version: "0.4.3",
     description: "Batteries-included agent harness on top of GPT Codex + OMX",
     type: "module",
     bin: {
@@ -28619,16 +28619,29 @@ import { join as join8 } from "node:path";
 var PROJECT_CONFIG_DIR = ".codex";
 var PROJECT_CONFIG_FILE = "config.toml";
 var ONTOLOGY_SERVER_TABLE = "[mcp_servers.ontology-rag]";
+var ONTOLOGY_SERVER_COMMAND = "uv";
+var ONTOLOGY_SERVER_ARGS = [
+  "run",
+  "--no-project",
+  "--python",
+  ".venv",
+  "python",
+  "-m",
+  "ontology_rag.mcp_server"
+];
 function getProjectMCPConfigPath(targetDir) {
   return join8(targetDir, PROJECT_CONFIG_DIR, PROJECT_CONFIG_FILE);
 }
+function renderTomlString(value) {
+  return `"${value.replaceAll("\\", "\\\\").replaceAll('"', "\\\"")}"`;
+}
 function renderOntologyMCPBlock(ontologyDir) {
   return `${ONTOLOGY_SERVER_TABLE}
-command = ".venv/bin/python"
-args = ["-m", "ontology_rag.mcp_server"]
+command = ${renderTomlString(ONTOLOGY_SERVER_COMMAND)}
+args = [${ONTOLOGY_SERVER_ARGS.map(renderTomlString).join(", ")}]
 
 [mcp_servers.ontology-rag.env]
-ONTOLOGY_DIR = "${ontologyDir}"
+ONTOLOGY_DIR = ${renderTomlString(ontologyDir)}
 `;
 }
 function hasOntologyMCPConfig(content) {

package/dist/index.js

@@ -2180,7 +2180,7 @@ var package_default = {
   workspaces: [
     "packages/*"
   ],
-  version: "0.4.1",
+  version: "0.4.3",
   description: "Batteries-included agent harness on top of GPT Codex + OMX",
   type: "module",
   bin: {

package/package.json

@@ -3,7 +3,7 @@
   "workspaces": [
     "packages/*"
   ],
-  "version": "0.4.1",
+  "version": "0.4.3",
   "description": "Batteries-included agent harness on top of GPT Codex + OMX",
   "type": "module",
   "bin": {

package/templates/.claude/skills/visual-ralph/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: visual-ralph
+description: Visual Ralph orchestration for frontend UI using approved references, Ralph implementation, Visual Verdict scoring, and reproducible design-system evidence
+---
+
+# Visual Ralph Skill
+
+Use this skill when the user wants a frontend UI implemented or restyled through
+a measured visual loop rather than subjective design feedback.
+
+## Purpose
+
+Create a frontend delivery loop:
+
+`user description or live URL -> approved visual reference -> $ralph implementation -> $visual-verdict + optional pixel diff -> reusable design system`.
+
+For live URL cloning or recreation requests, Visual Ralph owns the flow. Preserve
+the URL, viewport, content state, and interaction notes in the handoff instead of
+routing new work to a standalone web-clone path.
+
+## Use When
+
+- The user describes a web/app UI and wants implementation.
+- The user provides a live URL and wants a measured visual implementation.
+- A generated raster mockup or static reference image would clarify the target.
+- The task needs screenshot-based pass/fail iteration.
+- The final result should leave reusable tokens/components, not only a one-off visual match.
+
+## Do Not Use When
+
+- The user only wants design critique or frontend advice.
+- The task is non-visual backend/API work.
+- The user supplied a final static reference and only needs a comparison/fix loop; hand directly to `$ralph` with `$visual-verdict`.
+- The requested output is a deterministic SVG/vector/code-native asset.
+
+## Workflow
+
+### 1. Ground The Target Repo
+
+Inspect local evidence before choosing stack-specific tactics:
+- package manager and scripts,
+- frontend framework and routing,
+- styling system and design-token conventions,
+- screenshot/test tooling,
+- existing components that should be reused.
+
+Do not assume React, Vue, Tailwind, Playwright, or another stack without repo evidence.
+
+### 2. Establish The Visual Reference
+
+For live URL work, record:
+- source URL and scope note,
+- viewport(s), route/state, and seed/login assumptions,
+- baseline screenshot path or capture command,
+- interaction parity notes,
+- known exclusions such as backend/auth/personalized data/third-party widget parity.
+
+For generated UI concepts, use `$imagegen` to produce the reference. Prompt for a
+`ui-mockup` with viewport/aspect ratio, intended surface, hierarchy, typography,
+color direction, exact text, and a ban on unrequested logos/watermarks.
+
+For project-bound implementation, save the approved reference in the workspace,
+for example `.omx/artifacts/visual-ralph/<slug>/reference.png`.
+
+### 3. Require User Approval
+
+Stop after reference generation or URL-derived reference capture and ask the user
+to approve one reference image/state or request targeted changes. Do not start
+frontend implementation before approval.
+
+### 4. Hand Off To Ralph
+
+Invoke `$ralph` with:
+- approved reference image path or URL-derived artifact,
+- source URL and scope note when relevant,
+- viewport/content state,
+- detected repo/frontend context,
+- exact screenshot command and output path,
+- the completion checklist below.
+
+### 5. Use Visual Verdict Before Every Next Edit
+
+For each visual iteration:
+1. Capture the current screenshot with recorded viewport/state.
+2. Run `$visual-verdict` against the approved reference.
+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.
+
+Pixel diff is secondary evidence only. It helps translate mismatch hotspots into
+concrete edits, but it does not replace `$visual-verdict`.
+
+### 6. Leave A Reproducible Design System
+
+Encode the match in repo-native reusable artifacts: CSS variables, theme tokens,
+Tailwind config, component variants, stories, docs, or the existing equivalent.
+Capture applicable colors, spacing, typography, radii, shadows, and key states.
+
+## Completion Checklist
+
+- Approved reference or URL-derived artifact is saved in the workspace.
+- Screenshot reproduction command, viewport, route/state, and output paths are documented.
+- Final `$visual-verdict` score is `>= 90`.
+- Pixel diff or overlay evidence is recorded when useful.
+- Design tokens/components are repo-native and reusable.
+- Build/lint/test or the repo equivalent passes.
+- Remaining visual differences are documented with rationale.
+
+## Handoff Template
+
+```text
+$ralph "Implement the approved frontend reference.
+Reference: <workspace-reference-image-or-url-derived-artifact>
+Source URL: <url and permission/scope note, if relevant>
+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 pixel diff only as secondary debug evidence.
+Extract reusable design tokens/components.
+Run build/lint/test before completion.
+Do not make major design pivots unless explicitly requested."
+```
+
+Task: {{ARGUMENTS}}

package/templates/.claude/skills/visual-verdict/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: visual-verdict
+description: Structured visual QA verdict for screenshot-to-reference comparisons
+---
+
+# Visual Verdict Skill
+
+Use this skill when a UI task needs a strict visual comparison between one or
+more reference images and the current generated screenshot.
+
+## Inputs
+
+- `reference_images[]`: one or more reference image paths
+- `generated_screenshot`: current output screenshot path
+- `category_hint`: optional UI category, such as `dashboard`, `landing-page`, or `editor`
+
+## Output Contract
+
+Return JSON only:
+
+```json
+{
+  "score": 0,
+  "verdict": "revise",
+  "category_match": false,
+  "differences": ["..."],
+  "suggestions": ["..."],
+  "reasoning": "short explanation"
+}
+```
+
+Rules:
+- `score` is an integer from 0 to 100.
+- `verdict` is `pass`, `revise`, or `fail`.
+- `category_match` is true only when the screenshot matches the intended UI category.
+- `differences[]` lists concrete visual mismatches.
+- `suggestions[]` lists concrete next edits tied to the mismatches.
+- `reasoning` is one or two short sentences.
+
+## Threshold And Loop
+
+- Target pass threshold is `score >= 90`.
+- If `score < 90`, continue editing and rerun `$visual-verdict` before the next edit.
+- Persist useful verdict evidence in `.omx/state/{scope}/ralph-progress.json` when Ralph is active.
+
+## Debug Visualization
+
+Pixel diff or pixelmatch overlays are secondary debugging aids. They help locate
+hotspots, but `$visual-verdict` remains the authoritative pass/fail signal.

package/templates/manifest.json

@@ -1,6 +1,6 @@
 {
-  "version": "0.4.1",
-  "lastUpdated": "2026-04-27T01:00:00.000Z",
+  "version": "0.4.3",
+  "lastUpdated": "2026-04-27T02:00:00.000Z",
   "components": [
     {
       "name": "rules",
@@ -18,7 +18,7 @@
       "name": "skills",
       "path": ".agents/skills",
       "description": "Reusable skill modules (project-scoped repo skills)",
-      "files": 114
+      "files": 116
     },
     {
       "name": "guides",

package/templates/workflows/auto-dev.yaml

@@ -1,5 +1,5 @@
 # /pipeline auto-dev — Full-auto release pipeline
-# Pre-triages open issues → triage verify-done → plan → implement → verify → PR/release → publish → followup
+# Pre-triages open issues and release monitors → triage verify-done → plan → implement → verify → PR/release → publish → followup
 
 name: auto-dev
 description: "Full-auto release pipeline: pre-triage → triage → plan → implement → verify → PR → publish → followup"
@@ -11,11 +11,11 @@ steps:
     parallel:
       - name: pre-triage
         skill: professor-triage
-        description: Run professor-triage on open issues that lack verify-done label
-        condition: "open issues without label:verify-done exist"
+        description: Run professor-triage on open issues that lack verify-done label, including release-monitor labels codex-release and oh-my-codex-release
+        condition: "open issues without label:verify-done exist OR open release-monitor issues with label:codex-release or label:oh-my-codex-release exist"
       - name: triage
         skill: professor-triage
-        description: Analyze verify-done issues against current codebase and perform automated triage
+        description: Analyze verify-done and release-monitor issues against current codebase and perform automated triage
 
   - name: plan
     depends_on: issue-analysis