spec-product-prd (R2: Generate PRD Based on Solution)

Overview

The goal of R2 is to transcribe the recommended decisions from

{FEATURE_DIR}/requirements/solution.md

into

{FEATURE_DIR}/requirements/prd.md

: enabling R&D to break down tasks, QA to write test cases, and stakeholders to review and accept deliverables.

Verification-first: The core of PRD is Scenario + Business Rules + AC (Testable)
Uncertainty Convergence: No "Pending Questions / Open Questions" lists are allowed in PRD; all unknowns are consolidated into the Verification Checklist (Owner/Deadline/Signal/Action)
No Duplication with R1: Solution comparisons/rationale/discussion processes remain in
```
solution.md
```
; PRD only includes delivery specifications

Announce at the start: "I am using the spec-product-prd skill to generate an acceptable PRD (prd.md) based on solution.md."

When to Use / Not to Use

Use Cases
- R1 is completed and
```
requirements/solution.md
```
  is produced; need to freeze delivery specifications (scope/AC/milestones/risk dependencies) into an independent PRD for review
- The requirement does not meet the criteria for "skipping R2 for simple requirements" (see diversion below)
Do Not Use When
- ```
spec-context
```
  fails (context positioning failed) → Stop immediately
- ```
requirements/solution.md
```
  does not exist / is clearly not converged (lacks conclusion summary/scope In-Out/recommended solution/verification checklist) → Stop and return to R1

Input / Output (File Storage Convention)

Mandatory Gate Input:
```
FEATURE_DIR
```
(must be obtained via
```
spec-context
```
)
Read
- ```
{FEATURE_DIR}/requirements/solution.md
```
  (mandatory read, serves as the only decision entry point)
- ```
{FEATURE_DIR}/requirements/raw.md
```
  (as needed: supplementary evidence entry/original wording)
- ```
project/memory/glossary.md
```
  (if exists: terminology and specifications)
Write
- ```
{FEATURE_DIR}/requirements/prd.md
```
  (R2 deliverable, generate according to template first)

Gates (Must Pass First, Otherwise Stop)

REQUIRED SUB-SKILL: Execute
spec-context
first and echo
FEATURE_DIR=...
.

powershell

. ".\.aisdlc-cli\scirpts\spec-common.ps1"
$context = Get-SpecContext
$FEATURE_DIR = $context.FEATURE_DIR
Write-Host "FEATURE_DIR=$FEATURE_DIR"

If
```
spec-context
```
fails → Stop
If
```
{FEATURE_DIR}/requirements/solution.md
```
is missing → Stop (do not "generate a PRD first and adjust later")

Violating gates = violating the core principle: Regardless of "time constraints/boss pressure/process bottlenecks", guessing paths and writing PRD without
solution.md
are strictly prohibited.

Core Process (Diversion + Standardized File Storage)

0) First Perform R2 Diversion (Optional but Highly Recommended)

If any of the "simple requirement" criteria are met, do not generate an independent
prd.md
; instead, return to R1's

solution.md

and append a Mini-PRD section before proceeding to design:

Pure rule/configuration/copy changes (no changes to task flow or page structure)
Minimal and unambiguous change scope (usually 1–2 changes, no complex trade-offs in permissions/status branches)
AC can be clearly written in a few entries in
```
solution.md
```
and can be directly accepted

Prohibited: Using "issue + checklist" to replace Mini-PRD: The minimum delivery specification of this process must be stored in
solution.md
(traceable, iterable, and storable in repository)

1) Extract Deliverable Information for PRD from

solution.md

Extract content directly related to delivery/acceptance from

solution.md

into a checklist (do not add new decisions):

One-sentence goal, In/Out, MVP boundaries
Core scenarios (recommended ≤3) and success criteria
Functional items (decomposable) and priorities (P0/P1/P2 or Must/Should/Could/Won’t)
Business rules/specifications that affect AC (reference if possible; add to verification checklist if uncertain)
Known risks/dependencies/assumptions (transcribe to the verification checklist table in PRD)

2) Generate/Update

{FEATURE_DIR}/requirements/prd.md

Using Template

Prioritize alignment with the template:

skills/spec-product-prd/prd-template.md

(borrow only the structure, do not treat unknowns as knowns)

