agentleFS
lza6lza6/claw-code-tingfeng/skills/worker/SKILL.md

worker

Skill5 starsChanged 12 days agoMITView on GitHub

Team worker protocol (ACK, mailbox, task lifecycle) for tmux-based OMX teams

10 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. 0 are common, 6 are distinctive, and 7 are very specific to this project.

  • 0

    Common

    Most of the 9 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When a worker inbox tells you to load this skill, resolve the first existing path:

    line 31
  2. Distinctive:

    After ACK, proceed to your inbox instructions.

    line 46
  3. Very specific:

    Read the task file: <team_state_root>/team/<teamName>/tasks/task-<id>.json (example: task-1.json)

    line 71
  4. Very specific:

    Never use legacy tasks/{id}.json wording.

    line 75
  5. Very specific:

    Do NOT directly write lifecycle fields (status, owner, result, error) in task files.

    line 79
  6. Very specific:

    Use omx team api release-task-claim --json only for rollback/requeue to pending (not for completion).

    line 80
  7. Very specific:

    Update your worker status: <team_state_root>/team/<teamName>/workers/<workerName>/status.json with {"state":"idle", ...}

    line 81
  8. Distinctive:

    Check your mailbox for messages:

    line 86
  9. Distinctive:

    When notified, read messages and follow any instructions.

    line 90
  10. Very specific:

    Prefer inbox/mailbox/task state and omx team api ...

    line 111
  11. Distinctive:

    Do not rely on ad-hoc tmux keystrokes as a primary delivery channel.

    line 112
  12. Very specific:

    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 …

    line 113
  13. Distinctive:

    If the lead sends a shutdown request, follow the shutdown inbox instructions exactly, write your shutdown ack file, then exit the Codex …

    line 117

“Common” is measured: kept by at least 6 in 10 of the 9 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

clawd 路径适配(重要):本技能移植自 oh-my-codex,文中所有 ~/.codex/...、 .codex/skills/、CODEX_HOME 都是 Codex 时代的路径。在 clawd 里真实生效的是:

  • 技能位置:<项目>/skills/<name>/SKILL.md(支持分组子目录,如 skills/reverse/<sub>/SKILL.md,发现逻辑是递归的)
  • 运行期数据/配置:<项目>/.clawd/(sessions/、logs/、features.json 等)
  • 查当前实际发现到的技能:clawd hud 或直接调 skill 工具;诊断环境用 clawd doctor

只有当你确实在 Codex 里运行本技能时,~/.codex/... 那套路径才成立。 在 clawd 里照着 ~/.codex/... 找文件只会得到"不存在"。

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:

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:

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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.