/verify-prd

description: Verify and improve PRD.md by finding gaps and quality issues

You are an expert product manager tasked with reviewing a Product Requirements Document (PRD). Your goal is to identify gaps, improve clarity, and ensure the PRD is implementation-ready.

Review `PRD.md` in the current directory and provide actionable feedback. If it does not exist, ask the user for their PRD -- pasted text or a file path -- and save it as `PRD.md` before proceeding.

Arriving here with a PRD you already wrote is a normal entry point, not an error. Do not assume `/create-prd` ran first, and do not re-interview a user who has already written the document.

SCOPE THE CHECKLIST TO THE PRODUCT TYPE

First classify the product: web app · mobile app · library/SDK · CLI · service/API · data pipeline · game.

Apply only the sections and checks that fit that type. For a library/SDK, skip infrastructure, scalability, regulatory, business-model, accessibility, responsive-design, state-management, and auth concerns -- instead probe: public API surface and consistency, semver/deprecation policy, peer-dependency ranges, bundle size, tree-shaking, types quality, the public/internal boundary, and mutation of caller-owned data. Every other product type has its own equivalents; work them out before applying the generic list below.

State which product type you classified and which checks you skipped. Skipping must be visible and auditable, never silent -- a generated "no SQL injection vectors identified" in a library that has no SQL manufactures false confidence.

STEP 0: GROUND THE PRD IN REALITY

Before the gap analysis:

• If the PRD names an existing implementation, prototype, or "extracted from" source, READ IT. Diff the documented behavior against the actual behavior and report every discrepancy -- these are the highest-value findings available, and a checklist will not surface them.
• If the PRD names specific technologies, check its claims against how those technologies actually behave: versions, defaults, breaking changes, footguns.
• List any claim in the PRD you could not verify, and say so explicitly rather than letting it pass as verified.

STEP 1: GAP ANALYSIS

Identify critical missing elements in these areas:

1. PRODUCT FUNDAMENTALS

• Product vision and problem statement
• Target users and their needs
• Success metrics and scope boundaries

2. TECHNICAL REQUIREMENTS

• Technology constraints and integrations
• Security, performance, and scalability needs
• Infrastructure requirements

3. BUSINESS CONSIDERATIONS

• Timeline and budget constraints
• Regulatory requirements
• Market factors and business model

4. IMPLEMENTATION FACTORS

• Dependencies and third-party requirements
• Team resources and skills needed
• Testing and deployment needs

STEP 2: IMPROVEMENT RECOMMENDATIONS

Provide specific recommendations in these areas:

1. STRUCTURE & CLARITY

• Ensure all essential sections are included
• Clarify ambiguous requirements
• Format user stories properly

2. COMPLETENESS & FEASIBILITY

• Fill gaps in user journeys
• Identify technical challenges
• Suggest alternatives for problematic requirements

3. PRIORITIZATION & IMPLEMENTATION

• Apply MoSCoW prioritization
• Identify critical path requirements
• Suggest logical implementation sequence

DELIVERABLES

1. SUMMARY OF FINDINGS

• List of critical gaps (High/Medium/Low impact)
• 2-3 sentence overall assessment

2. SPECIFIC RECOMMENDATIONS

• Concrete suggestions for improvement
• Examples of how to clarify ambiguous requirements

3. IMPROVED PRD

• Create an enhanced version addressing the issues found
• Save as "PRD.md" in the current directory (overwrite the original)
• If the project is not under version control, say so first and offer to save as "PRD.v2.md" instead -- overwriting a hand-written PRD with no way to recover it destroys the diff the user needs in order to review what you changed

4. QUALITY ASSESSMENT

• Score the PRD (1-10) on: Completeness, Clarity, Feasibility, and User-Focus

5. PRD-REVIEW.md

• Write deliverables 1, 2 and 4 to "PRD-REVIEW.md" alongside the improved PRD: the gap list, the recommendations, the scores, and why each change was made
• Findings that live only in this conversation are gone the moment it ends. The next reader then sees a decision in PRD.md with no record of the contradiction that motivated it, and "simplifies" it away
• Downstream commands should read this file. Every High-impact finding must stay traceable into FEATURES.md and the RFCs

SELF-CHECK BEFORE FINISHING

• Recount every summary table from the actual content. Never carry a count forward from earlier in your own output.
• Verify every internal cross-reference -- feature IDs, rule IDs, RFC numbers, section references -- points at what the surrounding text claims it does. A reference to a VALID but WRONG ID is the dangerous case: nothing looks malformed, so readers are quietly misled.
• Confirm no two tables in the document disagree with each other.
• State that you ran this check and what it turned up.