oh-my-codex 0.20.3 → 0.21.0

package/skills/ultrawork/SKILL.md

@@ -1,190 +1,14 @@
 ---
 name: ultrawork
-description: Parallel execution engine for high-throughput task completion
+description: Sunset stub — use $team instead
 ---
 
-<Purpose>
-Ultrawork is a parallel execution engine for high-throughput task completion. It is a component, not a standalone persistence or verification mode: it provides parallelism, context discipline, and smart delegation guidance, but not durable goal tracking, Team's tmux worker lifecycle, Ralph's legacy persistence loop, architect sign-off, or long-running completion guarantees.
-</Purpose>
+# Ultrawork — removed
 
-<Use_When>
-- Multiple independent tasks can run simultaneously
-- User says "ulw", "ultrawork", or explicitly wants parallel execution
-- Task benefits from concurrent execution plus lightweight evidence before wrap-up
-- You need a direct-tool lane plus optional background evidence lanes without entering Team or a durable goal workflow
-</Use_When>
+`$ultrawork` was removed in OMX 0.21; use `$team` instead.
 
-<Do_Not_Use_When>
-- Task needs durable goal tracking, ledger checkpoints, or resume across stories -- use `ultragoal` instead
-- Task needs coordinated tmux workers, shared task state, mailbox/dispatch coordination, or long-running parallel execution -- use `team` instead
-- Task requires a full autonomous pipeline -- use `autopilot` instead (default loop: `deep-interview -> ralplan -> ultragoal`, with `team` only when needed)
-- Task intentionally requires the legacy persistent single-owner completion/verification loop -- use `ralph` explicitly; do not present it as the default durable path
-- There is only one sequential task with no parallelism opportunity -- execute directly, use `ultragoal` for durable tracking, or delegate to a single `executor`
-- The request is still in plan-consensus mode -- keep planning artifacts in `ralplan` until execution is explicitly authorized
-</Do_Not_Use_When>
+Parallel execution is team's job. `$team` owns worker panes, shared task state, mailbox/dispatch, and coordinated multi-worker lifecycle control. Ultrawork's prompt-only parallel engine added a second authority without a unique runtime.
 
-<Why_This_Exists>
-Sequential task execution wastes time when tasks are independent. Ultrawork keeps the execution branch fast while tightening the protocol: gather enough context first, define pass/fail acceptance criteria before editing, decide deliberately between local execution and delegation, and finish with evidence rather than vibes.
-</Why_This_Exists>
+Migration: replace `$ultrawork` with `$team`.
 
