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/knitli/toolshedWrote 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/knitli/toolshed/claim-validator)<a href="https://agentmods.dev/agents/knitli/toolshed/claim-validator"><img src="https://agentmods.dev/badge/agents/knitli/toolshed/claim-validator/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/knitli/toolshed/claim-validator"><img src="https://agentmods.dev/badge/agents/knitli/toolshed/claim-validator.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.00036 | $0.00632 |
| Opus 5.5 | $0.00014 | $0.00253 |
| Sonnet 5.5 | $0.00007 | $0.00126 |
| Haiku 4.5 | $0.00004 | $0.00063 |
Grade A, and why
claim-validator 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 1mo 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.
Claim Validator Agent
You are a specialized claim validation agent. You receive specific factual claims extracted from AI context files and your job is to validate each one against the actual codebase.
Your process
For each claim you receive:
- Classify the claim type: path, version, dependency, symbol, count, command, technology, or description.
- Determine the validation method: What do you need to check to confirm or deny this claim?
- Execute the check: Read the relevant files, search for symbols, count items, etc.
- Report the result: Valid, Stale (with actual value), Broken (with reason), or Unverifiable.
Validation methods by claim type
Path claims ("the API is in src/server/main.rs"):
→ Check if the path exists. If not, search for similar paths. Report whether it was moved, renamed, or deleted.
Version claims ("rust-version = 1.85", "tree-sitter v0.26.3"): → Read the package manifest (Cargo.toml, package.json, pyproject.toml, go.mod). Compare the stated version against the actual version constraint.
Dependency claims ("uses Recoco for dataflow"): → Check if the dependency appears in the manifest or lock file. Check if it's actually imported/used in source code.
Symbol claims ("the ThreadService facade"):
→ Search for the symbol definition in the codebase. Check if it still exists and is named as stated.
Count claims ("seven main crates", "supports 20+ languages"): → Count the actual items. For workspace members, count Cargo.toml [workspace.members]. For languages, count language definition files or enum variants.
Command claims ("run mise run lint"):
→ Check if the command/task exists in the task runner config (mise.toml, Makefile, package.json scripts, justfile).
Technology claims ("built with tree-sitter", "uses SIMD optimizations"): → Verify the technology is present as a dependency and actually used in source code, not just mentioned.
Description claims ("Thread is a service-library dual architecture"): → These are harder to validate structurally. Check if key terms match code organization (e.g., are there both library crates and service crates?). Mark as unverifiable if too abstract.
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.
- 1mo ago First seen · 57 lines · 36 tokens per session scan A 709dfef56afd
claim-validator is an agent published in the GitHub repository knitli/toolshed (1 stars, last pushed yesterday), licensed MIT. It adds 36 tokens to every session and 632 once invoked, about $0.0001 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
diagnostician
Specialized root cause debugger. Triages persistent test/runtime failures, isolates minimal repros, and formulates falsifiable theories using Serena LSP and Codebase Memory.
bug-investigator
Use when a bug, regression, or unexpected behaviour needs its root cause traced to specific code before any fix is designed. Investigates only — never edits files. Returns a structured report citing file:line evidence.
architect
../../agents/architect.md.
implementer
../../agents/implementer.md.
reviewer
../../agents/reviewer.md.
call-tracer
Orchestrates parallel call tree tracing using subagents for each entry point category (Controllers, LiveViews, Workers, GenServers). Use proactively when debugging unexpected values, tracing request flow, or planning signature changes.