Writing Requirements (Most Common Pitfalls):

Scenario-driven: Section 3 scenarios should directly derive Section 6 AC
Testable AC: Each AC can be written as "Input/Operation/Expected Result" instead of subjective descriptions
Priority Aligns with Milestones: MVP must cover at least Must/P0; Out/Won’t specifications are clear
Uncertainty Appears Only Once: Only written in Section 8 "Risks/Dependencies and Verification Checklist" table

3) R2 Self-Check (Review Immediately After Writing)

In/Out is consistent with
```
solution.md
```
and unambiguous
Each core scenario has corresponding AC (can be directly converted to test cases)
Functional priorities are consistent with milestones: MVP covers Must/P0
Business rules/specifications are traceable; untraceable entries have been added to the verification checklist
Key exceptions and boundaries that affect AC are covered (permissions/failure/idempotency, etc.)
No "Pending Questions / Open Questions / To-Be-Determined Items" lists appear in the document

Quick Reference (High-Frequency Rules)

Mandatory
- Run
```
spec-context
```
  first, only use
```
FEATURE_DIR
```
  to construct file paths
- Must read
```
solution.md
```
  , PRD only performs "transcription/standardization" and does not add new decisions
- PRD must include: In/Out, core scenarios, AC, verification checklist (Owner/Deadline/Signal/Action)
Prohibited
- Guessing paths (e.g., manually writing
```
.aisdlc/specs/...
```
  )
- Generating PRD when
```
solution.md
```
  is missing ("write first and ask later/generate a version first")
- Writing lists of "Pending Questions/Open Questions/To-Be-Determined Items" (use verification checklist table instead)

Red Flag Checklist (Stop and Correct If Any Item Appears)

Starting to read/write
```
requirements/*.md
```
without running
```
spec-context
```
(or starting to "guess FEATURE_DIR")
Planning to "write PRD first to reserve a spot" even though
```
solution.md
```
does not exist/is not converged

Lists like

Pending / Open Questions / To-Be-Determined / TBD

appear in PRD

AC is full of subjective words ("friendly/clear/reasonable/as soon as possible") without verifiable actions
Milestones are written, but functional priorities do not align with MVP scope (MVP does not cover Must/P0)

Common Excuses and Countermeasures (High-Frequency Points in Baseline Testing)

Excuse (Original/Approximate Words)	Common Violations	Mandatory Countermeasures
"The boss will review in 10 minutes... write first and ask later"	Skipping `spec-context` / guessing paths / writing PRD first and then supplementing basis	Stop if gates are not passed; if delivery is urgent, only deliver "verification checklist + next steps", not "guessed PRD"
"Guess the path, correct it later if wrong"	Writing to the wrong directory, causing all subsequent references/traceability to break	Only recognize the output of `FEATURE_DIR=...` ; all paths are constructed using `$FEATURE_DIR`
"Generate a PRD first even without solution"	Brainstorming based on raw content + common sense, leading to scope and decision drift	If `solution.md` is missing/not converged → Stop and return to R1 (stabilize the decision entry point first)
"Just mark all uncertainties as pending questions"	PRD contains Open Questions lists with no responsible person and no way to converge	Use the verification checklist table in Section 8 of PRD: complete with Owner/Deadline/Signal/Action; no "pending" items appear in other sections
"Just write an issue/checklist for simple requirements"	Delivery specifications are scattered outside the system, making them untraceable and uniterable	Simple requirements either go through R2 or append a Mini-PRD in `solution.md` ; using issue to replace file storage is prohibited

A Good Example (Rewriting "Pending Questions" into Executable Verification Checklist)

Bad Writing (Prohibited):

Pending: What is the maximum number of export rows?
Pending: What are the performance indicators?

Good Writing (Write to PRD Section 8 Verification Checklist Table):

Risk/Assumption/Dependency	Verification Signal	Method	Owner	Deadline	Trigger Action
Assumption: MVP synchronous export is acceptable within ≤50,000 rows	Export time ≤30s and no timeout/memory alerts are triggered	Pressure test with real data distribution; record P95	DEV	3 days after review	If threshold is exceeded: switch to asynchronous export solution and update PRD milestones and AC

spec-product-prd

NPX Install

Tags

SKILL.md Content (Chinese)