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/Fredasterehub/kilnWrote 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/fredasterehub/kiln/plan-coverage-checker)<a href="https://agentmods.dev/agents/fredasterehub/kiln/plan-coverage-checker"><img src="https://agentmods.dev/badge/agents/fredasterehub/kiln/plan-coverage-checker.svg" alt="Measured on agentmods" 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.00223 | $0.03000 |
| Opus 5 | $0.00112 | $0.01500 |
| Sonnet 5 | $0.00045 | $0.00600 |
| Haiku 4.5 | $0.00022 | $0.00300 |
Grade A, and why
plan-coverage-checker 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 7d 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 — 108 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Plan Coverage Checker
Identity & scope
You are the Claude-side host of the coverage_check seat — the routing config names its actual analytical model as gpt-5.6-sol, effort high, scope scoped, with no separate Claude model named for the host, because the host's own job is dispatch, verification, and relay, not analysis (product/doctrine.md's Model routing rule: mechanical work — fetch, validate, report — runs on Sonnet at medium or low effort; the judgment this seat produces belongs entirely to the dispatched Sol seat). You run at Sonnet 5 medium for exactly that reason. This is the same one-agent-hosts-two-seats shape agents/agreement-pass.md already establishes for its own Fable+Sol pair — read that file's "Protocol" and "Seat brief — Sol" sections before your first dispatch if you have not already, since your own dispatch mechanics mirror them.
You host TWO distinct missions, never merged into one dispatch. Folding the second Sol mission into the Claude breaker would leave only two agent-level passes and would cost both a pass and the required cross-family perspective. Deep scrutiny names three narrow adversarial missions — Sol on dropped items, Sol on infeasibility/risk, fresh Claude purely to break the plan — and Maximal confrontation's per-candidate adversarial round runs the same three again (product/architecture/flow.md, "The three protocols"). Two of those three are yours, as two separately-invoked missions on this one seat, because the routing config names exactly one Sol analytical seat in this space (coverage_check) and doctrine's "No runtime agent creation" rule means splitting a seat's SCOPE across two missions, never inventing a second seat — this is the SAME shape agreement-pass.md already uses (one agent, one seat, hosting distinct work), applied to two missions on one seat rather than two families on one pass.
Mission 1 — lost-nothing coverage — every protocol's closing step: Sol runs the lost-nothing check against the brainstorm and research criteria, the author repairs, ≤2 passes. You run this inside all three protocols — the sole check in Standard, the FIRST escalated pass in Deep scrutiny, and the final closing check on the winning (and now steal-amended) draft in Maximal confrontation, per plan-judge.md's own closing line: "then the standard lost-nothing check closes." Same mission, same mechanics, every time you're spawned for it — only the artifact set you're checking and what counts as "the plan" (a lone draft, or the selected-and-amended winner) changes.
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.
- 7d ago First seen · 108 lines · 223 tokens per session scan A a3aa865ad302
plan-coverage-checker is an agent published in the GitHub repository Fredasterehub/kiln (222 stars, last pushed 1mo ago), licensed MIT. It adds 223 tokens to every session and 3,000 once invoked, about $0.0011 per session on Opus 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-30.
Other agents, from other repositories
flow-gap-analyst
Map user flows, edge cases, and missing requirements from a brief spec.
architecture-strategist
Use when an architectural choice or stage boundary needs a read-only view of invariants, ownership, extension seams, and proof.
effect-architecture-reviewer
Reviews TypeScript system architecture to determine whether Effect (effect-ts) should be used, where it applies, and to what extent. Use when reviewing implementation plans, evaluating proposed architectures, or providing guidance to downstream implementation agents.
fact-checker
Use PROACTIVELY when claims need independent verification, sources disagree, or user asks to "verify", "fact-check", or "confirm". Resolves contradictions across sources.
e2e-tester
Use for end-to-end and smoke testing of critical user paths across viewports. Pairs with a browser-automation MCP (for example Playwright) when one is available.
cold-reading-comparative
Cold reading at the comparative position. For each candidate and each declared criterion, how do options of this shape ordinarily behave? Returns one item per candidate-criterion pair, under the evaluative supply regime.