01 Prd Generation

PRD Generation Skill

Use When

• Discovery is sufficient to define product outcomes, users, feature priorities, measurable success and release boundaries.

Do Not Use When

• Do not use to test an unvalidated business model; use 04-lean-canvas. Do not use for implementation design; route approved requirements to Phase 03.

Required Inputs

Workflow

1. Read the named inputs and confirm their approval, version and unresolved decisions.
2. Apply the decision rules below before drafting; stop on a missing authority, unsafe assumption or unresolved scope driver.
3. Produce the Product Requirements Document and manifest through the existing domain procedure and load only the references needed for the chosen branch.
4. Trace each material statement in the Product Requirements Document and manifest to an input, decision or explicitly qualified assumption.
5. Verify the observable acceptance conditions, record unassessed checks, and hand the artefacts to their named consumers.
6. If validation fails, recover by correcting the source decision or artefact and rerun the affected check; do not weaken the acceptance condition.

Outputs

Evidence Produced

Capability and permission boundaries

Read-only is the default for analysis, review, evaluation and planning. Read and search access to authorised project artefacts are required. Editing is limited to an explicitly requested project deliverable. Execution may run document, syntax or validation checks. Network access is used only for facts that require current verification. Do not publish, spend, change production, approve policy, or claim certification without explicit authority.

Degraded mode

If any required capability is unavailable, return the narrowest useful qualified Product Requirements Document and manifest draft plus a gap register showing the missing item, affected sections, risk and owner. Never convert an unassessed check into a pass.

Decision Rules

Quality Standards

• Preserve repository terminology and trace every material choice to project context.
• Use deterministic acceptance conditions; replace vague quality claims with an observable check, threshold or named approval.
• Cover error, empty, edge, recovery and operational cases relevant to this skill.
• Verify standards, citations, APIs and package names before relying on them; qualify what cannot be checked.
• Stop release for a failed safety, security, legal, financial, accessibility or data-integrity gate.

Anti-Patterns

• Writing a feature list without objective traceability. Fix: map each feature to a named objective and measure.
• Turning stakeholder wishes into requirements without evidence. Fix: label the source and decision owner.
• Using high/medium/low without a rule. Fix: apply the priority matrix in this skill.
• Hiding scope exclusions in prose. Fix: maintain an explicit out-of-scope register.
• Claiming a metric without a baseline or measurement method. Fix: name the baseline gap and instrumentation owner.

References

• SaaS PRD addendum
• AI feature PRD addendum
• PRD learning contract
• Generation logic

SaaS mode: if the project is a multi-tenant SaaS, apply references/saas-prd-addendum.md in addition to the generic steps below.

Overview

For every material objective, load the PRD learning contract. Convert uncertain assumptions into a baseline, hypothesis, smallest reversible experiment, primary measure, guardrails, owner, stop rule, decision, and next cycle. Do not let a roadmap statement masquerade as validated demand.

This is the second skill in Phase 01 (Strategic Vision). It builds on the Vision Statement to create a comprehensive Product Requirements Document (PRD) that bridges strategic intent and detailed requirements engineering. The PRD serves as the authoritative source for product scope, feature prioritization, and measurable objectives before downstream skills decompose features into formal SRS-level requirements.

When to Use

• After the 03-vision-statement skill has produced Vision_Statement.md in projects/<ProjectName>/<phase>/<document>/.
• Directly after 00-meta-initialization if the team is working without a formal vision document but has populated vision.md and features.md in projects/<ProjectName>/_context/.

Quick Reference

Input Files

Output Files

Core Instructions

Follow these nine steps in order. Halt and notify the user if a required input file is missing.

Step 1: Read Context Files

Read vision.md, features.md, and stakeholders.md from projects/<ProjectName>/_context/. Optionally read Vision_Statement.md from projects/<ProjectName>/<phase>/<document>/. Log every file path read. If vision.md or features.md is missing, halt execution and report the gap.

Step 2: Generate Document Header

Write the document header containing:

• Project name (from vision.md)
• Version: 1.0
• Date: current date
• Authors: extracted from context or marked [AUTHOR-TBD]
• Document Status: Draft

Step 3: Generate Executive Summary

Write one paragraph in active voice that distills the product purpose, the primary user segment it serves, and the key value proposition. Avoid superlatives and marketing language.

Step 4: Generate Market Context

• Problem Space: Extract directly from the Problem Statement in vision.md.
• Target Market Segments: Derive from stakeholders.md user roles and domains.
• Competitive Landscape: Infer from domain constraints and technology choices. Flag any assertions that lack grounding with [INFERRED].
• Premium Positioning: If the product targets premium, affluent, executive, enterprise, luxury, high-ticket, or elite users, load ../07-premium-product-positioning/SKILL.md and apply its requirements gate before finalising market context, feature priorities, success metrics, or release strategy.

Step 5: Generate Product Objectives

Create one objective per business goal listed in vision.md. Each objective shall follow SMART format:

