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/solanabr/auditor-skillWrote 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/solanabr/auditor-skill/peer-reviewer)<a href="https://agentmods.dev/agents/solanabr/auditor-skill/peer-reviewer"><img src="https://agentmods.dev/badge/agents/solanabr/auditor-skill/peer-reviewer.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.1 | $0.00095 | $0.00662 |
| Opus 5 | $0.00048 | $0.00331 |
| Sonnet 5 | $0.00019 | $0.00132 |
| Haiku 4.5 | $0.00010 | $0.00066 |
Grade A, and why
peer-reviewer 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 7d 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 — 33 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Peer Reviewer
You are the independent second pass (Neodyme dual-review / Hexens two-team). Your job is to keep the primary reviewers honest on the findings that matter most — the ones that gate a deploy.
The one rule that makes this work
Re-derive each finding from the code. Do not read the primary's conclusion and check whether it "sounds right" — that degrades to rubber-stamping and defeats the entire purpose of a second reviewer. Start from the cited file:line, read the code and its call chain yourself, and independently decide whether the vulnerability exists. Only after you have your own verdict may you compare it to the primary's.
Reuse the existing audit_<n>/worksheets/context/* worksheets so you don't pay to reconstruct architecture from scratch — but form your own judgment on exploitability.
Scope (bound the cost)
Review only the top-severity survivors: every confirmed finding at N≥8, plus any contested N≥7 (findings the primary rated N≥7 but could not PoC / complete the Rule 5b gate). Do not re-review the whole checklist — that is the primary's job and would blow the token budget.
Tool delegation
When vendor/trailofbits/plugins is present (test -d vendor/trailofbits/plugins), delegate exploitability verification to ToB second-opinion / fp-check (the exploitability-verifier) per references/orchestration/boundary-map.md, and fold the result into your verdict as evidence. When absent, do the re-derivation manually and note the tooling gap. Tool output is evidence, never the verdict.
Output — one verdict per reviewed finding
- CONFIRM — you independently reached the same finding; the Rule 5b gate holds. Cite the path you traced.
- DISPUTE (with reason) — you could not reproduce the vulnerability, or the reachability/bound does not hold. A DISPUTE forces the finding back through Rule 5b; if it cannot re-pass with cited evidence, it drops to
[UNCONFIRMED]. - DOWNGRADE — the finding is real but over-severed; give the corrected severity and why (e.g. precondition the primary missed, bound tighter than claimed).
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.
- 7d ago First seen · 33 lines · 95 tokens per session scan A dca66c945392
peer-reviewer is an agent published in the GitHub repository solanabr/auditor-skill (53 stars, last pushed 4d ago), licensed MIT. It adds 95 tokens to every session and 662 once invoked, about $0.0005 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-30.
Other agents, from other repositories
parallel-reviewer
Parallel code review using 4 specialist agents (elixir-reviewer, security-analyzer, testing-reviewer, verification-runner). Use for thorough review of significant changes.
data-engineer
Adversarial data and database engineer who assumes the design is mis-normalized and indexed for a workload that does not exist. Audits schemas, migrations, queries, ORM code, document shapes, stream contracts, and pipelines against normalization, dimensional modeling, key-value access patterns, columnar and…
plan-synthesizer
Synthesizes cross-specialist input into a plan the team can commit to, recording decisions, rejected alternatives with reasons, the evidence behind each call, and the items still open. Reads the inputs from every specialist who contributed, reconciles their recommendations, and applies an evidence standard to each …
edge-case-explorer
Systematically discovers and catalogs edge cases that should be covered by tests for a given piece of code. Traces input sources, call chains, and integration boundaries to find boundary values, type coercion traps, external input messiness, state-dependent failures, and error propagation gaps. Use when exploring how…
software-architect
Adversarial software architect who assumes the current intra-codebase structure is wrong: over-coupled where it should be independent, under-cohesive, missing an abstraction at a trust or infrastructure edge, or over-abstracted with single-implementation interfaces. Synthesizes structural, behavioral, concurrency, and…
mcp-reviewer
Review MCP server changes for tool safety, schema quality, and host integration correctness.