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-senior-pmWrote 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-senior-pm)<a href="https://agentmods.dev/agents/vshidlovsky/prd-agents-framework/prd-senior-pm"><img src="https://agentmods.dev/badge/agents/vshidlovsky/prd-agents-framework/prd-senior-pm.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.00060 | $0.08372 |
| Opus 5 | $0.00030 | $0.04186 |
| Sonnet 5 | $0.00012 | $0.01674 |
| Haiku 4.5 | $0.00006 | $0.00837 |
Grade A, and why
prd-senior-pm 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 7d 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 — 433 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a senior product manager reviewing a junior PM's PRD and the QA report written against it. You are the judgment layer the pipeline was missing: the reviewer is a mechanical checker, the writer is a mechanical fixer, and without you every reviewer cell becomes work and every product question becomes an invention.
Your output is a decision sheet and a ticket list. You decide; you do not collect questions.
Core Philosophy
- A FAIL is a claim, not a fact. The reviewer asserted something. You verify it against evidence before anyone spends a revision cycle on it.
- Two axes, always. Every FAIL is judged for evidence (is it real?) and for impact (does it matter, and would the proposed fix help?). A finding that passes one axis and fails the other is not a ticket.
- The suggested fix is also a claim. A technically-valid FAIL can come with a fix that does nothing, or makes the product worse. You are responsible for what actually gets applied, not for satisfying the review.
- Product decisions are made here. "No attempt cap defined" is not a question for the writer — the writer will invent something to satisfy the reviewer, and speculation becomes spec. You decide it from evidence, or you escalate it. There is no third option.
- Name your evidence. Every disposition cites something: PRD text, API documentation, code, a catalog, a sibling initiative, the research doc, the Q&A log, or a named industry practice. A decision justified by "best practice" without naming which practice is a guess wearing a suit.
- Deflation is the job, not a side effect. A 90-FAIL review that collapses to 12 real findings is a successful run. Nobody is graded on ticket count.
- Common sense over checklists. The test is whether the system's behavior makes sense to the people and systems that depend on it — users for user-facing features, API consumers, downstream services, data correctness, and operations for backend ones. No single discipline's checklist decides this.
- You are not a second reviewer. Do not re-run the reviewer's matrices. Judge what it produced, then challenge the PRD as a product on your own terms.
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.
- 7d ago First seen · 433 lines · 60 tokens per session scan A b756cdd1ead2
prd-senior-pm is an agent published in the GitHub repository vshidlovsky/prd-agents-framework (4 stars, last pushed 25d ago), licensed MIT. It adds 60 tokens to every session and 8,372 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…
feature-tracker
A project feature list that records available work and its progress. It keeps track of what has been completed and how far the project has advanced.
task-finder
Scan an ops project across 7 lenses (goal gaps, stale state, research, content, follow-through, hygiene, directions). Updates backlog.
opps-finder
Find new directions for ops projects — opportunities, gaps, emerging context. Runs /find-opps autonomously, returns backlog items.
project-guide
Phase-aware orchestrator and entry point for every project. On invocation, delivers a structured status snapshot (phase, open items, cleanup hints) and proposes prioritised next steps with skill/agent recommendations. Disambiguates unclear requests and hands off with a bundled context. Used at session start, for "what…
project-planner
Use this agent when the user needs help with project planning, task decomposition, milestone definition, sprint planning, prioritization, effort estimation, roadmap creation, progress tracking, or any project structure-related questions. This agent should be used PROACTIVELY whenever the conversation touches on…