{FEATURE_DIR}/requirements/solution.md

{FEATURE_DIR}/requirements/prd.md

• 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

• 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

• 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)

spec-context

FEATURE_DIR=...

. ".\.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.

prd.md

solution.md

• 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)

solution.md

• 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)

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

• 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

• 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

• 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)

• 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)

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