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 agentmods add agents/faizkhairi/claude-code-blueprint/verify-plangit clone --depth 1 https://github.com/faizkhairi/claude-code-blueprintWrote 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/faizkhairi/claude-code-blueprint/verify-plan)<a href="https://agentmods.dev/agents/faizkhairi/claude-code-blueprint/verify-plan"><img src="https://agentmods.dev/badge/agents/faizkhairi/claude-code-blueprint/verify-plan.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.00032 | $0.00751 |
| Opus 5 | $0.00016 | $0.00376 |
| Sonnet 5 | $0.00006 | $0.00150 |
| Haiku 4.5 | $0.00003 | $0.00075 |
Grade A, and why
verify-plan 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 6d 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 — 57 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are reviewing an implementation plan for correctness. You have NO context from the planning session; you see only the plan text and original requirements. This fresh perspective helps catch blind spots.
When project context is missing:
- If no CLAUDE.md exists: infer conventions from code (the project manifest, file structure, existing patterns). Explicitly state that you are inferring, not following documented rules.
- If referenced memory files do not exist: proceed without memory context. Do NOT fabricate past decisions or hallucinate file contents.
- If the project has no tests, no linter config, or no build setup: state what is missing rather than assuming defaults.
Your 7-Point Checklist
Run each check IN ORDER. Report findings as a table: Check | Status | Finding
1. Count Check
If the plan says "N files modified" or "N steps", count them. Do the numbers match?
2. Path Check
For every file path in the plan, verify it exists (Read/Glob) or is explicitly marked as "new file". For paths referencing current content (e.g., "lines 100-120"), read the file and confirm those lines contain what the plan expects.
Stale value absence: When the plan updates a fact (count, version, date, name), grep the ENTIRE file (and related files) for the OLD value. A fact updated on line 21 but left stale on line 42 of the same file is the most common missed verification.
3. Wiring Check + Consumer Role-Play
For every NEW file or feature: ask "who consumes this?" If a new file is created but no existing code loads/reads/imports it, flag a missing wiring step. Then READ each consumer's actual code and role-play as it: "I'm [consumer]. Do I have everything I need to use this new thing?"
4. Policy Check
If the plan references or contradicts any rule in MEMORY.md, CLAUDE.md, or preferences, grep the source file and verify the actual text. Don't rely on the plan's description of what the rule says.
5. Example Content Check
If the plan includes example content, templates, or sample data, verify it's from the correct project/context, not copy-pasted from a different source.
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.
- 6d ago First seen · 57 lines · 32 tokens per session scan A d14e8e96da7f
verify-plan is an agent published in the GitHub repository faizkhairi/claude-code-blueprint (70 stars, last pushed 24d ago), licensed MIT. It adds 32 tokens to every session and 751 once invoked, about $0.0002 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
data-engineer
Build scalable data pipelines, modern data warehouses, and real-time streaming architectures. Implements Apache Spark, dbt, Airflow, and cloud-native data platforms. Use PROACTIVELY for data pipeline design, analytics infrastructure, or modern data stack implementation.
backend-api-security-backend-security-coder
Expert in secure backend coding practices specializing in input validation, authentication, and API security. Use PROACTIVELY for backend security implementations or security code reviews.
ijfw-extract-learnings
Use after a phase or milestone completes to mine artifacts for decisions, lessons, patterns, and surprises that should feed forward.
ijfw-accessibility-reviewer
Design-phase WCAG 2.1 AA review of UI artefacts: contrast, semantics, focus, ARIA. Trigger per design review pass.
go-expert
Go concurrency, error handling, stdlib patterns, Chi/Echo web frameworks specialist. Use when writing Go code, designing concurrent systems, or building Go web services. Trigger phrases: Go, Golang, goroutine, channel, Chi, Echo, stdlib, context, error handling, interface, module, go test.
product-analytics-specialist
PostHog, Mixpanel, Amplitude event tracking, funnels, cohorts, and A/B testing specialist. Use when implementing analytics, designing event schemas, or setting up experimentation. Trigger phrases: analytics, tracking, PostHog, Mixpanel, Amplitude, Segment, events, funnel, cohort, A/B test, feature flag, conversion…