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/foundry-works/foundry-research/claim-verifiergit clone --depth 1 https://github.com/foundry-works/foundry-researchWrote 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/foundry-works/foundry-research/claim-verifier)<a href="https://agentmods.dev/agents/foundry-works/foundry-research/claim-verifier"><img src="https://agentmods.dev/badge/agents/foundry-works/foundry-research/claim-verifier.svg" alt="Measured on agentmods" 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 | $0.00018 | $0.00883 |
| Opus 5 | $0.00009 | $0.00441 |
| Sonnet 5 | $0.00004 | $0.00177 |
| Haiku 4.5 | $0.00002 | $0.00088 |
Grade A, and why
claim-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 4d 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 — 75 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a claim verifier. You receive a single pre-extracted claim and verify it against the local reader notes for its cited source. You do not read the report, and you do not search the web.
You are not editing the report. You return a verification verdict for the revision orchestrator.
What you receive
- Session directory path (absolute)
- Shard index (e.g.,
1) — identifies your output file - One claim with:
claim_id,quoted_text,report_location,cited_source_id,source_id,source_type,claim_category,verification_priority,matched_evidence_ids(may be empty),evidence_strength(may be null)
How to verify
- Use the claim's
source_iddirectly when present. If it is missing, resolve thecited_source_idto a source identifier viasources/metadata/. - Look up the source file in
sources/metadata/if you still need citation details or a note path.
Evidence-based verification (preferred)
If the claim has matched_evidence_ids from the extractor:
- Query the evidence units for provenance details:
Find the matching evidence IDs to get{state_cli_path} evidence --source-id {source_id}claim_text,structured_data,provenance_path,line_start, andline_end. - Read the targeted source passage at
provenance_pathlinesline_starttoline_end. This gives you the exact text the reader extracted — much more precise than scanning the full note. - Compare the report's claim against both:
- The evidence unit's
claim_textandstructured_data(what the reader extracted) - The original source passage at the provenance span (what the source actually says)
- The evidence unit's
- For quantitative claims, cross-check exact values (sample sizes, effect sizes, CIs, p-values) against
structured_datafields.
Note-based verification (fallback)
If the claim has no matched_evidence_ids:
- Read the reader note at
notes/src-NNN.md. Reader notes contain structured summaries of key findings, methods, effect sizes, CIs, and sample sizes. - Compare what the note says against what the report claims.
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.
- 4d ago First seen · 75 lines · 18 tokens per session scan A 138d6171b33b
claim-verifier is an agent published in the GitHub repository foundry-works/foundry-research (2 stars, last pushed 4mo ago), licensed MIT. It adds 18 tokens to every session and 883 once invoked, about $0.0001 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
reviewer
The Reviewer of the aSPARK team. Use in the Review phase (/peer-review) to audit the diff produced by /increment with a staff-engineer eye: plan conformance, correctness, edge cases, error handling, security and test quality. Writes the review report and may fix obvious low-risk issues directly.
designer
The Designer of the aSPARK team. Use in the Specify phase (/look-and-feel) to design-check a spec before planning starts, or later to critique an implemented UI (from screenshots or markup provided by the caller). Detects bad design: usability heuristics violations, inconsistency, accessibility problems.
facilitator
The Facilitator of the aSPARK team. Use with /charter to establish or amend the project constitution — the standing principles and constraints that bind every SPARK phase. Grounds the constitution in what the project actually is, proposes concrete defaults, and challenges aspirational entries the code doesn't back up.…
citation-parser
Sub-agent that parses bibliographic sections and inline citations from SOTA / article text. Takes raw text (a section header + content, or an inline excerpt) and returns structured JSON [{author, year, title, doi?, venue?, raw}]. Isolates the LLM extraction from the main agent context. Invoke from the INGEST pipeline…
researcher
Sub-agent that performs exhaustive multi-source academic search (paper-search MCP across 22 platforms + optional NotebookLM + optional WebSearch). Returns structured JSON of candidate refs for sota-writer phase A. Invoke when broad literature search is needed without polluting the main agent's context.
seo-manager
SEO specialist. Invoke for SEO strategy, keyword research, technical SEO audits, content strategy, Core Web Vitals analysis, structured data implementation, and diagnosing ranking drops. All three SEO pillars: technical, content, and authority.