Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add zookanalytics/gc-toolkit --skill waitsgit clone --depth 1 https://github.com/zookanalytics/gc-toolkitWrote 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/skills/zookanalytics/gc-toolkit/waits)<a href="https://agentmods.dev/skills/zookanalytics/gc-toolkit/waits"><img src="https://agentmods.dev/badge/skills/zookanalytics/gc-toolkit/waits/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/skills/zookanalytics/gc-toolkit/waits"><img src="https://agentmods.dev/badge/skills/zookanalytics/gc-toolkit/waits.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.00166 | $0.02284 |
| Opus 5.5 | $0.00066 | $0.00914 |
| Sonnet 5.5 | $0.00033 | $0.00457 |
| Haiku 4.5 | $0.00017 | $0.00228 |
Grade A, and why
waits scanned grade A with 0 findings 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 today.
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.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 154 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Waits: when work can go
A wait is an edge onto a bead, and there is no parked state. What a person owes
is a demand bead and what a pool owes is a work bead. A bead that still has work
to do once that bead closes is blocked by it: a blocks edge keeps it out of
bd ready until that bead closes, and then it is ready. A bead whose whole job
ends when that bead closes carries an until edge to it instead, and is closed
once that bead has closed. Never write triage.hold, and never leave a
stamped, still bead as the record of a wait.
Each option says what the message means, who acts on it, and the one writer
that sends it. The writer's --help carries its flags. The writers are the
gc-toolkit pack's own scripts. gc <binding> scripts-dir prints their
directory in the pack as gc loaded it, so each example calls the pack's copy
inside the command itself, and runs in a fresh shell. <binding> is the name
the city imports the pack under, which gc puts in front of this skill's name:
gc-toolkit in gc-toolkit.waits. gc skill list prints it in this skill's
FROM column.
Make a bead wait on other work
The message is that this bead does not go until that one closes. bd acts on
it: the waiting bead stays out of bd ready, and once the blocker closes a
routed bead is offered to its pool again. A waiting bead with no route needs an
arm (below), or nothing sends it.
Writer: gc bd dep add <waiting-bead> <blocker> --type=blocks. Read the edge
back with gc bd dep list <waiting-bead> --direction=down -t blocks, because a
link across two stores prints success and holds nothing. When it does not read
back, the blocker is in another rig's store, so remove that edge and make the
bead wait on a demand in its own store that names the blocker (below), which
the operator resolves once the blocker lands.
- The two are never parent and child. bd refuses a
blocksedge from a parent to its own descendant, so never file the blocker under the bead that waits on it (the work skill). - A pull request's anchor that waits on an open bead cannot merge until that bead closes. When a follow-up needs the PR on main, make the follow-up wait on the anchor, never the anchor on the follow-up.
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.
- today Changed · +38 lines · +38 tokens per session 8f7258ce44fe
- yesterday First seen · 116 lines · 128 tokens per session scan A 300b2a9f314d
waits is a skill published in the GitHub repository zookanalytics/gc-toolkit (5 stars, last pushed today), licensed MIT. It adds 166 tokens to every session and 2,284 once invoked, about $0.0007 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-10-17.
Other skills, from other repositories
dispatch
Use when a task file exists in .hyperflow/tasks/ and workers need dispatching. Fans out parallel workers under per-batch Reviewers, runs a final integration review, and commits per sub-task. Endpoint of the auto-chain — no auto-deploy. Trigger with /hyperflow:dispatch, "run the plan", "execute the task", "build it"…
commonly
You are a member of a Commonly workspace — a shared space where humans and AI agents from any origin collaborate in pods (chat rooms with memory). Use this whenever you are connected to Commonly via the commonly MCP tools: to read what's happening, post, remember things across sessions, react, DM other agents, and…
sdlc-accelerate
End-to-end SDLC ramp-up from idea to construction-ready with automated phase transitions.
project-awareness
Detect project type, AIWG framework state, team configuration, and active work to summarize status and recommend next actions.
artifact-metadata
Manage artifact metadata, versioning, ownership, and review history across the SDLC lifecycle.
mission-control
Orchestrate multi-loop background operations via the Mission Control dashboard — start sessions, dispatch missions, monitor, and stop.