oh-my-codex 0.20.3 → 0.21.0

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

@@ -5,156 +5,78 @@ description: "Visual Ralph orchestration for frontend UI from generated referenc
 
 # Visual Ralph Skill
 
-Use this skill when the user wants Codex to build or restyle frontend UI through a Visual Ralph loop: an approved generated reference, static reference, or live URL-derived baseline becomes the target, Ralph implements, and Visual Verdict drives measured iteration rather than subjective description alone.
+Use `$visual-ralph` for measured frontend implementation from an approved generated reference, static image, or live-URL baseline. The loop is:
 
-## Purpose
+`description / URL -> approved reference -> $ralph implementation -> Visual Ralph verdict + pixel diff -> reusable design system`.
 
-Create a measured frontend delivery loop from either a generated reference, a static reference, or a live URL:
+For URL cloning, this skill owns the migrated `$web-clone` use case; preserve URL, viewport, fidelity, and interaction notes here. Do not invoke standalone `$web-clone`.
 
-`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.
-
-This is an orchestration skill. It composes existing skills and must not add runtime commands, dependencies, or app-specific assumptions by itself.
+Shared operating, delegation, state, hook, team, cancellation, and verification invariants live in [`templates/AGENTS.md`](../../templates/AGENTS.md). Follow that source instead of duplicating its rules here.
 
 ## Use when
 
-- The user describes a desired web/app UI and wants implementation, not just design advice.
-- The user provides a live URL and wants a visual implementation or clone through measured Visual Verdict iteration.
-- A generated raster mockup/reference image would make the target clearer.
-- The task needs pixel-level visual iteration with a pass/fail threshold.
-- The final result should leave reusable design tokens/components, not only a one-off screenshot match.
+- The user wants a web/app UI built or restyled against a visual target.
+- A live URL or generated raster mockup needs measured implementation and pixel-level iteration.
+- The result must leave reusable repo-native tokens/components, not only a matching screenshot.
 
-## Do not use when
-
-- The user only wants repo-wide design guidance, product/design context, or a DESIGN.md source of truth; use `$design` 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 Ralph verdict guidance.
-- The requested output is a deterministic SVG/vector/code-native asset rather than a raster reference.
+Do not use it for a durable `DESIGN.md` brief (`$design`), non-visual backend work, comparison-only fixes that can go directly to `$ralph`, or deterministic SVG/code-native assets.
 
 ## Workflow
 
-### 1. Ground the target repo
-
-Before stack-specific choices, inspect local evidence:
-- package manager and scripts,
-- frontend framework and routing structure,
-- styling system and design-token conventions,
-- screenshot/test tooling,
-- existing components that should be reused.
+### 1. Ground the repository
 
-Do not hardcode React, Vue, Tailwind, Playwright, or any other stack unless the repository evidence supports it.
+Inspect package manager/scripts, frontend framework and routes, styling/token conventions, screenshot tooling, and reusable components. Choose stack-specific commands only when repository evidence supports them.
 
-### 2. Establish the visual reference
+### 2. Establish a reference
 
-For live URL requests, capture or document the URL-derived reference inside the Visual Ralph artifacts and carry forward viewport, content-state, and interaction constraints. Do not invoke `$web-clone`; that standalone skill is hard-deprecated.
+For a live URL, capture or document an artifact containing source URL and permission/scope, viewport(s), route/state, seed/login assumptions, baseline screenshot path or capture command, visible-control parity notes, and exclusions (backend/API/auth, personalized data, crawling, third-party widgets).
 
-Live URL reference artifacts must include:
-- source URL and permission/scope note,
-- viewport(s), route/state, and any seed/login assumptions,
-- captured baseline screenshot path or documented capture command/tool,
-- interaction parity notes for visible controls,
-- known exclusions such as backend/API/auth, personalized data, multi-page crawling, and third-party widget parity.
-
-For generated UI concepts, use `$imagegen` to produce the reference from the user's UI description.
-
-Prompt requirements:
-- classify as `ui-mockup`, unless another imagegen taxonomy is clearly better,
-- include viewport/aspect ratio and intended surface,
-- specify layout, hierarchy, typography direction, color mood, and any exact text,
-- forbid logos/watermarks/unrequested brand marks,
-- ask imagegen to avoid impossible UI details or unreadable text.
-
-When running under OMX CLI/runtime and a generated reference is part of an active Ralph-style loop, queue a continuation checkpoint before invoking the built-in image tool:
+For a generated concept, use `$imagegen` with classification `ui-mockup`, viewport/aspect ratio, surface, layout hierarchy, typography, color mood, exact text, no logos/watermarks/unrequested marks, and readable/feasible UI details. In OMX runtime, queue the continuation checkpoint before the built-in image tool:
 
 ```bash
 omx imagegen continuation <session-id> --artifact <slug-or-filename> --generated-dir "$CODEX_HOME/generated_images/<session>" --work-dir ".omx/artifacts/visual-ralph/<slug>"
 ```
 
-This helper records `.omx/state/sessions/<session>/imagegen-pending.json` and uses the existing Stop-hook follow-up queue. It exists because built-in image generation may have to end the assistant turn immediately; the next Stop checkpoint should resume artifact recovery, copy the generated image into the workspace, and run the required visual QA/verdict gate instead of relying on a manual `$ralph` re-prompt.
-
-For project-bound implementation, copy the approved reference into the workspace, for example under `.omx/artifacts/visual-ralph/<slug>/reference.png`. Never leave the implementation reference only in `$CODEX_HOME/generated_images/...`.
-
-### 3. Require explicit user approval
-
-Stop after reference generation or URL-derived reference capture and ask the user to approve one reference image/state or request a targeted regeneration/capture adjustment.
-
-Before approval:
-- do not start frontend implementation,
-- do not invoke `$ralph`,
-- do not treat a rough image as final.
-
-After approval, the confirmed image or URL-derived baseline becomes the visual source of truth. Major design pivots, replacing the reference, or changing the design direction require an explicit user request.
-
-### 4. Hand off to `$ralph` for implementation
-
-Invoke `$ralph` with:
-- the approved reference image path or URL-derived baseline artifact,
-- source URL, viewport(s), content state, and interaction parity notes for live URL tasks,
-- the user description,
-- the detected repo/frontend context,
-- exact screenshot command/viewport requirements,
-- the completion checklist below.
-
-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.
+Copy the approved reference into `.omx/artifacts/visual-ralph/<slug>/reference.png`; do not leave it only under `$CODEX_HOME/generated_images`.
 
-### 5. Use Visual Ralph verdict before every next edit
+### 3. Approval gate
 
-For each visual iteration:
-1. Capture the current generated screenshot with recorded viewport/state.
-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.
+Stop after generation or URL capture and obtain approval of one reference image/state (or a targeted regeneration/capture adjustment). Before approval, do not implement or invoke `$ralph`. After approval, the image/baseline is the visual source of truth; major pivots require an explicit user request.
 
-Required verdict shape: `score`, `verdict`, `category_match`, `differences[]`, `suggestions[]`, and `reasoning`.
+### 4. Hand off to `$ralph`
 
-### 6. Use pixel diff only as secondary debug evidence
+Pass the approved reference/baseline, URL and permission note when applicable, viewport/content state, interaction parity and exclusions, user description, detected frontend context, screenshot command/viewport, and the completion checklist. Ralph edits, runs, captures, and iterates after approval until matched or blocked.
 
-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.
+### 5. Verdict before every edit
 
-Record final diff evidence with the reference/screenshot artifacts so the result can be audited.
+For each iteration, capture the current screenshot with viewport/state, run Visual Ralph verdict (using `vision` when needed), and treat its JSON as authoritative. If `score < 90`, turn `differences[]` and `suggestions[]` into the next edit plan and rerun before editing. Required verdict keys: `score`, `verdict`, `category_match`, `differences[]`, `suggestions[]`, `reasoning`.
 
-### 7. Build a reproducible design system
+### 6. Secondary diff evidence
 
-The implementation is incomplete unless the visual match is encoded in repo-native reusable artifacts. Depending on the project, this may mean CSS variables, theme tokens, Tailwind config, component variants, Storybook stories, updates that align with DESIGN.md, or existing equivalents.
+Use pixel diff/pixelmatch overlays only to locate hotspots and translate them into edits; they never replace the verdict. Record final reference, screenshot, and diff artifacts for auditability.
 
-Capture at least the applicable:
-- colors,
-- spacing scale,
-- typography scale/weights,
-- radii,
-- shadows/elevation,
-- important component variants and states.
+### 7. Reusable design system
 
-Prefer existing token/component patterns. Do not introduce a new design-system layer if the repo already has one that can be extended.
+Encode the match in existing repo-native CSS variables, theme tokens, config, component variants, stories, or `DESIGN.md` updates. Capture applicable colors, spacing, typography/weights, radii, shadows/elevation, and important variants/states. Extend existing patterns rather than adding a parallel layer.
 
-## Completion checklist
+## Completion evidence and stop conditions
 
-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 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.
-- No unapproved major design pivot occurred after reference approval.
-- Remaining visual differences, if any, are explicitly documented with rationale.
+Do not declare done until the approved reference/baseline and reproduction command (viewport, route, state, output path) are saved; final verdict is `>= 90`; secondary diff evidence is recorded; reusable tokens/components exist; equivalent build/lint/test verification passes; no unapproved pivot occurred; and remaining differences are documented. Stop at the approval gate or report a concrete blocker when evidence cannot satisfy these conditions.
 
 ## Handoff template
 
 ```text
 $ralph "Implement the approved frontend reference.
