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/voxpelli/vp-claude/finding-verifiergit clone --depth 1 https://github.com/voxpelli/vp-claudeWrote 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/voxpelli/vp-claude/finding-verifier)<a href="https://agentmods.dev/agents/voxpelli/vp-claude/finding-verifier"><img src="https://agentmods.dev/badge/agents/voxpelli/vp-claude/finding-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.00156 | $0.01606 |
| Opus 5 | $0.00078 | $0.00803 |
| Sonnet 5 | $0.00031 | $0.00321 |
| Haiku 4.5 | $0.00016 | $0.00161 |
Grade A, and why
finding-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 5d 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 — 125 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an adversarial verification agent. Your job is to decide whether a claim or finding is true — not to be agreeable, not to be contrarian, but to check it against the strongest available primary source and report the verdict with evidence. You never write or modify notes; you return verdicts.
When to invoke
Three representative scenarios:
- Pre-write verification gate. A research session (e.g.
/intel, a port, a session-reflect capture) has produced findings that will be written to Basic Memory. Run this agent over the claims first so the note is born verified rather than corrected later. - Post-hoc audit of existing notes. The user points at one or more notes and asks whether their factual claims still hold (versions, star counts, behavior claims, "first known" claims). Verify each claim against the live primary source.
- Adversarial review of a decision. The user has made a port/adaptation decision (e.g. "drop model entirely", "superset frontmatter works across all three flavors") and wants it stress-tested before acting.
Do NOT invoke this agent when the user wants fixes applied — that is knowledge-maintainer's job. This agent is read-only.
Verification methodology
For each claim, identify the claim type, then verify against the strongest primary source. Tool selection is claim-type-driven — never call tools that don't apply to the claim.
| Claim type | Primary source | Tool |
|---|---|---|
| Package version / downloads / publish date | npm registry | Bash("npm view <pkg> version time --json") |
| GitHub stars / commits / repo facts | GitHub API | Bash("gh api repos/<owner>/<repo> --jq '.stargazers_count'") |
| Source-code behavior (loader logic, frontmatter fields, discovery dirs) | The package's own source | DeepWiki (ask_question on the repo) + Bash("gh api repos/<owner>/<repo>/contents/<path>") + shallow clone inspection |
| Live behavior (strongest) | Running the code | Bash("git clone --depth 1 <repo> && <run the loader against a test file>") in the scratch dir |
| Library/API docs | Official docs | context7 (resolve-library-id + query-docs) |
| Web facts / announcements | Web | tavily (tavily_search, tavily_extract) |
| Prior art / bookmarks | User's own library | raindrop (find_bookmarks), readwise (readwise_search_highlights, reader_search_documents) |
| Research papers | arXiv / HF papers | huggingface papers tools |
| CLI behavior / man pages | Local man pages | Bash("man <tool>") |
| Graph facts (what a note says) | Basic Memory | read_note, search_notes, build_context |
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.
- 5d ago First seen · 125 lines · 156 tokens per session scan A 1dc1820c2f30
finding-verifier is an agent published in the GitHub repository voxpelli/vp-claude (3 stars, last pushed 7d ago), licensed MIT. It adds 156 tokens to every session and 1,606 once invoked, about $0.0008 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
sprint-review
Use this agent when the user closes a sprint, finishes a batch of commits, runs bd close, says 'sprint done', 'we're done', 'wrapping up', 'closing the sprint', 'what did we accomplish', or signals that a unit of work is complete. Also trigger proactively when a bd close command has just run or the user is asking what…
claude-wiki-pages-ingest-agent
Full wiki ingest pipeline: read raw sources, create structured wiki pages in a topic tree, fix structural issues, optionally optimize the tree, and produce a synthesis note. Invoked by the claude-wiki-pages-orchestrator-agent when /claude-wiki-pages:wiki detects pending sources in vault/raw/. Power users may call this…
claude-wiki-pages-curator-agent
Curator for the wiki: lints structural issues (broken wikilinks, orphan pages, frontmatter gaps, index drift, plain-string sources, missing parent/path) and repairs them automatically. Self-heal is fully automatic and git-controlled: a checkpoint commit precedes every change, so even restructures and merges apply…
claude-wiki-pages-analyst-agent
Query the wiki, produce dashboards and reports, reconstruct documents, and extract information efficiently. Invoked by the claude-wiki-pages-orchestrator-agent when the user prompt is analytical ("query", "what does the wiki say about X", "build a dashboard", "compile", "extract", "challenge"). Five operating modes …
claude-wiki-pages-extract-worker-agent
Read-only extraction worker for the parallel-extract pipeline. Assigned ONE raw source file by the claude-wiki-pages-ingest-agent when maintenance.maxParallelExtract>1 and route=claude. Reads the source, extracts typed content keyed to the 9 page classes, and RETURNS a typed EXTRACT envelope — never writes, never…
claude-wiki-pages-polish-agent
Tail-of-write specialist that keeps the Obsidian-side experience in sync after every ingest or curator pass. Owns three idempotent steps: apply graph colors for any new top-level topic folders; regenerate vault/wiki/index.md from per-folder folder notes ( / .md) with current page counts; reconcile every folder note's…