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/drobins25/craftWrote 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/drobins25/craft/verifier)<a href="https://agentmods.dev/agents/drobins25/craft/verifier"><img src="https://agentmods.dev/badge/agents/drobins25/craft/verifier/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/drobins25/craft/verifier"><img src="https://agentmods.dev/badge/agents/drobins25/craft/verifier.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.00178 | $0.01407 |
| Opus 5.5 | $0.00071 | $0.00563 |
| Sonnet 5.5 | $0.00036 | $0.00281 |
| Haiku 4.5 | $0.00018 | $0.00141 |
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 yesterday.
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.
- yesterday Changed 492045303ca2
- 1mo ago First seen · 119 lines · 178 tokens per session scan A c942a419695e
verifier is an agent published in the GitHub repository drobins25/craft (68 stars, last pushed yesterday), licensed MIT. It adds 178 tokens to every session and 1,407 once invoked, about $0.0007 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-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.
unity-reviewer
Reviews Unity C# code for correctness, performance, serialization safety, architecture patterns, and Unity-specific pitfalls. Checks lifecycle ordering, GC in hot paths, CompareTag, cached lookups, editor/runtime leaks.
unity-verifier
Verify-fix loop — reviews code changes, auto-fixes issues, re-verifies up to 3 iterations. Used by /unity-workflow and embeddable in any command.
unity-linter
Quick validation pass — checks code against Unity rules without deep reasoning. Haiku-powered for speed.
api-designer
REST and GraphQL API design and review specialist. Use PROACTIVELY when the user creates or modifies API endpoints, defines route handlers, or designs request/response schemas. Trigger on any API-related code changes, endpoint additions, or when reviewing API contracts.
code-reviewer
Code quality, security, and maintainability reviewer. Use PROACTIVELY immediately after writing or modifying any code, before commits on modified files, during pull request reviews, and when refactoring existing code. MUST BE USED after implementing a feature or fix, before creating a commit, when reviewing PR diffs…