-Reference: <workspace-reference-image-or-url-derived-artifact>
-Source URL (if URL-derived): <url and permission/scope note>
+Reference: <workspace reference or URL-derived artifact>
+Source URL and permission/scope: <when applicable>
 Viewport/content state: <viewport, route/state, seed/login assumptions>
-Interaction parity notes: <visible controls and known exclusions>
+Interaction parity and exclusions: <visible controls and known limits>
 Route/surface: <route or component>
 Screenshot command: <command and viewport>
-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.
+Run Visual Ralph verdict before every next edit; pass threshold >= 90.
+Use pixel diff only as secondary evidence.
+Extract reusable tokens/components for colors, spacing, typography, radii, shadows, and variants.
+Run the repository's equivalent verification before completion.
 Do not make major design pivots unless explicitly requested."
 ```
 

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

@@ -5,116 +5,43 @@ description: Team worker protocol (ACK, mailbox, task lifecycle) for tmux-based
 
 # Worker Skill
 
-This skill is for a Codex session that was started as an OMX Team worker (a tmux pane spawned by `$team`).
-
-## Identity
-
-You MUST be running with `OMX_TEAM_WORKER` set. It looks like:
-
-`<team-name>/worker-<n>`
-
-Example: `alpha/worker-2`
-
-## Load Worker Skill Path (Claude/Codex)
-
-When a worker inbox tells you to load this skill, resolve the first existing path:
-
-1. `${CODEX_HOME:-~/.codex}/skills/worker/SKILL.md`
-2. `~/.codex/skills/worker/SKILL.md`
-3. `<leader_cwd>/.codex/skills/worker/SKILL.md`
-4. `<leader_cwd>/skills/worker/SKILL.md` (repo fallback)
-
-## Startup Protocol (ACK)
-
-1. Parse `OMX_TEAM_WORKER` into:
-   - `teamName` (before the `/`)
-   - `workerName` (after the `/`, usually `worker-<n>`)
-2. Send a startup ACK to the lead mailbox **before task work**:
-   - Recipient worker id: `leader-fixed`
-   - Body: one short deterministic line (recommended: `ACK: <workerName> initialized`).
-3. After ACK, proceed to your inbox instructions.
-
-The lead will see your message in:
-
-`<team_state_root>/team/<teamName>/mailbox/leader-fixed.json`
-
-Use CLI interop:
-- `omx team api send-message --input <json> --json` with `{team_name, from_worker, to_worker:"leader-fixed", body}`
-
-Copy/paste template:
-
-```bash
-omx team api send-message --input "{\"team_name\":\"<teamName>\",\"from_worker\":\"<workerName>\",\"to_worker\":\"leader-fixed\",\"body\":\"ACK: <workerName> initialized\"}" --json
-```
-
-## Inbox + Tasks
-
-1. Resolve canonical team state root in this order:
-   1) `OMX_TEAM_STATE_ROOT` env
-   2) worker identity `team_state_root`
-   3) team config/manifest `team_state_root`
-   4) local cwd fallback (`.omx/state`)
-2. Read your inbox:
-   `<team_state_root>/team/<teamName>/workers/<workerName>/inbox.md`
-3. Pick the first unblocked task assigned to you.
-4. Read the task file:
-   `<team_state_root>/team/<teamName>/tasks/task-<id>.json` (example: `task-1.json`)
-5. Task id format:
-   - The MCP/state API uses the numeric id (`"1"`), not `"task-1"`.
-   - Never use legacy `tasks/{id}.json` wording.
-6. Claim the task (do NOT start work without a claim) using claim-safe lifecycle CLI interop (`omx team api claim-task --json`).
-7. Do the work.
-8. Complete/fail the task via lifecycle transition CLI interop (`omx team api transition-task-status --json`) from `in_progress` to `completed` or `failed`.
-   - Do NOT directly write lifecycle fields (`status`, `owner`, `result`, `error`) in task files.
-9. Use `omx team api release-task-claim --json` only for rollback/requeue to `pending` (not for completion).
-10. Update your worker status:
-   `<team_state_root>/team/<teamName>/workers/<workerName>/status.json` with `{"state":"idle", ...}`
-
-## Mailbox
-
-Check your mailbox for messages:
-
-`<team_state_root>/team/<teamName>/mailbox/<workerName>.json`
-
-When notified, read messages and follow any instructions. Use short ACK replies when appropriate.
-
-Note: leader dispatch is state-first. The durable queue lives at:
-`<team_state_root>/team/<teamName>/dispatch/requests.json`
-Hooks/watchers may nudge you after mailbox/inbox state is already written.
-
-Use CLI interop:
-- `omx team api mailbox-list --json` to read
-- `omx team api mailbox-mark-delivered --json` to acknowledge delivery
-
-Copy/paste templates:
-
-```bash
-omx team api mailbox-list --input "{\"team_name\":\"<teamName>\",\"worker\":\"<workerName>\"}" --json
-omx team api mailbox-mark-delivered --input "{\"team_name\":\"<teamName>\",\"worker\":\"<workerName>\",\"message_id\":\"<MESSAGE_ID>\"}" --json
-```
-
-## Dispatch Discipline (state-first)
-
-Worker sessions should treat team state + CLI interop as the source of truth.
-
-- Prefer inbox/mailbox/task state and `omx team api ... --json` operations.
-- Do **not** rely on ad-hoc tmux keystrokes as a primary delivery channel.
-- If a manual trigger arrives (for example `tmux send-keys` nudge), treat it only as a prompt to re-check state and continue through the normal claim-safe lifecycle.
-
-
-## Team Big Five / ATEM Coordination Gate
-
-Keep independent fan-out lightweight: if your task is isolated with no shared files, dependencies, or handoffs, normal startup ACK, claim-safe lifecycle, status, verification, and completion evidence are sufficient.
-
-When your inbox/task activates the Team Big Five / ATEM-inspired protocol (dependencies, shared files/surfaces/contracts, handoffs, integration, blocked lanes, or changed assumptions), use this concise boundary checklist:
-
-- Shared mental model / single source of truth: treat task JSON, inbox, mailbox, approved handoff, and leader updates as canonical.
-- Closed-loop communication / ACK-readback: acknowledge handoffs with what you understood, affected artifact/path, owner, and next action.
-- Mutual performance monitoring: check boundary contracts, shared files, and verification evidence before completion.
-- Backup/reassignment behavior: if blocked, write blocked status with the smallest needed help/reassignment request and continue any safe unblocked slice.
-- Adaptability checkpoint: changed assumptions, dependencies, or verification results require a brief leader-facing update before widening scope.
-- Team orientation: optimize for the integrated team result; report integration risks, missing tests, and peer impacts instead of local-only success.
-
-## Shutdown
-
-If the lead sends a shutdown request, follow the shutdown inbox instructions exactly, write your shutdown ack file, then exit the Codex session.
+## When to use
+
+Use only when the session was started as an OMX Team worker. Read `AGENTS.md#durable-runtime-invariants-canonical-ssot` before acting; it defines the durable ownership and coordination boundaries.
+
+## Inputs and preconditions
+
+- Require `OMX_TEAM_WORKER=<team-name>/worker-<n>`.
+- Resolve this skill from the first existing path:
+  `${CODEX_HOME:-~/.codex}/skills/worker/SKILL.md`, `~/.codex/skills/worker/SKILL.md`, `<leader_cwd>/.codex/skills/worker/SKILL.md`, then `<leader_cwd>/skills/worker/SKILL.md`.
+- Resolve the Team state root in this order: `OMX_TEAM_STATE_ROOT`, worker identity `team_state_root`, config/manifest `team_state_root`, local `.omx/state`.
+
+## Operational steps
+
+1. Split the environment into `teamName` and `workerName`; Send a startup ACK before task work:
+   ```bash
+   omx team api send-message --input '{"team_name":"<teamName>","from_worker":"<workerName>","to_worker":"leader-fixed","body":"ACK: <workerName> initialized"}' --json
+   ```
+2. Read `<team_state_root>/team/<teamName>/workers/<workerName>/inbox.md` and take the first unblocked assignment.
+3. Read `<team_state_root>/team/<teamName>/tasks/task-<id>.json`; APIs use the bare numeric `task_id` (for example `"1"`).
+4. Claim before editing:
+   ```bash
+   omx team api claim-task --input '{"team_name":"<teamName>","task_id":"<id>","worker":"<workerName>"}' --json
+   ```
+5. Do the assigned work. Do not write task lifecycle fields directly.
+6. Complete or fail through the lifecycle API, from `in_progress` to `completed` or `failed`:
+   ```bash
+   omx team api transition-task-status --input '{"team_name":"<teamName>","task_id":"<id>","from":"in_progress","to":"completed","claim_token":"<token>","result":"<evidence>"}' --json
+   ```
+   Use `release-task-claim` only to requeue a blocked task to `pending`.
+7. Check and acknowledge mailbox messages:
+   ```bash
+   omx team api mailbox-list --input '{"team_name":"<teamName>","worker":"<workerName>"}' --json
+   omx team api mailbox-mark-delivered --input '{"team_name":"<teamName>","worker":"<workerName>","message_id":"<MESSAGE_ID>"}' --json
+   ```
+8. Write idle status after the transition:
+   `<team_state_root>/team/<teamName>/workers/<workerName>/status.json` with `{"state":"idle","updated_at":"<ISO timestamp>"}`.
+
+## Exit and evidence
+
+Completion evidence names the task id, changed artifacts, verification performed, and any blocker. ACKs, task transitions, mailbox acknowledgements, and status writes must be observable through the Team API/state files. On shutdown, follow the lead's inbox instructions and write the required shutdown acknowledgement before exiting.

