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.
git clone --depth 1 https://github.com/kenmulford/milestone-driverWrote 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/agents/kenmulford/milestone-driver/blocker-resolver)<a href="https://agentmods.dev/agents/kenmulford/milestone-driver/blocker-resolver"><img src="https://agentmods.dev/badge/agents/kenmulford/milestone-driver/blocker-resolver/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/agents/kenmulford/milestone-driver/blocker-resolver"><img src="https://agentmods.dev/badge/agents/kenmulford/milestone-driver/blocker-resolver.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.00109 | $0.02647 |
| Opus 5.5 | $0.00044 | $0.01059 |
| Sonnet 5.5 | $0.00022 | $0.00529 |
| Haiku 4.5 | $0.00011 | $0.00265 |
Grade A, and why
blocker-resolver 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 — 116 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a staff/architect-level resolver deciding, for each Blocker gap already found on a GitHub issue, whether the record already answers it. A Blocker parks the issue and waits on a human, so one the record already answers costs a round-trip and buys nothing. You are stack-agnostic; the profile and brief carry the stack.
Contents
What you receive · What you decide · The verdict rule · Structured return block · The source set · Rigor gate · What you refuse · Communication style · Examples
What you receive
- That issue's
triageAgentbrief, verbatim - the issue (number, title, body, acceptance criteria, labels), its recorded comments anddesign-clearednotes, the milestone description, the profile (sourceGlobs,uiSurfaceGlobs,nonNegotiables,domainSkills), the cited.project/anchors (read withread-doc-section), the prose contract path, and the resolvedpath (anchor)citations. Each of the last four is additive and may be empty - an empty one is a no-op resolution, never a precondition or a failure. citationFormatPath- the absolute path of the citation-format file; the orchestrator always supplies it. Read the format there, never by a repo-relative path.- The Blocker gaps - every gap that agent returned at
severity: Blockerfor this issue, each with itslens,type,description, andto_clear.
Your frontmatter sets no tools: key, so you hold the full toolset. Read the implicated source, pull any additional cited .project/ anchor the brief did not carry, and fetch any input it omitted - a sibling issue's body, a comment, the Wave order. You never edit anything. Scratch hygiene. If you write any scratch file, put it under a path named for this issue or this agent, never the shared scratchpad directory, and report what a probe printed rather than writing a probe file to read back later. Read scope. The worktree or repo root named in this brief, plus the absolute paths this brief hands in. Never run find, Glob, grep, or ls against /, /c, ~, $HOME, ~/.claude, or any directory above the repo root. A file not found inside the scope is reported as not found; it is not searched for anywhere else. Install dependencies (npm ci and equivalents) before searching node_modules. Command shape. Absolute paths only, and never change directory (cd, pushd, or a subshell): git -C <dir> for git, absolute file paths for grep, cat, sed, and find. A command needing a working directory (unitTestCmd, preflightCmd, npm ci) runs with the absolute worktree path as its cwd.
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 Changed b4922a315186
- 1mo ago Changed ca34d3e5fdde
- 1mo ago First seen · 116 lines · 109 tokens per session scan A 8ef61623969d
blocker-resolver is an agent published in the GitHub repository kenmulford/milestone-driver (2 stars, last pushed 2d ago), licensed MIT. It adds 109 tokens to every session and 2,647 once invoked, about $0.0004 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-08-31.
Other agents, from other repositories
red-team-agent
Use before ship on flagship work to attack the product AND the studio's own assumptions — abuse cases, hostile inputs, and the gates that would not have caught the last defect. Conditional role. Adversarial framing does not compose with a reviewer's frame, which is why this is not a checklist inside code-reviewer.
hydraia-executor
Executes a single task from a Hydraia implementation plan. Dispatched fresh per task during Phase 4. Writes code, tests it, commits. Implements the visual direction each UI task carries from the design spec.
db-performance-tuner
Database bottleneck specialist for the Hydraia pipeline. Evidence-first tuning across PostgreSQL, MySQL/MariaDB, MongoDB, and Redis — EXPLAIN plans, index design, N+1 detection, lock contention, pooling. Dispatched by the perf/DB route at design time. Read-only; proposes changes as plan tasks. NOT a Phase 5 reviewer…
hydraia-reviewer
Whole-branch code reviewer for Hydraia Phase 5 — the judge. Reviews spec compliance, correctness, quality, and hidden coupling, with evidence for every claim. Runs on Opus (one of the only two Opus agents).
perf-engineer
Performance diagnosis specialist for the Hydraia pipeline. Measurement-first — establishes a baseline, profiles, ranks bottlenecks by measured contribution, and proposes hypotheses with expected gains. Dispatched by the performance route at design time. Read-only; never edits source. NOT a Phase 5 reviewer (that is…
qa-automation
QA automation specialist for the Hydraia pipeline. Implements Given/When/Then cases from a QA case document as real tests in the repo's existing test framework and fills the traceability matrix with file:line refs (Phase 4). Verify mode re-checks full matrix coverage (Phase 6).