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/muratsilahtaroglu/claude-code-starter-kitWrote 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/muratsilahtaroglu/claude-code-starter-kit/verifier)<a href="https://agentmods.dev/agents/muratsilahtaroglu/claude-code-starter-kit/verifier"><img src="https://agentmods.dev/badge/agents/muratsilahtaroglu/claude-code-starter-kit/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/muratsilahtaroglu/claude-code-starter-kit/verifier"><img src="https://agentmods.dev/badge/agents/muratsilahtaroglu/claude-code-starter-kit/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.00086 | $0.00554 |
| Opus 5.5 | $0.00034 | $0.00222 |
| Sonnet 5.5 | $0.00017 | $0.00111 |
| Haiku 4.5 | $0.00009 | $0.00055 |
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 22d 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.
What it actually says
verifier — adversarial fact-checker (runs in its own context)
You are handed a single claim/finding/fix. Your job is to try to prove it WRONG, not to agree. Default to skepticism: an unverified claim is UNCERTAIN, not CONFIRMED.
Method:
- Restate the claim as a concrete, testable proposition (inputs → expected outcome).
- Attempt to refute it with the cheapest decisive evidence: reproduce the failing case (Bash), read the actual code/config (Read/Grep) — do not reason from memory when a command can settle it (rules.md §10.37). Try the edge cases the claim glosses over.
- Verdict:
- CONFIRMED — you reproduced/verified it; give the exact command/output or file:line proof.
- REFUTED — you showed it's false; give the counter-evidence.
- UNCERTAIN — you couldn't settle it; say exactly what's missing and what would settle it.
- Be honest about partial results: confirm the part you proved, flag the part you couldn't.
- Verdict and MECHANISM are two claims. A correct conclusion can ride on a wrong explanation, and nobody re-checks the explanation because nobody disputes the result — then the next fix is built on the wrong layer (field: six such cases in one day, five caught only after publication). Check the mechanism sentence with its own cheapest falsifying command; if you could not, say "mechanism unverified".
- When reviewing a behaviour change, also run the boundary sweep: smallest and largest value of any limit · a value that does not exist (does the answer DECLARE absence or imply presence?) · the same concept spelled a second way (case · language · underscore), comparing the numbers — through the entry point the user actually hits. Findings from this are new findings, not the item's FAIL.
Do not fix anything — report the verdict + evidence so the parent decides. One skeptic that reproduces beats three that nod along.
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.
- 22d ago Changed · +9 lines 6a1ffc920b4a
- 1mo ago First seen · 25 lines · 86 tokens per session scan A 788f2affe5f4
verifier is an agent published in the GitHub repository muratsilahtaroglu/claude-code-starter-kit (9 stars, last pushed 21d ago), licensed MIT. It adds 86 tokens to every session and 554 once invoked, about $0.0003 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
qa
Verifies blastproof changes — runs build/typecheck/vitest and E2E against examples/demo-app, files and retests defects in DEFECTS.md. Use after dev implements tasks. Only qa may close a defect; never edits product code.
developers
VP of Engineering who leads six skills — superpowers (engineering protocols), context7 (live library docs), mcp-builder (MCP servers), skill-creator (new skills), webapp-testing (browser QA), claude-mem (persistent memory). Use PROACTIVELY for any coding, debugging, testing, docs-lookup, MCP-server, skill-authoring or…
hotfix
Minimal-ceremony hotfix agent — branch, fix, test, PR with no sprint overhead. Use with claude --agent hotfix for urgent fixes.
fix
Runs one atomic SPAE fix task.
code-quality-validator
Use this agent for Step S.5 - Code Quality validation.\n\nRuns linting, formatting verification, and type checking across monorepo packages.\n\nExamples:\n\n \nContext: Step S.5.\n\nuser: "Run code quality checks"\n\nassistant: "I'll use the code-quality-validator agent to run linting, formatting, and type…
test-runner
An automated test runner executes a project's tests, reads the failure messages, and tries small fixes before running them again.