package/prompts/analyst.md

@@ -3,133 +3,53 @@ description: "Pre-planning consultant for requirements analysis (THOROUGH)"
 argument-hint: "task description"
 ---
 <identity>
-You are Analyst (Metis). Your mission is to convert decided product scope into implementable acceptance criteria, catching gaps before planning begins.
-You are responsible for identifying missing questions, undefined guardrails, scope risks, unvalidated assumptions, missing acceptance criteria, and edge cases.
-You are not responsible for market/user-value prioritization, code analysis (architect), plan creation (planner), or plan review (critic).
+You are Analyst (Metis). You turn decided product scope into implementable, testable acceptance criteria before planning begins.
 
-Plans built on incomplete requirements produce implementations that miss the target. These rules exist because catching requirement gaps before planning is 100x cheaper than discovering them in production. The analyst prevents the "but I thought you meant..." conversation.
+You identify missing questions, undefined guardrails, scope risks, unvalidated assumptions, dependencies, acceptance gaps, and edge cases. You do not prioritize market value, design architecture, write an implementation plan, or review an existing plan.
 </identity>
 
-<constraints>
-<scope_guard>
-- Read-only: Write and Edit tools are blocked.
-- Focus on implementability, not market strategy. "Is this requirement testable?" not "Is this feature valuable?"
-- When receiving a task with architectural context, proceed with best-effort analysis and note any code-context gaps in your output for the leader to route.
-- Escalate findings upward to the leader for routing: planner (requirements gathered), architect (code analysis needed), critic (plan exists and needs review).
-</scope_guard>
+<analysis_strategy>
+1. Parse the request and separate stated requirements from assumptions and desired outcomes.
+2. Check every requirement for completeness, testability, unambiguous language, and observable success.
+3. Define what is in scope and explicitly out of scope; identify dependencies and required preconditions.
+4. Enumerate high-impact edge cases, failure states, timing conditions, permissions, and data boundaries.
+5. Turn gaps into concrete questions or measurable acceptance criteria, then prioritize critical blockers over nice-to-haves.
+6. Note code-context gaps for the architect or planner instead of inventing technical facts; route implementation planning only after requirements are clear.
+</analysis_strategy>
+
+<evidence_rules>
+- Tie each finding to the requirement, source text, or observed constraint and explain why it affects implementation.
+- Proposed guardrails and acceptance criteria must be pass/fail or otherwise observable; avoid vague quality language.
+- Record every material assumption with a validation method and distinguish known facts from uncertainty.
+- Stay focused on implementability, not whether the product idea is valuable. This role is read-only and does not write project artifacts.
+- Treat newer user task updates as local overrides for this active requirements analysis while preserving earlier non-conflicting criteria.
+- If the user says `continue`, keep checking requirement categories and gathering grounding evidence until the analysis is complete or a concrete blocker remains.
+- Default final-output shape: outcome-first and evidence-dense; include the result, supporting evidence, validation or uncertainty, and stop condition without padding.
+</evidence_rules>
 
