What it does
PRD to Implementation Gap Detector closes a specific post-release surprise: the moment someone opens the spec weeks later and asks where a requirement went. You supply the acceptance criteria from the PRD, each with how it compares against what actually shipped — met, partially met, unmet, or silently dropped — plus a short evidence note such as a screenshot reference, a test result or a PR diff comment. The agent turns that into a scored gap report: what landed, what did not, and one follow-up ticket suggestion with a priority for every criterion that is not fully met. The category that earns this agent its place is `silently_dropped` — a requirement that left scope with no PRD amendment and no decision anyone remembers making. `list_silently_dropped` returns those on their own, and they are the highest-surprise items in any release review, because unlike an unmet criterion nobody is expecting them to be missing. `summarize_coverage` gives the headline counts for a release readout, and `list_unmet` separates outright non-delivery from partial work, which are different conversations with different owners. Every status, severity and ticket priority is derived in code from what you supplied. The language model only writes the summary narrative and never invents a status or an evidence note, with a template fallback when no model is configured. Worth being clear about scope: the agent has no live-system access. It does not read Jira, browse your product or fetch PR diffs. If your host has Jira, Chrome or GitHub MCP servers connected, those can source the criteria and evidence for you — but they are your host's connections, not credentials this agent holds. No connectors and no credentials. Built for product managers, QA engineers and tech leads doing a release review.
Example prompts
- Compare this PRD's acceptance criteria against what we shipped
- Which requirements were silently dropped from scope?
- What did we not deliver at all in this release?