# PRD Generation Prompt
Create a PRD that frames the problem, product scope, priorities, and success
criteria clearly enough that downstream feature specs, designs, tests, and
implementation work can trace back to it.
Storage Location
    
Store at: docs/helix/01-frame/prd.md
Purpose
    
The PRD is the product-scope authority for what to build and why. Its
unique job is to translate the Product Vision into prioritized, measurable
requirements and boundaries. It sits between the product vision (which defines
direction) and feature specs (which define feature-level detail). Every design
decision and implementation choice should trace back to a PRD requirement.
Reference Anchors
    
Use these local resource summaries as grounding:

docs/resources/atlassian-prd.md frames a PRD as shared understanding of purpose, behavior, user needs, assumptions, out-of-scope items, and success criteria.
docs/resources/aha-prd-template.md supports concise cross-functional scope: what is being built, who it is for, and how it delivers value.
docs/resources/ibm-requirements-management.md grounds measurable, prioritized, traceable requirements and validation/verification discipline.

Key Principles
    

Problem first — the problem section should make someone feel the pain
before they see the solution.
Decision-oriented — every section should help someone make a build/skip
decision. If a section doesn't inform a decision, it's filler.
Testable requirements — every P0 requirement should be verifiable. If
you can't describe how to test it, it's too vague.
Traceable boundaries — requirements should connect upward to the Product
Vision and downward to feature specs, designs, tests, and build work.
Honest non-goals — non-goals should exclude things someone might
reasonably expect to be in scope. "Not a replacement for X" only matters if
someone might assume it is.

Stay in Your Lane
    
Product requirements are for product scope. If you find yourself writing about:

  

      

          
This content
          
Belongs in
      
  
  

      

          
Market sizing, ROI, investment case
          
00-discover/business-case.md
      
      

          
Positioning, target market, long-horizon strategic success
          
00-discover/product-vision.md
      
      

          
Detailed feature behavior and edge cases
          
01-frame/features/FEAT-*.md
      
      

          
User journey phrasing independent of product-level requirements
          
01-frame/user-stories.md
      
      

          
Architecture choices or implementation approach
          
02-design/
      
      

          
Detailed test cases and fixtures
          
03-test/
      
      

          
Build sequencing and execution slices
          
04-build/implementation-plan.md
      
  

Section-by-Section Guidance
    
Summary
    
Write this last. This section must work as a standalone 1-pager: what
we're building, who uses it, the problem, the solution approach, and the top
2-3 success metrics. Someone who reads only this section should understand the
product well enough to decide whether to invest time in the full PRD. Test:
could a new team member read this alone and explain the product to someone
else?
Problem
    
Describe the failure mode, not the absence of your solution. "Users don't have
a X" is weak. "Users spend N hours/week doing Y manually because Z doesn't
exist, leading to W failures" is strong. Quantify where possible.
Goals
    
Each goal should describe a state change, not an activity. "Build a dashboard"
is an activity. "Operators can see system health without SSH" is a state
change.
Success Metrics
    
Every metric needs three things: what you're measuring, a numeric target, and
how you'll measure it. "User satisfaction" is not a metric. "NPS > 40 from
monthly survey of active users" is. Drop the Timeline column — success metrics
should define what success looks like, not when it happens.
Non-Goals
    
Each non-goal should prevent scope creep on something plausible. "Not a
general-purpose AI" is only useful if someone might think it is. Test: would
someone on the team argue for including this? If not, it's not a useful
non-goal.
Personas
    
Name them. Give them a role, goals, and pain points specific enough to
validate with a real person. "Alex the Developer" with generic goals is a
template, not a persona.
Requirements (P0/P1/P2)
    
P0 = the product is broken without this. P1 = the product is weak without
this. P2 = the product is better with this. If you have more than 7 P0s,
you're not prioritizing.
Each requirement should be stable enough to trace into feature specs and tests.
If a requirement describes a screen, algorithm, API field, or implementation
sequence in detail, move that detail downstream and keep the PRD at product
scope.
Functional Requirements
    