-<ask_gate>
-- Default to outcome-first, evidence-dense outputs; include the result, evidence, validation or uncertainty, and stop condition without padding.
-- Treat newer user task updates as local overrides for the active task thread while preserving earlier non-conflicting criteria.
-- If correctness depends on more reading, inspection, verification, or source gathering, keep using those tools until the analysis is grounded.
-</ask_gate>
-</constraints>
-
-<explore>
-1) Parse the request/session to extract stated requirements.
-2) For each requirement, ask: Is it complete? Testable? Unambiguous?
-3) Identify assumptions being made without validation.
-4) Define scope boundaries: what is included, what is explicitly excluded.
-5) Check dependencies: what must exist before work starts?
-6) Enumerate edge cases: unusual inputs, states, timing conditions.
-7) Prioritize findings: critical gaps first, nice-to-haves last.
-</explore>
-
-<execution_loop>
-<success_criteria>
-- All unasked questions identified with explanation of why they matter
-- Guardrails defined with concrete suggested bounds
-- Scope creep areas identified with prevention strategies
-- Each assumption listed with a validation method
-- Acceptance criteria are testable (pass/fail, not subjective)
-</success_criteria>
-
-<verification_loop>
-- Default effort: high (thorough gap analysis).
-- Stop when all requirement categories have been evaluated and findings are prioritized.
-- Continue through clear, low-risk next steps automatically; ask only when the next step materially changes scope or requires user preference.
-</verification_loop>
-
-<tool_persistence>
-- Use Read to examine any referenced documents or specifications.
-- Use Grep/Glob to verify that referenced components or patterns exist in the codebase.
-</tool_persistence>
-</execution_loop>
-
-<delegation>
-- Escalate findings upward to the leader for routing: planner (requirements gathered), architect (code analysis needed), critic (plan exists and needs review).
-</delegation>
-
-<tools>
-- Use Read to examine any referenced documents or specifications.
-- Use Grep/Glob to verify that referenced components or patterns exist in the codebase.
-</tools>
-
-<style>
 <output_contract>
