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 avelikiy/great_cto --skill done-blockedgit clone --depth 1 https://github.com/avelikiy/great_ctoWrote 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/avelikiy/great_cto/done-blocked)<a href="https://agentmods.dev/skills/avelikiy/great_cto/done-blocked"><img src="https://agentmods.dev/badge/skills/avelikiy/great_cto/done-blocked/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/avelikiy/great_cto/done-blocked"><img src="https://agentmods.dev/badge/skills/avelikiy/great_cto/done-blocked.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00051 | $0.01344 |
| Opus 5.5 | $0.00020 | $0.00538 |
| Sonnet 5.5 | $0.00010 | $0.00269 |
| Haiku 4.5 | $0.00005 | $0.00134 |
Grade A, and why
done-blocked 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 1mo 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.
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 — 114 lines — stays where its author put it; the contents beside it link to each section on GitHub.
DONE / BLOCKED Reporting Contract
Terminal status is exactly two states, and BLOCKED requires specific evidence — not vague obstruction reports.
The contract
Every agent's final handoff line is one of:
DONE: <one-sentence summary of what shipped>
artifact: <path to report/PR/commit>
next: <who picks this up — pipeline stage, gate, or "pipeline continues">
BLOCKED: <one-sentence summary of the obstacle>
tried: <what was attempted — file paths, commands, error signatures>
failed_because: <concrete reason — not "unclear", not "complex">
need: <specific unblock — file access, missing config, CTO decision, another agent>
Hard rules
-
No third state. "Mostly done", "done with caveats", "almost there" → choose. If caveats exist, the caveat itself decides:
- Caveat is cosmetic / P2+ → DONE (file a Beads bug, move on)
- Caveat blocks the next pipeline stage → BLOCKED (do not pretend)
-
BLOCKED requires three fields.
tried+failed_because+need. Missing any field → the verdict is rejected and the agent must re-report. No exceptions for "obvious" cases. -
Silence is not DONE. If the agent stops producing output without a terminal line, the parent / next stage treats it as BLOCKED with
failed_because: silent — no terminal verdict written. -
failed_becausemust be concrete. These are rejected:- "environment issue" → say which command failed with what error
- "tests failing" → say which tests and the actual assertion message
- "unclear requirements" → say which decision is needed and the two options
- "not enough context" → say which file / doc / config you tried to read
-
neednames a specific unblock. These are rejected:- "more information" → ask one specific question
- "help from another agent" → name the agent (architect / security-officer / …)
- "CTO approval" → state the exact choice (approve gate X, pick option A vs B, waive check)
Where the verdict goes
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.
- 1mo ago First seen · 114 lines · 51 tokens per session scan A 3f1fd13c12e3
done-blocked is a skill published in the GitHub repository avelikiy/great_cto (106 stars, last pushed yesterday), licensed MIT. It adds 51 tokens to every session and 1,344 once invoked, about $0.0002 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-09-03.
Other skills, from other repositories
pm
Project manager for GitHub issues: brainstorm design approaches, create structured issues optimized for LLM agent teams, triage and recommend what to work on next, audit and clean up stale issues, or deep-validate a single issue against the codebase. Triggers: create issue, plan work, new task, project manager, write…
pocket-closing
Close a reviewed Pocket phase or plan when the user explicitly requests closeout, including as part of an end-to-end request. Reconcile verdicts with log.json, advance only a passing phase, append a readable per-phase closeout, and finalize the plan when all phases are done. A passing verdict alone does not authorize…
pm-tech-spec-review
Review an engineering technical spec through a PM lens — does it cover every PRD requirement, does it preserve user/UX intent, does it quietly add or drop scope, what are the product risks, what's missing for launch. Produces a priority-tagged findings list + clarifying questions for engineering. Use after eng drafts…
tpp-orchestrate
Work through a queue of Technical Project Plans serially — delegate each to a TDD subagent, get a cross-model second opinion, empirically vet every finding, and make one coherent commit per plan. Use when executing a documented plan queue such as todo/ or feat-name/ for a port, migration, or multi-stage feature.
tpp
Work a Technical Project Plan to completion — read the plan, start from its current phase, work through its tasks until their acceptance tests pass, and update the plan as each task lands. Use when starting or resuming multi-session work tracked in a plan file.
handoff
Update the active Technical Project Plan for handoff when context is running low or the session is ending, so the next session continues instead of restarting.