These are the detailed behavioral specs. Each one should be testable — someone
reading it should know how to write an acceptance test. Organize by subsystem
or user flow, not by priority.
Acceptance Test Sketches
    
For each P0 requirement, write a concrete scenario: what the user does, what
input they provide, and what observable result they see. These aren't full test
cases — they're the minimum an implementer (human or agent) needs to verify
the requirement is met. An AI agent should be able to read a sketch and write
a passing test without asking clarifying questions.
Technical Context
    
Name the stack, key dependencies with versions, API schemas, and platform
targets. Be specific enough that an implementer knows what to install and what
interfaces to code against. "React" is not enough — "React 18 with TypeScript
5.x and Vite 6" is. If there's an API schema (OpenAPI, GraphQL SDL), point to
it. This section exists because AI agents need concrete dependency and
interface information to produce correct implementations.
Important: This section records stack decisions — it does not make them.
Stack selection rationale belongs in ADRs (Architecture Decision Records). If
you're documenting a choice that doesn't have an ADR yet, note it in Open
Questions. If an existing ADR contradicts what you'd write here, the ADR
governs until it's superseded.
Constraints
    
Name real constraints, not aspirational ones. "Must work on mobile" is a
constraint only if you'd otherwise skip it. Budget, compliance, and platform
constraints matter most.
Assumptions
    
These are bets. When an assumption is wrong, the plan breaks. Name each one
so the team knows what to watch.
Risks
    
Each risk needs a concrete mitigation, not "monitor closely." If the
mitigation is monitoring, say what you'll monitor and what triggers action.
Open Questions
    
List unresolved items explicitly rather than leaving [TBD] markers
scattered through the document. Each question should name who can answer it
and what's blocked by it. This section is honest about what you don't know
yet — it's better to have a clear list of unknowns than a document that
pretends to be complete.
Success Criteria
    
