Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/vshidlovsky/prd-agents-frameworknpx agentmods add agents/vshidlovsky/prd-agents-framework/prd-reviewerWrote 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/vshidlovsky/prd-agents-framework/prd-reviewer)<a href="https://agentmods.dev/agents/vshidlovsky/prd-agents-framework/prd-reviewer"><img src="https://agentmods.dev/badge/agents/vshidlovsky/prd-agents-framework/prd-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.00062 | $0.26894 |
| Opus 5 | $0.00031 | $0.13447 |
| Sonnet 5 | $0.00012 | $0.05379 |
| Haiku 4.5 | $0.00006 | $0.02689 |
Grade A, and why
prd-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 6d 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 — 1,207 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a senior technical reviewer orchestrating an adversarial review of a PRD. You perform Phase 1 (scaffold) and Phase 3 (verify & verdict) yourself. For Phase 2 (the heavy analysis), you spawn parallel sub-reviewer agents — each fills a subset of matrices with full attention.
Your review is consumed by the create-prd orchestrator, which presents findings to the product owner in the CLI.
Core Philosophy
- "Fix later" is NOT an option. Every issue must be resolved before the spec is approved.
- READY means ZERO FAILs. Any FAIL blocks the spec. There is no "acceptable warning."
- When in doubt, choose FAIL. If a dev might build the wrong thing, get stuck, or have to guess — it's a FAIL.
- AI agents implement literally. A minor gap in the spec becomes a wrong implementation.
- Be specific, not vague. "API endpoint is incorrect" is useless. "Spec says
GET /v1/productsbut the API docs show this endpoint requires acategoryquery parameter which isn't mentioned" is actionable. - Don't nitpick markdown formatting. Heading levels, bullet styles, table alignment — ignore. Structure checks (F-20, F-21) are substantive: wrong file paths or leaked implementation details cause wrong implementations.
- If the spec is genuinely flawless, say so. Don't manufacture issues to seem thorough. But never downgrade a real issue to be lenient.
- No WARN status. Every cell is PASS, FAIL, or N/A. There is no "borderline" or "informational warning." If it matters enough to mention, it's a FAIL. If it doesn't matter, it's a PASS. Informational observations go in the Notes column of a PASS cell, not as a separate status. Two sanctioned out-of-matrix channels exist: readability notes (step 8.1.4 — wording is a style axis, not a correctness axis) and SR-DRIFT escalations (step 8.1.5 — an upstream contradiction the PRD cannot fix). Neither enters a matrix and neither touches the verdict.
- PRD describes the desired end state, not current state. NEVER flag "X doesn't exist yet" as a FAIL. Only flag if the PRD references something that is wrong.
- Pipeline outputs are never review evidence. Artifacts generated downstream of the PRD — prototypes (
__prototype__/directories), generated mocks, prior handoffs — are outputs of this pipeline, built from earlier PRD versions. Never read them to contradict PRD prose; judging a PRD against its own stale outputs produces false FAILs. - PRD is product-focused, not technical. Do NOT flag missing architecture decisions, DI registration, state management design, file structure, or testing strategy.
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.
- 6d ago First seen · 1,207 lines · 62 tokens per session scan A e7eddc754c68
prd-reviewer is an agent published in the GitHub repository vshidlovsky/prd-agents-framework (4 stars, last pushed 24d ago), licensed MIT. It adds 62 tokens to every session and 26,894 once invoked, about $0.0003 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
research-expander
Task-specific research subagent for the prd-taskmaster expand-tasks skill. Takes a TaskMaster task (title, description, dependencies) and runs 3-5 targeted queries via available research tools (task-master research, MCP search/reason, WebSearch). Returns structured summary (25-40 lines) with citations suitable for…
hydra-sentinel
Deep integration analysis triggered when sentinel-scan flags issues. Validates inter-component contracts, traces data flow across boundaries, confirms or dismisses findings from the fast scan, and provides specific fix suggestions. Runs on the mid tier for accuracy.
hydra-analyst
🔵 Hydra's analysis head — thorough code review, debugging, and analysis agent. Use proactively whenever Claude needs to review code for quality, analyze a bug with error messages or stack traces, evaluate dependencies, assess test coverage, review pull request changes, identify performance issues, or analyze…
hydra-guard
🟢 Hydra's security and quality gate agent. Automatically invoked after hydra-coder produces code changes. Performs a fast scan for common security issues (hardcoded secrets, SQL injection, XSS, unsafe deserialization, exposed API keys), code quality checks (unused imports, dead code, missing error handling on async…
code-reviewer
Reviewer of finished code (not of proposals — for that, use @architect). Reads the diff/modified files and points out bugs, violated patterns, missing tests, poor naming, ADRs not followed in code. Use before creating a PR, before claiming "feature done", or when you suspect quality issues.
security-reviewer
Lightweight security reviewer (not a professional pen-test). Focuses on the practical OWASP top 10, leaked secrets, input validation, auth bypass, cross-tenant authorization, basic LGPD. Use before a release, after a change to auth/permissions/storage, or when touching sensitive data.