Name: worker
Rating: 61.6 (1 reviews)
Author: Yeachan-Heo

Blog Docs Log inGet started

worker

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

Quality

77%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

High

Do not use without reviewing

Fix and improve this skill with Tessl

tessl review fix ./plugins/oh-my-codex/skills/worker/SKILL.md

The canonical home for this skill is worker in Yeachan-Heo/oh-my-codex

Quality

Content

86%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is an exemplar of lean, command-driven skill writing: concrete CLI invocations with full payloads, a clearly sequenced task lifecycle with failure paths, and no wasted tokens. The only real gap is unstated provenance for the claim_token and a few undefined criteria ('unblocked assignment'), which slightly limit copy-paste executability.

Suggestions

State where the claim_token comes from, e.g. 'Use the claim_token returned by claim-task in subsequent transition commands.'

Define what makes an inbox assignment 'unblocked' or instruct the worker to skip assignments lacking a pending task file.

Dimension	Reasoning	Score
Conciseness	The body is lean and efficient with zero padding: every section ('When to use', 'Inputs and preconditions', 'Operational steps', 'Exit and evidence') carries operational content, no concepts Claude already knows are explained, and every token earns its place.	5 / 5
Actionability	Steps provide copy-paste-ready `omx team api` commands with complete JSON payloads and exact state-file paths, which is mostly fully-executable guidance. Minor gaps: the `claim_token` required in step 6 is never sourced (presumably the claim-task output, but this is unstated), and 'take the first unblocked assignment' leaves the blocked/unblocked criterion undefined, keeping it just below the fully-executable anchor.	4 / 5
Workflow Clarity	The 8-step sequence is clearly ordered with a claim-before-edit checkpoint, explicit failure paths ('Complete or fail through the lifecycle API', 'release-task-claim only to requeue a blocked task'), and defined observability requirements. Minor validation gaps remain: no instruction to confirm the ACK or claim-task command succeeded before proceeding, and no error-recovery loop if a transition fails.	4 / 5
Progressive Disclosure	The skill is under 50 lines with well-organized sections and no need for external reference files, so per the simple-skill guideline it scores 5 on structure alone; the single external pointer (`AGENTS.md#durable-runtime-invariants-canonical-ssot`) is clearly signaled and one level deep.	5 / 5
	Total	18 / 20 Passed

Description

57%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is concise, distinct, and names its domain concretely, but it reads as a compressed jargon label rather than an action-oriented trigger description. Adding an explicit 'Use when...' clause with natural trigger phrases would address its main gaps in completeness and trigger-term quality.

Suggestions

Add an explicit trigger clause, e.g. 'Use when the session was started as an OMX Team worker (OMX_TEAM_WORKER is set) or when coordinating tmux-based OMX team tasks.'

Phrase capabilities as concrete actions rather than parenthesized nouns, e.g. 'Sends startup ACKs, claims and transitions tasks through their lifecycle, and acknowledges mailbox messages as an OMX team worker.'

Include common term variations users might say (e.g. 'team worker', 'OMX team', 'task claim', 'inbox') to broaden natural trigger coverage.

Dimension	Reasoning	Score
Specificity	The description names the domain ('Team worker protocol') and lists concrete elements ('ACK, mailbox, task lifecycle'), but these are terse component nouns rather than the specific action phrases the anchor-4 example shows ('Extracts text from PDF files, fills forms, converts pages to images'), and coverage is not comprehensive.	3 / 5
Completeness	The 'what' is clear (worker protocol covering ACK, mailbox, task lifecycle), but the 'when' is only weakly implied by 'for tmux-based OMX teams' — there is no 'Use when...' clause or equivalent explicit trigger guidance, which caps completeness at 3 per the judging guidelines.	3 / 5
Trigger Term Quality	Relevant domain keywords are present ('Team worker', 'ACK', 'mailbox', 'task lifecycle', 'tmux-based OMX teams') that an OMX operator would naturally use, but there are no common variations or synonyms and no natural trigger phrasing, matching the 'some relevant keywords but missing common variations' anchor rather than the generic-only anchors below.	3 / 5
Distinctiveness Conflict Risk	The description carves out a clear niche — team worker protocol for tmux-based OMX teams — with distinct, highly specific triggers that would virtually never conflict with another skill.	5 / 5
	Total	14 / 20 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: Yeachan-Heo/oh-my-codex
Path: plugins/oh-my-codex/skills/worker/SKILL.md
Commit: 1dcf513

Reviewed: 4 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.