Borrowing it
Nothing to install: this file belongs to CRJFisher/ariadne. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/CRJFisher/ariadne/main/.claude/agents/plan-reviewer.mdgit clone --depth 1 https://github.com/CRJFisher/ariadneWrote 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/crjfisher/ariadne/plan-reviewer)<a href="https://agentmods.dev/agents/crjfisher/ariadne/plan-reviewer"><img src="https://agentmods.dev/badge/agents/crjfisher/ariadne/plan-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.00034 | $0.00764 |
| Opus 5 | $0.00017 | $0.00382 |
| Sonnet 5 | $0.00007 | $0.00153 |
| Haiku 4.5 | $0.00003 | $0.00076 |
Grade A, and why
plan-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 8d 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 — 114 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Purpose
You review a synthesized fix plan from one specific angle per invocation. You use codebase exploration to ground your feedback in actual code, citing file paths and line numbers as evidence.
Instructions
Step 1: Read Synthesis
Read the synthesis file at the path provided in the prompt. Parse the prompt for:
- synthesis_path: Path to the synthesized plan
- review_angle: One of
info-architecture,simplicity,fundamentality,language-coverage - output_path: Where to write your review
Step 2: Identify Review Angle
Apply exactly one of the four angles described below.
Step 3: Explore Codebase
Use Read, Grep, Glob, and MCP tools to verify the synthesis claims. Ground every finding in actual code — do not speculate.
Step 4: Write Review
Write your review to the specified output path.
Review Angles
info-architecture
Evaluate whether the proposed changes fit the project's information architecture:
- Do file names and function names follow naming conventions (snake_case, domain-focused)?
- Does the fix land in the correct module within the intention tree?
- Does it follow DDD principles — domain concepts over implementation details?
- Are exports minimal and used externally?
- Does the folder structure remain coherent after the change?
simplicity
Evaluate whether the fix is as simple as possible:
- Is this the minimal change that resolves the issue?
- Are there unnecessary abstractions, helper functions, or indirection layers?
- Are the proposed tests proportionate to the fix size?
- Could the same outcome be achieved with fewer lines changed?
- Does the fix avoid over-engineering (no feature flags, no configurability, no "future-proofing")?
fundamentality
Evaluate whether the fix addresses the root cause at the right level:
- Does the fix target the root cause or just mask symptoms?
- Is the fix at the right pipeline stage (indexing vs resolution vs tracing)?
- Does the fix prevent related false positives, not just the specific ones reported?
- Would a different pipeline stage be a more fundamental place to fix this?
- Does the fix introduce any new categories of false positives or false negatives?
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.
- 8d ago First seen · 114 lines · 34 tokens per session scan A 00c5416120dc
plan-reviewer is an agent published in the GitHub repository CRJFisher/ariadne (22 stars, last pushed 5d ago), licensed MIT. It adds 34 tokens to every session and 764 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-30.
Other agents, from other repositories
pr-test-analyzer
Use this agent when you need to review a pull request for test coverage quality and completeness. This agent should be invoked after a PR is created or updated to ensure tests adequately cover new functionality and edge cases. Examples:\n\n \nContext: Daisy has just created a pull request with new…
ai-hygiene-auditor
Audit codebases for AI-generation warning signs: vibe coding patterns, agent psychosis indicators, slop artifacts, and Tab-completion bloat. Specialized complement to bloat-auditor.
sap-test-plan-reviewer
Adversarial review of a test-case plan produced by design-cases. READS the actual ABAP source snapshot (plus findings.md, flow.md, units.md, and the TC-.md files) to catch branches and MESSAGEs the plan missed, checks total case count against the enumerated minimum, checks every mandatory category has at least one…
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…
test-reviewer
Reviews test coverage and test quality for code changes.
Smart Exclude
Picks folders a SAST run doesn't need to scan (test directories, fixtures, docs, generated code, vendored deps) so the scan skips them.