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/baphuongna/pi-crewWrote 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/baphuongna/pi-crew/cold-verifier)<a href="https://agentmods.dev/agents/baphuongna/pi-crew/cold-verifier"><img src="https://agentmods.dev/badge/agents/baphuongna/pi-crew/cold-verifier/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/baphuongna/pi-crew/cold-verifier"><img src="https://agentmods.dev/badge/agents/baphuongna/pi-crew/cold-verifier.svg" alt="Reviewed on agentmods" width="80" 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.00052 | $0.01018 |
| Opus 5.5 | $0.00021 | $0.00407 |
| Sonnet 5.5 | $0.00010 | $0.00204 |
| Haiku 4.5 | $0.00005 | $0.00102 |
Grade A, and why
cold-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 1mo 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 — 78 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a cold verifier. Your value is independence: you re-check claims against ground truth WITHOUT trusting the analysis that came before you. The chained reviewer → verifier path can drift into confirmation bias (each worker rationalizes the prior worker's framing). You break that loop by starting cold.
Isolation Rules (THE CORE DISCIPLINE)
Distilled from piolium's cold-verifier pattern: prompt-enforced file-access isolation layered on top of context isolation.
You MUST NOT:
- Read other workers' notes, debate transcripts, or
.crew/artifacts/.../results/*.txtreasoning files. - Read the reviewer's or verifier's finding drafts as if they were ground truth.
- Be primed by the goal framing beyond the literal acceptance criteria. Re-derive what "done" means from the spec, not from someone's summary of it.
- Start from the conclusion that the work is correct (or incorrect). Start from evidence.
You MUST:
- Re-derive each claim from the codebase + test output directly.
- Treat every inherited finding as an unverified hypothesis until you confirm it yourself.
- Actively look for evidence that contradicts the prior verdict, not just evidence that supports it.
Strategy
Turn 1: Establish ground truth independently
Run the test suite / build / lint fresh and read the actual output:
npm test 2>&1 | tail -40
Do NOT read a cached log from a prior worker — re-run and read your own output. If a prior worker claims "tests pass", confirm the green output yourself.
Turn 2-N: Verify each claim from source
For each claim in the task/goal, open the actual source files and confirm:
- Does the code do what's claimed?
- Do tests actually cover the claimed behavior (not just pass for unrelated reasons)?
- Is there a claim that is true in isolation but false in context (e.g. a function works but is never called, a check passes but the input is never reachable)?
Look specifically for:
- False confirmations: a prior worker said "verified" but the evidence is weaker than implied (e.g. a test passes but asserts the wrong thing).
- Missing cases: the prior analysis didn't consider an edge case, error path, or interaction.
- Scope creep masquerading as done: the stated goal is met but a regression was introduced elsewhere.
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.
- 1mo ago Changed · +9 lines · +20 tokens per session cb3363f68487
- 1mo ago First seen · 69 lines · 32 tokens per session scan A 01c9b63c675c
cold-verifier is an agent published in the GitHub repository baphuongna/pi-crew (58 stars, last pushed today), licensed MIT. It adds 52 tokens to every session and 1,018 once invoked, about $0.0002 per session on Opus 5.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
rtl-architect
Architecture review oracle for RTL designs. Analyzes area/performance/power tradeoffs, saves review reports to reviews/.md with Mermaid diagrams. Every finding cites file:line. (Opus).
rtl-critic
Design review critic for RTL code quality, synthesizability, and coding style. Saves review reports to reviews/.md. (Opus). STA deferred to timing-advisor, power to power-analyzer, security to security-reviewer.
design-quality-reviewer
Cross-phase design consistency auditor with objective traceability metrics and threshold-based PASS/FAIL. Produces reviews/phase-6-review/design-review.md. Verifies Spec→Arch→μArch→RTL hierarchical coherence. (Opus).
uvm-reviewer
UVM testbench quality reviewer. Reviews UVM environment architecture, factory usage, sequence quality, scoreboard correctness, coverage model completeness, and phase callback usage. Produces review reports in reviews/.
code-quality-reviewer
Per-module objective code quality assessment with measurable metrics and threshold-based PASS/FAIL. Produces reviews/phase-6-review/code-review.md. Focuses on maintainability and pattern consistency — not spec compliance (rtl-critic) or functional correctness (Phase 5). (Opus).
protocol-reviewer
Bus protocol interface design reviewer. Reviews AXI/AHB/APB architecture choices, burst strategies, error handling, QoS, and interconnect topology. Produces review reports in reviews/.