Requirement to PRD

A self-contained shortcut: raw requirements in, a saved PRD.md out. Unlike the two-stage requirement-analyzer → prd-generator path, this skill does the analysis inline and its headline deliverable is a written file on disk, not chat text. Reach for it when someone says "here are the notes, give me a PRD file."

Instructions

Step 1: Read the input as-is

Take whatever the user provides — notes, a document path, a transcript, or pasted text. Do not ask them to reformat it. If several sources are given, merge them. If they give a file path, read that file.

Step 2: Analyze the requirements (in your head, then on paper)

Extract the structured brief before writing any PRD prose. Pull out:

• Project name and client — literal names if stated; otherwise propose a short working name and add "confirm project name" to Open Questions.
• Objective — one outcome-focused sentence.
• Goals — measurable where the input supports it.
• Stakeholders — decision maker, budget holder, end users, integration owners.
• Functional requirements — one capability per line, verb-first.
• Non-functional requirements — the frequently-missed ones. Scan deliberately against the checklist in references/analysis-guide.md (performance, security, compliance, availability, scalability, usability/offline, localization, data restrictions).
• Constraints — deadline, budget, mandated stack, integrations, data restrictions.
• Assumptions — anything you inferred; keep it visible.
• Open questions — specific, answerable gaps.

Apply the signal test: if removing a line does not change what gets built, drop it. "The client seemed excited" is not a requirement.

Step 3: Write the Project Vision

One paragraph naming who the product is for, the core value, and the outcome that defines success. This is the anchor for every scope decision below.

Step 4: Fill the PRD template

Use the exact structure in assets/prd-template.md. Fill every section from the brief in Step 2. Where the input is genuinely silent, write "To be confirmed" and add the item to Open Questions rather than inventing detail. Give every functional requirement a stable ID (FR-01) and a MoSCoW priority; give every non-functional requirement an ID (NFR-01).

Step 5: Make scope explicit

Populate Out of Scope deliberately — an empty Out of Scope is a red flag, not a convenience. State plainly what this release will not include; that is what prevents scope creep later.

Step 6: Run the quality gate

Check the draft against references/prd-quality-checklist.md. Every functional requirement must trace to a goal or requirement in the input (no orphan features), and nothing from the input may be silently dropped — anything cut appears in Out of Scope with a reason. Fix failures before writing the file.

Step 7: Write the PRD file

Save the finished PRD as a Markdown file — this step is the point of the skill; do not stop at chat text.

• Filename: slugify the project name → <project-slug>-prd.md (e.g. cod-reconciliation-prd.md). If the user named a path or filename, use theirs.
• Location: the current working directory unless the user specified one.
• After writing, confirm the saved path to the user and give a two-line summary (functional-requirement count, open-question count).

Output structure

The written file ALWAYS follows this order (full template in assets/prd-template.md):

# [Project Name] — Product Requirements Document
## Project Vision
## Objectives and Success Metrics
## Personas
## Scope (In Scope)
## Out of Scope
## Functional Requirements
## Non-Functional Requirements
## Dependencies and Integrations
## Risks
## Open Questions

Example

Input: messy last-mile-delivery discovery notes (rider app + merchant portal, COD reconciliation pain, offline-tolerant, cheap Android, "launch before Eid", no real customer data for testing).

Output: a saved cod-reconciliation-prd.md whose Vision reads —

"For a last-mile delivery operator whose finance team loses half a week reconciling cash-on-delivery collections by hand, this platform automates COD reconciliation and merchant settlement: riders record collected cash on a resilient mobile app and merchants track parcel status and settlement timing in a portal, so merchants are paid accurately in days sooner and disputes fall."

Out of Scope explicitly excludes in-app customer payments and a public consumer app for this release; Open Questions capture the undecided Eid deadline and the bKash-vs-bank settlement choice.

Troubleshooting

• PRD is vague. The input brief was thin. Do not pad — surface the gaps as Open Questions and tell the user what to confirm.
• PRD invents features nobody asked for. Cut anything not traceable to a goal or requirement in the input. Every PRD line traces back to the requirement that justifies it.
• User wanted the file somewhere specific. If they named a path or filename, honor it; otherwise default to <project-slug>-prd.md in the working directory and tell them where it landed.