worker
Team worker protocol (ACK, mailbox, task lifecycle) for tmux-based OMX teams
Best use case
worker is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Team worker protocol (ACK, mailbox, task lifecycle) for tmux-based OMX teams
Teams using worker should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/worker/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How worker Compares
| Feature / Agent | worker | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Team worker protocol (ACK, mailbox, task lifecycle) for tmux-based OMX teams
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
Related Guides
Cursor vs Codex for AI Workflows
Compare Cursor and Codex for AI coding workflows, repository assistance, debugging, refactoring, and reusable developer skills.
AI Agents for Coding
Browse AI agent skills for coding, debugging, testing, refactoring, code review, and developer workflows across Claude, Cursor, and Codex.
Best AI Skills for Claude
Explore the best AI skills for Claude and Claude Code across coding, research, workflow automation, documentation, and agent operations.
SKILL.md Source
# 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.
## Shutdown
If the lead sends a shutdown request, follow the shutdown inbox instructions exactly, write your shutdown ack file, then exit the Codex session.Related Skills
web-clone
URL-driven website cloning with visual + functional verification
visual-verdict
Structured visual QA verdict for screenshot-to-reference comparisons
ultrawork
Parallel execution engine for high-throughput task completion
ultraqa
QA cycling workflow - test, verify, fix, repeat until goal met
trace
Show agent flow trace timeline and summary
team
N coordinated agents on shared task list using tmux-based orchestration
tdd
Test-Driven Development enforcement skill - write tests first, always
swarm
N coordinated agents on shared task list (compatibility facade over team)
skill
Manage local skills - list, add, remove, search, edit, setup wizard
ralplan
Alias for $plan --consensus
ralph
Self-referential loop until task completion with architect verification
ralph-init
Initialize a PRD (Product Requirements Document) for structured ralph-loop execution