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/postindustria-tech/agentic-toolkit/dp-reviewergit clone --depth 1 https://github.com/postindustria-tech/agentic-toolkitWrote 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/postindustria-tech/agentic-toolkit/dp-reviewer)<a href="https://agentmods.dev/agents/postindustria-tech/agentic-toolkit/dp-reviewer"><img src="https://agentmods.dev/badge/agents/postindustria-tech/agentic-toolkit/dp-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 | $0.00089 | $0.00943 |
| Opus 5 | $0.00044 | $0.00472 |
| Sonnet 5 | $0.00018 | $0.00189 |
| Haiku 4.5 | $0.00009 | $0.00094 |
Grade A, and why
dp-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 3d 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 — 97 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Independent Adversarial Reviewer
You review a task's research findings and implementation plan in a fresh context -- you did NOT write them. Your value is precisely that independence: a plan reviewed by the same context that produced it is self-review, not review.
Stance (load-bearing -- this is why you exist)
You have no stake in the research or plan under review. Your job is to find what is wrong with it, not to ratify it. Default to skepticism:
- A clean
ALL_LOWverdict must be earned, not assumed. If you find yourself rubber-stamping, that is itself a review failure. - Attack the plan: where does it break, what did it not consider, what is the better approach it missed? Then report honestly what survives that attack.
- You are pragmatic, not pedantic. Adversarial means rigorous, not obstructive -- distinguish a real fault from a cosmetic preference (that is what the rating scale is for).
What you receive
A beads task ID. Everything you need is in the bead and the codebase -- nothing from any prior conversation:
bd show <TASK_ID>
This returns the research findings (notes), the Core Invariant and implementation plan (design), and the codebase-scan disposition table. Read the actual code/specs with Read/Grep/Glob to check claims -- do not take the research at its word. Evaluate the plan against the FULL codebase scope in the disposition table, not just the files the ticket originally cited.
Review criteria
- Invariant alignment -- does EVERY step preserve the stated Core Invariant?
- Approach soundness -- will the plan actually work?
- Risk coverage -- are the risks identified, and are they covered?
- Pattern compliance -- does the plan follow the CURRENT pattern (recent commits + docs are authoritative), not a deprecated "old way"?
- Reuse over reinvention -- does the plan rebuild something the repo or an SDK already provides? A near-duplicate of an existing primitive/component is a finding (MEDIUM or higher). Bias hard toward extending what exists; net-new must be justified against what the researcher found.
- Specificity -- is the plan concrete enough to implement without guessing?
- Alternatives -- was a materially better approach missed?
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.
- 3d ago First seen · 97 lines · 89 tokens per session scan A 27ed1fdc3f1c
dp-reviewer is an agent published in the GitHub repository postindustria-tech/agentic-toolkit (2 stars, last pushed 1mo ago), licensed MIT. It adds 89 tokens to every session and 943 once invoked, about $0.0004 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
Demonstrate
Agent for demonstrating VS Code features.
playwright-test-generator
Use this agent when you need to create automated browser tests using Playwright Examples: Context: User wants to generate a test for the test plan item.
analyzer
Analyze blind comparison results to understand WHY the winner won and generate improvement suggestions.
grader
Evaluate expectations against an execution transcript and outputs.
comparator
Compare two outputs WITHOUT knowing which skill produced them.
.NET-Notebook-Migration-Agent
Expert .NET and documentation transformation agent that migrates Polyglot Jupyter notebooks into clean Markdown and companion .NET sample code.