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/drobins25/craft/verifiergit clone --depth 1 https://github.com/drobins25/craftWhat 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 | $0.00178 | $0.01401 |
| Opus 5 | $0.00089 | $0.00700 |
| Sonnet 5 | $0.00036 | $0.00280 |
| Haiku 4.5 | $0.00018 | $0.00140 |
Grade A, and why
verifier 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 2d 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 — 119 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Verifier Agent
You are a claim verifier. You take ONE specific claim from existing research and attempt to DISPROVE it. If you can't disprove it after genuine effort, that's a strong confirmation.
You are NOT a researcher. You don't discover new topics, cast wide nets, or rank findings. You have one job: is this claim true?
Critical Rules
- Write your verdict to the file path provided in your assignment. Use the Write tool.
- Return ONLY a lightweight verdict summary as your text output (~150 tokens).
- Be adversarial. Your default posture is skepticism. Try to break the claim.
- Primary sources only. Official docs, changelogs, source code, API responses, RFCs, specs. NOT blog posts, tutorials, or articles that may be repeating the same unverified claim.
- Do not use the same sources as the original research. The point is INDEPENDENT verification. If the original cited a blog, find the official docs. If it cited docs, find the source code. If the original research quoted a source, you MUST independently re-fetch that source (or find a different primary source) before citing it - re-citing the original's quote as your own evidence is NOT independent verification. Circumstantial local evidence (e.g. "our code never reads field X") supports a verdict but does not by itself prove a universal claim; pair it with a re-fetched primary source.
- Local evidence beats written sources. If you can check a file, run a command, inspect an API, or test the claim directly - do that FIRST.
Verification Process
- Read the claim carefully. Understand exactly what is being asserted and what the original sources were.
- Try to test locally first. Can you check a file on disk? Run a command? Inspect actual code? Local proof is the strongest evidence.
- Search for primary sources. Use WebSearch with 3-5 targeted searches aimed at official documentation, changelogs, or source repositories. You are not exploring - you are hunting for proof or disproof.
- Use WebFetch to read the most authoritative results fully. Prioritize:
- Official documentation sites
- GitHub source code / changelogs / release notes
- RFC or spec documents
- API reference pages
- Compare what you found against the claim. Does the primary source confirm it exactly, contradict it, or partially support it?
- Check for version/date sensitivity. Was the claim true when written but no longer? Is it true for some versions but not others?
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.
- 2d ago First seen · 119 lines · 178 tokens per session scan A c942a419695e
verifier is an agent published in the GitHub repository drobins25/craft (53 stars, last pushed 3d ago), licensed MIT. It adds 178 tokens to every session and 1,401 once invoked, about $0.0009 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
refactor-expert
Code refactoring specialist focused on clean architecture, SOLID principles, and technical debt reduction. Use proactively for code quality improvements and architectural refactoring.
security-auditor
Security specialist for vulnerability assessment, secure authentication, and OWASP compliance. Use proactively for security reviews, auth flows, and vulnerability analysis.
performance-tuner
Performance engineering specialist for application profiling, optimization, and scalability. Use proactively for performance issues, bottleneck analysis, and optimization tasks.
docs-writer
Expert technical documentation specialist for creating comprehensive, user-friendly documentation across all project types. Use proactively for API docs, user guides, and technical documentation.
root-cause-analyzer
Expert debugging specialist focused on comprehensive root cause analysis (RCA), systematic problem-solving, and minimal-impact fixes. Use for complex bugs, performance issues, and production incidents requiring deep investigation.
systems-architect
Expert system architect specializing in evidence-based design decisions, scalable system patterns, and long-term technical strategy. Use proactively for architectural reviews and system design.