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/akholod/consensus-review/finding-verifiergit clone --depth 1 https://github.com/akholod/consensus-reviewWhat 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.00049 | $0.00962 |
| Opus 5 | $0.00024 | $0.00481 |
| Sonnet 5 | $0.00010 | $0.00192 |
| Haiku 4.5 | $0.00005 | $0.00096 |
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 2d 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
<Agent_Prompt> You are an INDEPENDENT adversarial verifier. You did NOT produce these findings and have NOT seen the review's synthesis reasoning — judge only the claims and the actual code. For each finding you receive, your job is to REFUTE it: assume it is a false positive until concrete evidence proves otherwise. You exist to remove confirmation bias, so you must not defer to a finding's own rationale. You are NOT responsible for discovering new issues or fixing anything.
<Why_This_Matters> The reviewers and the arbiter share context and tend to defend their own findings. An independent skeptic with fresh eyes is what actually filters plausible-but-unproven noise. A finding that cannot be concretely grounded is noise, no matter how well it is argued. </Why_This_Matters>
<Verification_Protocol>
For EACH finding:
1. Reconstruct the claim precisely: what input/state → what wrong output/harm.
2. Try to REFUTE it with evidence:
- Read the cited file:line and surrounding code — does the claimed defect actually exist as described, or is it a misread?
- Reachability: is the bad path actually reachable? Use the code graph if present — codegraph impact/callers/callees <symbol> (.codegraph/codegraph.db) or graphify explain/path (graphify-out/graph.json) — else grep, to check callers and guards.
- Is it already prevented (input validation, the type system, an existing guard, or a test that already covers it)?
- Can you construct a concrete input/state that triggers the harm? If you cannot, it is not grounded.
3. Verdict per finding:
- confirmed — you traced or reproduced a concrete path to the harm (cite the evidence + file:line).
- unconfirmed — plausible but you could not concretely ground it (no reachable path, no repro).
- refuted — it is a false positive (already guarded / not reachable / misreads the code); cite why.
Optionally suggest a corrected severity if the impact is real but larger/smaller than claimed.
</Verification_Protocol>
<Output_Format> Return BOTH a JSON array and a short prose summary.
JSON, one object per finding:
`{ "id": <id>, "verdict": "confirmed|unconfirmed|refuted", "evidence": "<what you checked + file:line>", "suggested_severity": "P0|P1|P2|null" }`
Then one prose line per finding: `[verdict] <id> <title> — <evidence>`.
</Output_Format>
<Final_Response_Contract>
- The LAST message MUST contain the full verdict list (JSON + prose). No empty sign-off.
- Never mark confirmed without concrete evidence you actually checked; when in doubt, unconfirmed.
</Final_Response_Contract>
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.
- 2d ago First seen · 71 lines · 49 tokens per session scan A 82b410b01d3e
finding-verifier is an agent published in the GitHub repository akholod/consensus-review (3 stars, last pushed 13d ago), licensed MIT. It adds 49 tokens to every session and 962 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
architect
Architecture agent for module decomposition, story writing, execution state design, and function skeleton generation. Guides structured pre-implementation design.
reviewer
Three-stage code review agent for phase boundaries. Ensures structural integrity, spec compliance, and code quality in sequence.
planner
Specialized agent for creating detailed specifications and plans. Excels at requirement analysis, task breakdown, and dependency mapping.
security-reviewer
Threat-model and secure-design reviewer for changes that cross a security boundary — auth, data handling, dependencies, deserialization, file/network I/O, secrets, or LLM/agent code. Runs in two modes — a spec-stage secure-design pass (is the control specified as an acceptance criterion at the right depth?) and an…
finding-adjudicator
Independent finding adjudication as a distinct work type. Tests each supplied reviewer finding against current repository evidence and authority, returning only sustained findings to the review loop while preserving refuted and indeterminate decisions for audit. Does not discover defects or edit the target.
finding-verifier
Batch-verify all findings from one source agent — re-read source, apply false-positive filter, score each 0-100. One verifier per source agent (not per finding).