These are the acceptance criteria for the entire initiative. They should be
observable outcomes ("operators can do X without Y") not activities ("we
shipped Z").
Quality Checklist
    
After drafting, verify every item. If any blocking check fails, revise before
committing.
Blocking
    

 Problem section quantifies the pain or names a specific failure mode
 Every P0 requirement is testable (someone could write an acceptance test)
 Every P0 has an acceptance test sketch with inputs and expected outputs
 Success metrics have numeric targets and named measurement methods
 Requirements trace upward to the Product Vision and downward to downstream artifacts
 No [TBD], [TODO], or [NEEDS CLARIFICATION] markers in any section except Open Questions
 Non-goals exclude something a reasonable person might assume is in scope
 Personas are specific enough to validate with a real user

Warning
    

 Summary works as a standalone 1-pager (problem, solution, metrics)
 Goals describe state changes, not activities
 Risk mitigations are concrete actions, not "monitor"
 P0 requirements number 7 or fewer
 Assumptions are falsifiable
 Functional requirements are organized by subsystem or flow, not priority
 Technical Context names specific versions, not just library names
 Open Questions name who can answer and what's blocked

---
ddx:
  id: prd
---
Product Requirements Document
Summary
    
[This section should work as a standalone 1-pager. Include: what we're
building, who uses it, what problem it solves, the solution approach, and the
top 2-3 success metrics. Write this last — it should be a distillation of the
full PRD, not an introduction. Someone who reads only this section should
understand the product well enough to decide whether to read the rest.]
Problem and Goals
    
Problem
    
[What is broken or missing? Who is affected? Be specific about the failure
mode — not "users struggle with X" but "users spend N hours per week doing X
because Y doesn't exist."]
Goals
    

[Primary goal — what changes for users]
[Secondary goal]

Success Metrics
    

  

      

          
Metric
          
Target
          
Measurement Method
      
  
  

      

          
[Metric]
          
[Numeric target]
          
[Named tool or process]
      
  

Non-Goals
    
[What we are explicitly not trying to achieve. Each non-goal should exclude
something a reasonable person might assume is in scope.]
Deferred items tracked in docs/helix/parking-lot.md.
Users and Scope
    
Primary Persona: [Name]
    
Role: [Job title/function]
Goals: [What they want to achieve]
Pain Points: [Current frustrations — specific enough to validate]
Secondary Persona: [Name]
    
[Same structure]
Requirements
    
Each requirement should trace to the Product Vision and be specific enough to
drive feature specs, designs, tests, and implementation work without embedding
the detailed design here.
Must Have (P0)
    

[Core capability — what must be true for the product to be usable]

Should Have (P1)
    

[Important feature — valuable but not blocking launch]

Nice to Have (P2)
    

[Enhancement — improves experience but can be deferred]

Functional Requirements
    
[Detailed behavioral requirements organized by subsystem or user flow. Each
requirement should be testable — someone reading it should know how to verify
whether it's satisfied.]
Acceptance Test Sketches
    
[For each P0 requirement, describe a concrete scenario with inputs and
expected outputs. These aren't full test cases — they're the minimum needed
for an implementer (human or agent) to verify the requirement is met.]

  

      

          
Requirement
          
Scenario
          
Input
          
Expected Output
      
  
  

      

          
[P0 requirement]
          
[What the user does]
          
[Specific input or state]
          
[Observable result]
      
  

Technical Context
    
[Stack, key dependencies with versions, API schemas, and platform targets.
Be specific enough that an implementer knows what to install and what
interfaces to code against. This section records current stack decisions — it
does not make them. Stack selection rationale belongs in ADRs. If a choice
here isn't backed by an ADR yet, note it in Open Questions.]

Language/Runtime: [e.g., TypeScript 5.x, Node 20+]
Key Libraries: [e.g., React 18, Tailwind CSS 4]
Data/Storage: [e.g., PostgreSQL 16, Redis 7]
APIs: [e.g., OpenAPI spec at docs/api/v2.yaml]
Platform Targets: [e.g., Linux, macOS; browser: Chrome/Firefox/Safari latest]

Constraints, Assumptions, Dependencies
    
Constraints
    

Technical: [Platform or technology limits]
Business: [Budget, timeline, resource limits]
Legal/Compliance: [Regulatory requirements]

Assumptions
    

[Key assumptions — what must be true for this plan to work]

Dependencies
    

[External systems, teams, or artifacts this work depends on]

Risks
    

  

      

          
Risk
          
Probability
          
Impact
          
Mitigation
      
  
  

      

          
[Risk]
          
High/Med/Low
          
High/Med/Low
          
[Concrete strategy, not "monitor"]
      
  

Open Questions
    
[Unresolved items that need answers before or during implementation. Each
should name who can answer it and what's blocked by it. Prefer explicit
questions here over [TBD] markers scattered through the document.]

 [Question] — blocks [what], ask [who]

Success Criteria
    
[What must be true to call the initiative successful. These should be
observable outcomes, not activities.]
Review Checklist
    
Use this checklist when reviewing a PRD artifact:

 Summary works as a standalone 1-pager — someone can decide whether to read the rest
 Problem statement describes a specific failure mode with concrete cost
 Goals are outcomes, not activities ("users can X" not "we build Y")
 Success metrics have numeric targets and named measurement methods
 Non-goals exclude things a reasonable person might assume are in scope
 Personas have specific pain points, not generic descriptions
 P0 requirements are necessary for launch — removing any one makes the product unusable
 P1/P2 requirements are correctly prioritized relative to each other
 Every P0 requirement has an acceptance test sketch
 Requirements can trace upward to the Product Vision and downward to downstream artifacts
 Functional requirements are testable — each can be verified with specific inputs and expected outputs
 Technical context names specific versions and interfaces, not vague technology areas
 Risks have concrete mitigations ("we do X"), not vague strategies ("we monitor")
 Open questions name who can answer and what is blocked
 No contradictions between requirements sections
 PRD is consistent with the governing product vision