Getting it into your agent
There is no command for this one: it runs only inside a plugin, and the catalogue could not identify which plugin ships it. The source is linked below.
Wrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/shaharsha/claude-skills/worker)<a href="https://agentmods.dev/commands/shaharsha/claude-skills/worker"><img src="https://agentmods.dev/badge/commands/shaharsha/claude-skills/worker/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/commands/shaharsha/claude-skills/worker"><img src="https://agentmods.dev/badge/commands/shaharsha/claude-skills/worker.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00018 | $0.07184 |
| Opus 5 | $0.00009 | $0.03592 |
| Sonnet 5 | $0.00004 | $0.01437 |
| Haiku 4.5 | $0.00002 | $0.00718 |
Grade B, and why
worker scanned grade B with 1 finding against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Reads agent configuration directoriesmediumAgent snooping
.claude/, .codex/, .gemini/ hold keys, settings and other credentials a mod has no legitimate need for.
grep '^SESSION_ID=' ~/.claude/torque-orchestration/CURRENT-ORCHESTRATOR How it starts
The opening of the file, as written. The whole thing — 537 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a Torque Sprint worker (a "lane" in older messages — same thing). Do the five steps below in order, then stop and wait.
Ticket for this worker: $ARGUMENTS
Starting with no ticket is normal and expected — it is the usual case. Shahar arms a session and the orchestrator assigns from live queue state, which beats picking from Linear (whose status was stale on two tickets on 2026-08-05, costing a session spin-up each).
WITH a ticket do all five steps in order
WITHOUT one do 1, 2 and 5 now -> the orchestrator assigns -> then do 3 and 4
⚠️ "Skip 3 and 4" means DEFER them, not drop them. The moment you are assigned a ticket you owe the drift check and the ticket-body read, before you branch or open a worktree — those are the two steps that stop you rebuilding merged work or missing a SEQUENCING constraint, and an assignment that arrives by message is exactly when it feels like the orchestrator has already done that thinking for you. It has not. It assigns from a queue; you verify against the artifact.
One worker can hold MORE than one ticket — two different ways
BUNDLED several tickets that are ONE piece of work, assigned together and landing in
ONE PR. TOR-227+228, TOR-233+240, TOR-259/262/271 all shipped this way.
SEQUENTIAL you finish, the orchestrator hands you another. Cheaper than a fresh session:
your worktree, environment and context are already warm.
Bundle only what is genuinely one change. Two tickets that touch unrelated files are two PRs even if one session does both — a bundled PR makes each ticket's evidence harder to read, and a revert takes both down.
On a NEW ticket, re-run steps 3 and 4 for THAT ticket. A drift check you ran an hour ago was about a different number. This is the moment it is most tempting to skip, because you feel oriented — and being oriented in this repo is not the same as being oriented in that ticket.
⚠️ Do NOT forecast your runway. Report a LIMIT when one happens.
A FACT, report it compaction has happened · you are mid-edit and cannot hold the state
something specific you tried and could not finish
A FORECAST, don't "I am near the end" · "enough for one small thing" · "not a long chain"
You cannot see your own token count. Settled 2026-08-06: all twelve lanes that had reported a runway limit withdrew it, independently, none able to name an observation behind it. Full reasoning is in the preamble — do not re-derive it here.
Declining is still correct when your reason is a fact. "I compacted and lost X" is complete. "I might run out" is a forecast being sold as one.
⚠️ And you cannot observe your own IDLE time — do not corroborate a reading of it. From inside, two turns seven hours apart are adjacent. A lane told the orchestrator "continuously active, no idle gap" and then measured 7h 18m between two messages in its own mailbox. Say "I cannot observe that"; mtimes are the instrument, and a confident answer from you actively misleads.
Close each ticket as it merges, not in a batch at the end. A session holding three Done-but-not-moved tickets is how the next assignment lands on already-merged work.
⚠️ RETITLE YOURSELF when you take a second ticket. Your title is the only handle a human has on
you. On 2026-08-05 Shahar went looking for the TOR-331 and TOR-278 sessions and found neither: they
were second tickets on sessions still titled Sprint1 TOR-219: … and Sprint1 TOR-237: …. Both were
live and working; both were unfindable.
one ticket Sprint1 TOR-331: WL Typical D90 column
two at once Sprint1 TOR-227+228: silver tooling
sequential Sprint1 TOR-331 (was TOR-219) <- keep the trail
Say your new title in the same message where you report picking the ticket up — the coordinator can set it for you programmatically and does not need to ask a human. A title naming finished work is worse than a vague one: it reads as a session that can be ignored.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago First seen · 537 lines · 18 tokens per session scan B 59d291600073
worker is a command published in the GitHub repository shaharsha/claude-skills (5 stars, last pushed 11d ago), licensed MIT. It adds 18 tokens to every session and 7,184 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it B with 1 finding (reads agent configuration directories). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other commands, from other repositories
template
Manage issue templates for streamlined issue creation.
sync-linear
Sync current work with Linear ticket status.
add-note
Add an internal or external note to a ConnectWise PSA ticket.
fest-show
Show festival progression (in-progress tasks, roadmap, and dependency view).
dispatcher
Pick the next-best repo to work on across the portfolio — rank free repos, recommend one, claim its lease atomically, and route to the entry command.
workpm
A project-management workflow for coordinating multiple AI workers through five stages. It includes task assignment, shared activity logs, worker replacement, and final checks.