• Specific: what exactly will be achieved
• Measurable: quantitative metric
• Achievable: feasibility note
• Relevant: link to business goal
• Time-bound: target date or release

Flag any goal that lacks a measurable metric with [METRIC-TBD].

Step 6: Generate Target Users and Personas

From stakeholders.md, produce a summary of user segments including:

• Persona name and role
• Key characteristics and goals
• Pain points relevant to the product
• Usage frequency and technical proficiency

Step 7: Generate Feature Priority Matrix

Produce a table with the following columns:

• Priority: Critical / High / Medium / Low (by business impact)
• Effort: S / M / L / XL (by technical complexity)
• Value: High / Medium / Low (by user benefit)
• MoSCoW: Must / Should / Could / Won't (by MVP criticality)
• Rationale: one sentence justifying the classification

Every feature in features.md shall appear in this table.

Step 8: Generate Success Metrics

Define 3-5 Key Performance Indicators. Each KPI shall include:

Flag unknown baselines with [BASELINE-TBD].

Step 9: Generate Remaining Sections and Write Output

• Constraints and Dependencies: Budget, timeline, technology, and regulatory constraints from vision.md. External system dependencies and API integrations.
• Release Strategy: Phased rollout plan mapping features to releases by priority tier.
• Standards Traceability Appendix: Table mapping each PRD section to the corresponding IEEE 29148-2018 and IEEE 1233-1998 clause numbers.

Write the completed document to projects/<ProjectName>/<phase>/<document>/PRD.md. Log the total section count and feature count.

Final Step: Write manifest.md

After generating all section files, create (or overwrite) manifest.md in this document's directory listing the section files in the correct assembly order:

# Document Manifest — PRD
# Generated by prd-generation. Edit to reorder or exclude sections before building.
01-purpose.md
02-scope.md
03-stakeholders.md
04-features.md
05-constraints.md

This ensures scripts/build-doc.sh assembles sections in the intended order rather than alphabetical fallback.

Output Format

The generated PRD.md shall follow this template structure:

# Product Requirements Document: [Project Name]

## Document Header
## 1. Executive Summary
## 2. Market Context
### 2.1 Problem Space
### 2.2 Target Market Segments
### 2.3 Competitive Landscape
## 3. Product Objectives
## 4. Target Users and Personas
## 5. Feature Priority Matrix
## 6. Success Metrics
## 7. Constraints and Dependencies
### 7.1 Constraints
### 7.2 Dependencies
## 8. Release Strategy
## 9. Standards Traceability
## Appendix A: Glossary

Common Pitfalls

1. Solution bias in the problem statement: Describe the problem, not the solution. The PRD defines what and why, not how.
2. Unmeasurable objectives: Every objective needs a metric. If one cannot be defined, flag it explicitly.
3. Missing feature rationale: A priority without justification is an opinion. Every row in the matrix requires a Rationale entry.
4. Vague success metrics: "Improve performance" is not a KPI. Specify baseline, target, and method.

Verification Checklist

• All required input files were read and logged.
• Every business goal in vision.md maps to at least one SMART objective.
• Every feature in features.md appears in the Feature Priority Matrix with all columns populated.
• Success Metrics include baseline, target, method, and timeline for each KPI.
• No marketing language or subjective adjectives appear without a defined metric.
• Standards Traceability appendix maps sections to IEEE 29148 and IEEE 1233 clauses.

Integration

Standards

• IEEE 29148-2018: Systems and software engineering -- Life cycle processes -- Requirements engineering. Governs the structure and content of requirements documentation.
• IEEE 1233-1998: Guide for Developing System Requirements Specifications. Provides guidance on well-formed requirements and traceability.

Resources

• logic.prompt -- executable prompt for automated PRD generation.
• README.md -- quick-start guide for this skill.

Strategic foundations check (added 2026-05-04 from Levy + Branson)

Canonical reference: docs/ux-foundations.md Sections 1 and 2.

Three checks before producing or finalizing the PRD:

1. Four Tenets check (Levy)

Verify the upstream artifacts and PRD scope contain evidence for all four tenets:

If any tenet lacks evidence, the PRD is "speculative" — return to upstream stage rather than ship a polished but unfounded PRD.

2. Persona discipline (Branson, Section 1)

The PRD's persona section must:

• Declare ONE Essential Persona per primary user role (no averaging)
• Include the full Mechanics floor (name, demographics, goals, environment, pain points, stress points)
• Use specific, named personas in feature-justification arguments — "Persona X needs Y" — not "users want Y"

3. Field-of-Dreams flag (Levy)

If the PRD contains no validated user research and no plan to acquire it, mark the PRD itself as "speculative." Speculative PRDs cannot be priced as execution engagements; they must precede a discovery engagement. Document the speculative-status banner at the top of the PRD.

Book-derived additions

For feature hypotheses, experiments, measures, and stop decisions, load evidence-backed hypothesis and learning.