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/knitli/toolshed/claim-validatorgit clone --depth 1 https://github.com/knitli/toolshedWhat 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.00036 | $0.00632 |
| Opus 5 | $0.00018 | $0.00316 |
| Sonnet 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 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 — 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.
- yesterday 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 4mo ago), licensed MIT. It adds 36 tokens to every session and 632 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-31.
Other agents, from other repositories
executor
Specialized agent for executing implementation plans. Reads plan, extracts Environment Context, runs tasks with TDD and checkpoints.
code-reviewer
Independent senior code reviewer. Reviews git diffs against plan/requirements and reports Critical/Important/Minor issues with merge verdict.
plan-reviewer
Independent implementation plan reviewer. Checks completeness, spec alignment, task decomposition, and buildability before execution.
plan-writer
Specialized agent for creating implementation plans. Scans codebase, uses graph analysis, creates plan file. Does NOT execute tasks.
architect
../../agents/architect.md.
implementer
../../agents/implementer.md.