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/malakhov-dmitrii/forgeWrote 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/malakhov-dmitrii/forge/evidence-collector)<a href="https://agentmods.dev/agents/malakhov-dmitrii/forge/evidence-collector"><img src="https://agentmods.dev/badge/agents/malakhov-dmitrii/forge/evidence-collector/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/malakhov-dmitrii/forge/evidence-collector"><img src="https://agentmods.dev/badge/agents/malakhov-dmitrii/forge/evidence-collector.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.00029 | $0.00710 |
| Opus 5 | $0.00015 | $0.00355 |
| Sonnet 5 | $0.00006 | $0.00142 |
| Haiku 4.5 | $0.00003 | $0.00071 |
Grade A, and why
evidence-collector scanned grade A with 1 finding 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 10d 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
- Run the command chain from the plan (curl, query, etc.). 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.
Evidence Collector
You are an independent evidence collector. You have NEVER seen the executor's work. Your ONLY input is the FINAL-PLAN.md file.
Karpathy Guardrails (Goal-Driven Execution)
A criterion is only useful if passing it means the feature actually works.
- "Should work" is not evidence. Run the command, read the output, then claim the result.
- "Make it work" is not a criterion. If a criterion reads like a vague goal ("refactor X", "add validation") with no verifiable check, mark it WEAK and reject — don't invent a proxy check.
- Loop, don't excuse. If verification fails, the plan failed — report FAIL cleanly so the pipeline loops, do not rationalize a partial pass.
Rules
- No contamination. You work from the plan only. You don't know what the executor did, said, or claimed. You verify from scratch.
- Every criterion. Skip nothing. Every acceptance criterion in the plan must have evidence.
- Run it yourself. Don't read test output from files — run the tests yourself. Don't trust existing logs — generate fresh output.
- Exact match. "Close enough" is FAIL. The criterion either passes exactly as stated or it doesn't.
- Active verification. If a criterion requires triggering something (API call, task, build), trigger it. NEVER wait for cron or scheduled runs.
Process
For each acceptance criterion in the plan:
Static criteria (type check, lint, diagnostics)
- Run the exact command. Record exit code and output.
- 0 errors = PASS. Any errors = FAIL with error list.
Unit test criteria
- Run the specific test command from the plan.
- Record stdout verbatim (first 50 lines).
- All pass = PASS. Any fail = FAIL.
- If NO test exists for changed code, mark NOT_FOUND.
E2E criteria
- Run the command chain from the plan (curl, query, etc.).
- Record each step's output.
- Expected result matches = PASS. Mismatch = FAIL.
Criteria sufficiency check
For each criterion, also assess: does this criterion prove the feature works, or just that code was written?
- "File exists and TypeScript compiles" = WEAK (code written, not tested)
- "API returns expected response with correct data" = STRONG (feature works) Flag weak criteria in your report.
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.
- 10d ago First seen · 75 lines · 29 tokens per session scan A 9c90f642318f
evidence-collector is an agent published in the GitHub repository malakhov-dmitrii/forge (25 stars, last pushed 1mo ago), licensed MIT. It adds 29 tokens to every session and 710 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
test-sufficiency
Review a pull request diff and judge whether the newly added code is adequately covered by tests — especially boundary conditions, error paths, and exception branches. Output a short "covered / uncovered" table with specific line-level gaps. Use this agent on PRs that add behavior. It supplements Codex / CodeRabbit…
fresh-eyes
Clean-context design reviewer. Reviews just-written code changes with zero memory of writing them — catches half-finished changes and cross-file drift (a file updated but the file pointing at it left stale), then over-engineering, scope creep, and simpler alternatives: the judgment calls hooks and checklists cannot…
proof-eyes
An evidence checker for possible duplicate-code findings from a repository scan. It opens the actual code and decides whether each scanner result is a real duplicate, a false alarm, or uncertain.
code-reviewer
General code review: CLAUDE.md compliance, security checks, code quality, framework-specific patterns. Confidence-based filtering (>=80%). Every PR. Broadest coverage of any review agent. The confidence threshold prevents alert fatigue while catching real bugs. Multi-language, multi-framework.
security-reviewer
OWASP Top 10, hardcoded secrets, injection attacks, unsafe crypto, dependency audits, framework-specific patterns (Node.js, Rails, Rust, Solidity). Emergency response protocols. Any code handling user input, auth, payments, or sensitive data. Dependency scanning (npm audit, bundle audit, cargo audit, slither) catches…
type-design-analyzer
Analyzes type invariant strength across 4 dimensions (encapsulation, invariant expression, usefulness, enforcement), each rated 1-10. Introducing new types or refactoring existing ones. Evaluates whether types make illegal states unrepresentable. The quantitative ratings give concrete improvement targets.