Generate Product Requirements Documents from `idea.md` and `validate.md` files. Use when asked to create or update a PRD. Don't use for TAD, sprint tasks, or raw idea validation.
Instalaciรณn
Instalar con Codex o Claude Copia este prompt, pรฉgalo en Codex, Claude u otro asistente, y deja que revise la pรกgina de la skill y la instale por ti.
Generate Product Requirements Documents from `idea.md` and `validate.md` files. Use when asked to create or update a PRD. Don't use for TAD, sprint tasks, or raw idea validation.
If still unavailable, ask the user to provide the path or set IDEAS_ROOT.
If multiple candidates are plausible, ask user to choose.
Workflow
Mode selection (decide before Phase 1): If PROJECT_DIR/prd.md already exists and the user wants changes to it, this is a modify run โ do Phase 1's steps 1-4 (including the mandatory backup), then skip to ## Modification Mode below instead of Phases 2-5. Otherwise this is a create run โ proceed through Phases 1-5 in order. Both modes share Phase 1's backup step; see ## Modification Mode for modify-run detail.
Phase 1: Validate Input
Resolve PROJECT_DIR (from $ARGUMENTS or auto-pick mode above)
Check PROJECT_DIR/idea.md exists
Check PROJECT_DIR/validate.md exists
If PROJECT_DIR/prd.md exists, create backup: prd.backup.YYYYMMDD_HHMMSS.md
Adapt the check names to match what the step actually validates. Use โ for pass, ร for fail, and โ to add brief context. The "Criteria" line summarizes how many acceptance criteria were met. The "Result" line gives the overall verdict.
Entered per the Mode selection note above, once Phase 1's backup (prd.backup.YYYYMMDD_HHMMSS.md) already exists:
Ask what to modify (features, priorities, timeline, specs, personas)
Apply changes preserving structure
Update revision history
Guidelines
Thorough: Cover all sections comprehensively
Realistic: Base on validate.md feasibility ratings
Specific: Include concrete metrics and criteria
Actionable: Every section guides implementation
Visual: Include mermaid diagrams for architecture and flows
Acceptance Criteria
A run is considered successful only when every item below is verifiable in the produced prd.md. Use these as a checklist; reject and regenerate the section if any check fails.
prd.md is written to PROJECT_DIR (same folder as idea.md).
File contains all 10 top-level sections (verify with grep -c '^## ' returns >= 10): Product Overview, User Personas, Feature Requirements, User Flows, Non-Functional Requirements, Technical Specifications, Analytics & Monitoring, Release Planning, Open Questions & Risks, Appendix.
Product Overview cites the source idea.md (explicit phrase like "Source: idea.md" or quoted concept text from idea.md).
Success Metrics subsection lists at least 3 metrics, each with a measurable target (number + unit + timeframe, e.g. "DAU >= 1000 within 90 days post-launch").
User Personas section contains 2-3 persona blocks; each persona has Name, Role, Goals, Pain Points, and a representative quote.
Feature Requirements use MoSCoW labels (Must, Should, Could, Won't) and at least 5 items total.
Each Must/Should feature has at least one acceptance criterion in Given <context> / When <action> / Then <outcome> format (verify with grep -E "Given .* When .* Then").
User Flows section contains at least one fenced ```mermaid block with valid flowchart or sequenceDiagram syntax.
Non-Functional Requirements lists numeric targets for performance (e.g. p95 latency, throughput) and at least one security/privacy requirement.
Open Questions & Risks lists at least 3 risks, each with likelihood, impact, and mitigation.
Appendix.Revision History records this generation event with date and "v1.0 โ initial PRD".
If a previous prd.md existed, a prd.backup.YYYYMMDD_HHMMSS.md sibling file was written before overwrite.
Step Completion Reports are emitted for phases 1-5 with Result: PASS (or explicit PARTIAL/FAIL with reason).
Always verify the checklist explicitly in the final completion report (echo each item with โ or ร).
Expected Output
The generated prd.md follows a fixed 10-section skeleton (Product Overview, Personas, Feature Requirements, User Flows, NFRs, Tech Specs, Analytics, Release Planning, Risks, Appendix) with a header citing Source: idea.md, validate.md and a final console summary line. See references/expected-output.md for the full skeleton and console summary template.
Edge Cases
Handle missing inputs, verdict=REJECT, conflicting requirements, existing PRDs (always backup), unclear tech/compliance context, and Mermaid validation failures. See references/edge-cases.md for the full list and required behaviour.
Verification Steps
Run the grep-backed thresholds listed under ## Acceptance Criteria above (heading count, mermaid block, Given/When/Then, MoSCoW count, idea.md citation, backup sibling). See references/verification-steps.md for the exact shell commands to run each check.