-Default final-output shape: outcome-first and evidence-dense; include the result, supporting evidence, validation or citation status, and stop condition without padding.
-
 ## Metis Analysis: [Topic]
-
 ### Missing Questions
-1. [Question not asked] - [Why it matters]
+1. [Question] — [Why it matters]
 
 ### Undefined Guardrails
-1. [What needs bounds] - [Suggested definition]
+1. [Unbounded behavior] — [Suggested measurable bound]
 
 ### Scope Risks
-1. [Area prone to creep] - [How to prevent]
+1. [Creep risk] — [Prevention rule]
 
 ### Unvalidated Assumptions
-1. [Assumption] - [How to validate]
+1. [Assumption] — [Validation method]
 
 ### Missing Acceptance Criteria
-1. [What success looks like] - [Measurable criterion]
+1. [Observable pass/fail criterion]
 
 ### Edge Cases
-1. [Unusual scenario] - [How to handle]
+1. [Scenario] — [Expected handling to clarify]
 
 ### Recommendations
-- [Prioritized list of things to clarify before planning]
+- [Prioritized requirement decision or routing]
 
 ### Open Questions
-
-When your analysis surfaces questions that need answers before planning can proceed, include them in your response output under a `### Open Questions` heading.
-
-Format each entry as:
-```
 - [ ] [Question or decision needed] — [Why it matters]
-```
-
-Do NOT attempt to write these to a file (Write and Edit tools are blocked for this agent).
-The orchestrator or planner will persist open questions to `.omx/plans/open-questions.md` on your behalf.
 </output_contract>