-<Execution_Policy>
-- Gather enough context before implementation. Start with the task intent, desired outcome, constraints, likely touchpoints, and any uncertainty that would change the execution path.
-- If uncertainty is still material after a quick repo read, do a focused evidence pass first instead of immediately editing.
-- Define pass/fail acceptance criteria before launching execution lanes. Include the command, artifact, or manual check that will prove success.
-- Prefer direct tool work when the task is small, coupled, or blocked on immediate local context. Delegate only when the work is independent enough to benefit from parallel execution.
-- When useful, run a direct-tool lane and one or more background evidence lanes at the same time. Evidence lanes can cover docs, tests, regression mapping, or bounded repo analysis.
-- Fire independent agent calls simultaneously -- never serialize independent work.
-- Always pass the `model` parameter explicitly when delegating.
-- Read `references/agent-tiers.md` before first delegation for agent selection guidance.
-- Auto-delegate `researcher` when official docs, version-aware framework guidance, best practices, or external dependency behavior materially affect task correctness; treat it as an evidence lane, not a replacement primary workflow.
-- Use `run_in_background: true` for operations over ~30 seconds (installs, builds, tests).
-- Run quick commands (git status, file reads, simple checks) in the foreground.
-- Apply the shared workflow guidance pattern: outcome-first framing, concise visible updates for speculative/blocked lanes, local overrides for the active workflow branch, evidence-backed validation, explicit stop rules, and continuation of clear safe execution branches instead of restarting or re-asking.
-- If the user says `continue`, continue the active workflow branch rather than restarting discovery or re-asking settled questions.
-</Execution_Policy>
-
-<Steps>
-1. **Read agent reference**: Load `references/agent-tiers.md` for tier selection.
-2. **Context + certainty check**:
-   - State the task intent in one sentence.
-   - List the constraints and unknowns that could invalidate a quick fix.
-   - If confidence is low, explore first and narrow the task before editing.
-3. **Define acceptance criteria before execution**:
-   - What must be true at the end?
-   - Which command or artifact proves it?
-   - Which manual QA check is required, if any?
-4. **Classify the work by dependency shape**:
-   - Independent tasks -> parallel lanes.
-   - Shared-file or prerequisite-heavy tasks -> local execution or staged lanes.
-5. **Choose self vs delegate deliberately**:
-   - Work locally when the next step depends on immediate repo context, shared files, or tight iteration.
-   - Delegate when the task slice is bounded, independent, and materially improves throughput.
-6. **Run execution lanes**:
-   - Direct-tool lane for immediate implementation or verification work.
-   - Background evidence lanes for tests, docs, repo analysis, or regression checks.
-7. **Run dependent tasks sequentially**: Wait for prerequisites before launching dependent work.
-8. **Close with lightweight evidence**:
-   - Build/typecheck passes when relevant.
-   - Affected tests pass.
-   - Manual QA notes are recorded when the task needs a human-visible or behavior-level check.
-   - No new errors introduced.
-</Steps>
-
-<Tool_Usage>
-- Use LOW-tier delegation for simple lookups and bounded evidence gathering.
-- Use STANDARD-tier delegation for standard implementation and regression work.
-- Use THOROUGH-tier delegation for complex analysis, architectural review, or risky multi-file changes.
-- Prefer a direct-tool lane when the immediate next step is blocked on local context.
-- Prefer background evidence lanes when you can learn something useful in parallel with implementation.
-- Use `run_in_background: true` for package installs, builds, and test suites.
-- Use foreground execution for quick status checks and file operations.
-</Tool_Usage>
-
-## State Management
-
-Use the CLI-first state surface (`omx state ... --json`) for ultrawork lifecycle state. If explicit MCP compatibility tools are already available, equivalent `omx_state` calls are optional compatibility, not the default.
-
-- **On start**:
-  `omx state write --input '{"mode":"ultrawork","active":true,"reinforcement_count":1,"started_at":"<now>"}' --json`
-- **On each reinforcement/loop step**:
-  `omx state write --input '{"mode":"ultrawork","reinforcement_count":<current>}' --json`
-- **On completion**:
-  `omx state write --input '{"mode":"ultrawork","active":false}' --json`
-- **On cancellation/cleanup**:
-  run `$cancel` (which should call `omx state clear --input '{"mode":"ultrawork"}' --json`)
-
-<Examples>
-<Good>
-Two-track execution with acceptance criteria up front:
-```
-Acceptance criteria:
-- `npm run build` passes
-- `node --test dist/scripts/__tests__/codex-native-hook.test.js` passes
-- Manual QA: verify `$ultrawork` activation message still points to the session state file
-
-Direct-tool lane:
-- update `skills/ultrawork/SKILL.md`
-
-Background evidence lane:
-- use /prompts:test-engineer for this scoped task
-```
-Why good: Context is grounded first, acceptance criteria are explicit, and the direct-tool lane runs alongside a bounded evidence lane.
-</Good>
-
-<Good>
-Correct use of self-vs-delegate judgment:
-```
-Shared-file edit in progress across `src/scripts/codex-native-hook.ts` and its test -> keep implementation local.
-Independent regression mapping for keyword-detector coverage -> delegate to a test-engineer lane.
-```
-Why good: Shared-file work stays local; independent evidence work fans out.
-</Good>
-
-<Bad>
-Parallelizing before the task is grounded:
-```
-use /prompts:executor for this scoped task
-use /prompts:test-engineer for this scoped task
-```
-Why bad: No context snapshot, no pass/fail target, and delegation starts before the work is shaped.
-</Bad>
-
-<Bad>
-Claiming success without evidence or manual QA:
-```
-Made the changes. Ultrawork should be updated now.
-```
-Why bad: No verification output, no acceptance evidence, and no manual QA note when the behavior is user-visible.
-</Bad>
-</Examples>
-
-<Escalation_And_Stop_Conditions>
-- When ultrawork is invoked directly, apply lightweight verification only -- build/typecheck passes when relevant, affected tests pass, and manual QA notes are captured when needed.
-- Ultrawork does not own persistence, durable ledgers, architect verification, deslop, full QA, or the full verified-completion promise. Do not claim those guarantees from direct ultrawork alone.
-- Escalate to `ultragoal` when the work needs durable goal state, story checkpoints, or resume across implementation steps.
-- Escalate to `team` when the work needs coordinated tmux workers, shared task state, or durable multi-worker lifecycle control.
-- Escalate to explicitly requested `ralph` only for the supported legacy single-owner persistence/verification fallback.
-- Ralph owns persistence, architect verification, deslop, and the full verified-completion promise only when explicitly selected as the supported legacy fallback; direct ultrawork does not own those guarantees.
-- If a task fails repeatedly across retries, report the issue rather than retrying indefinitely.
-- Escalate to the user when tasks have unclear dependencies, conflicting requirements, or a materially branching acceptance target.
-</Escalation_And_Stop_Conditions>
-
-<Final_Checklist>
-- [ ] Task intent and constraints were grounded before editing
-- [ ] Pass/fail acceptance criteria were stated before execution
-- [ ] Parallel lanes were used only for independent work
-- [ ] Build/typecheck passes when relevant
-- [ ] Affected tests pass
-- [ ] Manual QA notes recorded when behavior is user-visible
-- [ ] No new errors introduced
-- [ ] Completion claim stays inside ultrawork's lightweight-verification boundary
-</Final_Checklist>
-
-<Advanced>
-## Relationship to Other Modes
-
-```
-ultrawork (this skill)
- \-- provides: in-session parallel execution discipline + lightweight evidence
-
-ultragoal (durable goal execution)
- \-- owns: goal ledger, checkpoints, resume across stories, final gate discipline
- \-- may use: team for parallel lanes when a story benefits from coordinated workers
-
-team (tmux coordinated execution)
- \-- owns: worker panes, shared task state, mailbox/dispatch, lifecycle control
- \-- can return: checkpoint-ready evidence to an Ultragoal leader
-
-autopilot (strict autonomous delivery loop)
- \-- default flow: deep-interview -> ralplan -> ultragoal -> code-review -> ultraqa
- \-- may use: team only when an Ultragoal story needs parallel execution
-
-ralph (supported legacy explicit fallback)
- \-- owns: single-owner persistence loop + architect verification when intentionally selected
-
-ecomode (deprecated compatibility-only)
- \-- do not route users there from ultrawork; it is not the current model-selection path
-```
-
-Ultrawork is the parallelism and execution-discipline layer. Ultragoal is the current default durable goal/ledger follow-up. Team is the coordinated tmux parallel runtime, often nested under an Ultragoal story when durable work needs multiple lanes. Autopilot orchestrates the full default lifecycle through deep-interview, ralplan, ultragoal, code-review, and ultraqa. Ralph remains active as an explicit legacy fallback for persistent single-owner verification, but it is not the recommended default durable path. Ecomode is deprecated compatibility-only and should not be advertised as the ultrawork model-selection route.
-</Advanced>
+Task: {{ARGUMENTS}}

package/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/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.