agentsclimarketplace
Sign in

Worker

Skill mrzhangguoguo/oh-my-workbuddy/skills/worker

Protocol for a unit of work assigned to a WorkBuddy subagent (Agent tool) — ACK, claim-safe lifecycle, evidence-backed completion, and clean blocking escalation. Triggers: "worker protocol", "subagent task lifecycle", "claim task", "team worker".From its SKILL.md

Install
npx -y skills add mrzhangguoguo/oh-my-workbuddy --skill worker

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.5 KB, ~1.2k tokens by cl100k_base, as published. Nobody here has run it

Ported from oh-my-codex worker. OMX runtime conventions ($macro invocation, omx CLI, .omx/ state directory) are replaced with WorkBuddy idioms (Skill tool, Agent tool, task list, .workbuddy/memory).

Worker Protocol (WorkBuddy subagent)

This skill describes the discipline a WorkBuddy subagent (spawned via the Agent tool) should follow when a leader assigns it a unit of work. In OMX this was a tmux-pane Team worker driven by omx team api; in WorkBuddy there is no tmux runtime or omx binary. Coordination happens through (a) the Agent's returned result, and (b) optional shared artifacts under .omw/team/<team>/. The value preserved here is the claim-safe lifecycle, ACK-readback, and evidence discipline — not the transport.

Identity

A worker is created by a leader who spawns an Agent with a clear identity and task. The identity looks like:

<team-name>/worker-<n> — e.g. alpha/worker-2.

Pass the identity and the full task into the Agent prompt. There is no OMX_TEAM_WORKER env var to read; the prompt is the source of truth.

Startup Protocol (ACK)

  1. Parse the assigned identity into teamName (before /) and workerName (after /).
  2. Send a startup ACK before task work: in your first response (or as the first line of your returned result), state one short deterministic line, e.g. ACK: worker-2 initialized.
  3. After ACK, proceed to the assigned task.

If the team uses a durable mailbox artifact, write the ACK to .omw/team/<teamName>/mailbox/<workerName>.md; otherwise the ACK lives in your returned message.

Inbox + Tasks

  1. Read the task from the Agent prompt (the leader embeds the task directly — there is no separate inbox file to poll).
  2. If the team uses durable task files, read .omw/team/<teamName>/tasks/task-<id>.json; otherwise work from the prompt.
  3. Pick the first unblocked task assigned to you.
  4. Claim the task (do NOT start work without a claim): record {"state":"in_progress","owner":"<workerName>"} via TaskUpdate on the shared task list, or write it to the task file / .omw/team/<teamName>/workers/<workerName>/status.md.
  5. Do the work.
  6. Complete/fail via lifecycle transition: move the task to completed or failed with a short result/error note — TaskUpdate on the task list, or write to the task file. Do not leave lifecycle fields ambiguous.
  7. Write your worker status back: .omw/team/<teamName>/workers/<workerName>/status.md with {"state":"idle", ...} (or mark the corresponding task done in the task list).

Mailbox

Check for messages addressed to you:

.omw/team/<teamName>/mailbox/<workerName>.md

When notified, read messages and follow any instructions. Use short ACK replies when appropriate. Note: in WorkBuddy the primary delivery channel is the Agent's returned result to the leader; a mailbox file is only needed when work spans multiple turns or multiple workers must coordinate.

Dispatch Discipline (state-first)

Treat team state (task list / shared artifacts) as the source of truth.

  • Prefer the task list (TaskCreate/TaskUpdate) and .omw/team/<teamName>/... artifacts.
  • Do not rely on ad-hoc nudges as a primary delivery channel.
  • If a manual trigger arrives, 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 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 the task spec, 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.

Completion evidence

Always return, in your result, enough to verify the work:

  • what changed (files/paths),
  • the verification command run and its output (build/typecheck/test),
  • any manual QA notes,
  • remaining differences or open risks.

Shutdown

If the leader signals shutdown (via the prompt or mailbox), stop accepting new work, write your shutdown ack to .omw/team/<teamName>/workers/<workerName>/shutdown.md, and end your turn.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most context ai engineering skills give in ~1.2k tokens

Counted across 1,193 of the 1,976 authors here whose files we hold, read 2026-08-07

  • Dispatch a fresh implementer subagent per taskin 48 of 1193, across 19 files
  • Dispatch a final code reviewer after all tasksin 33 of 1193, across 8 files
  • Provide full task text to the subagentin 30 of 1193, across 9 files
  • Review spec compliance before code qualityin 27 of 1193, across 10 files
  • Make the hook script executablein 26 of 1193, across 8 files
  • Re-snapshot after navigation or DOM changesin 25 of 1193, across 19 files
  • Read files before editing themin 22 of 1193, across 11 files
  • Answer subagent questions before proceedingin 22 of 1193, across 7 files
  • Mark task complete in TodoWrite after approvalin 22 of 1193, across 6 files
  • Merge hook into existing settingsin 21 of 1193, across 3 files
  • Ask if installation is global or projectin 20 of 1193, across 2 files
  • Copy the hook script to target locationin 20 of 1193, across 2 files

Said here and by no other author read

  • parse assigned identity from prompt
  • read assigned task from agent prompt
  • use task list as source of truth
  • check mailbox for addressed messages
  • verify boundary contracts before completion
  • optimize for integrated team result

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,144. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.