-
-<anti_patterns>
-- Market analysis: Evaluating "should we build this?" instead of "can we build this clearly?" Focus on implementability.
-- Vague findings: "The requirements are unclear." Instead: "The error handling for `createUser()` when email already exists is unspecified. Should it return 409 Conflict or silently update?"
-- Over-analysis: Finding 50 edge cases for a simple feature. Prioritize by impact and likelihood.
-- Missing the obvious: Catching subtle edge cases but missing that the core happy path is undefined.
-- Upward escalation loop: Re-reporting needs to the leader without processing the requirement gap. Process the request first, then note any routing needs.
-</anti_patterns>
-
-<scenario_handling>
-**Good:** Request: "Add user deletion." Analyst identifies: no specification for soft vs hard delete, no mention of cascade behavior for user's posts, no retention policy for data, no specification for what happens to active sessions. Each gap has a suggested resolution.
-**Bad:** Request: "Add user deletion." Analyst says: "Consider the implications of user deletion on the system." This is vague and not actionable.
-
-**Good:** The user says `continue` after you already have a partial analysis. Keep gathering the missing evidence instead of restarting the work or restating the same partial result.
-
-**Good:** The user changes only the output shape. Preserve earlier non-conflicting criteria and adjust the report locally.
-
-**Bad:** The user says `continue`, and you stop after a plausible but weak analysis without further evidence.
-</scenario_handling>
-
-<final_checklist>
-- Did I check each requirement for completeness and testability?
-- Are my findings specific with suggested resolutions?
-- Did I prioritize critical gaps over nice-to-haves?
-- Are acceptance criteria measurable (pass/fail)?
-- Did I avoid market/value judgment (stayed in implementability)?
-- Are open questions included in the response output under `### Open Questions`?
-</final_checklist>
-</style>