PRD - Product Requirements Document

The Product Requirements Document is the top of the tree for a single repo: what the product does and why. It is owned by Lena, the Product seat of the Three Amigos, and it is the richest input every later step reads - personas, epics, stories and the closing review all trace back to it.

It lives as plain Markdown at sdlc-studio/prd.md.

Three modes

create (greenfield)

An interactive conversation builds the PRD from scratch:

/sdlc-studio prd create

1. You are asked about the project name, purpose and target users.
2. You describe features one by one, with acceptance criteria.
3. You are asked about non-functional requirements - performance, security, scale.
4. The PRD is written to sdlc-studio/prd.md.

Best for new projects.

generate (brownfield)

SDLC Studio reads your existing code and reverse-engineers the requirements:

/sdlc-studio prd generate

1. An explore pass reads your routes, components, tests and config.
2. Features are extracted and their acceptance criteria inferred.
3. The PRD is written with confidence markers - [HIGH], [MEDIUM], [LOW] - so you can see what is certain and what is a guess.

Best for documenting a codebase that already exists. generate --force replaces an existing PRD.

review

Re-check the PRD against the current codebase and update each feature’s status:

/sdlc-studio prd review

Every feature is marked Complete, Partial, Stubbed, Broken or Not Started, and features found in the code but missing from the PRD are surfaced. This is how the document stays honest after a few sprints.

Caution

A generated PRD is an extraction, not a specification, until its acceptance criteria pass against the code. Treat [LOW]-confidence lines as questions to answer, not facts to trust.

What it captures

The PRD is a structured document, not a free-form brief. Its sections:

1. Project Overview
2. Problem Statement
3. Feature Inventory
4. Functional Requirements
5. Non-Functional Requirements
6. AI/ML Specifications (when applicable)
7. Data Architecture
8. Integration Map
9. Configuration Reference
10. Test Coverage Analysis
11. Technical Debt Register
12. Documentation Gaps
13. Recommendations
14. Open Questions

You do not have to fill every section for a small project - the point is that the shape is there, so nothing important is silently missing.

What you can do with it

• Grow your team from it. The PRD is the strongest input persona generate --team will ever have - it reads the PRD to propose a project-specific engineering team and a stakeholder panel.
• Decompose it into work. epic and story read the PRD to produce the delivery backlog, each story naming the persona it serves.
• Keep it true. prd review re-checks feature status against the code every few sprints, so the document tracks reality instead of drifting into fiction.

Where to next

• TRD - Technical Requirements - how the PRD’s what becomes a how (the TRD is gated on the PRD).
• Personas - the users the PRD’s features serve.
• The Three Amigos - how Lena, Dani and Sam each review the spec from their angle.
• The two-backlog model - how requirements become sized, planned work.