spec-product-prototype (R3: Generate Prototype Specifications Based on PRD)

Overview

{FEATURE_DIR}/requirements/prd.md

{FEATURE_DIR}/requirements/prototype.md

• Task Flow (Mermaid) + Node Numbering (T-001…)
• Page/Popup Checklist (P/D/W-001…) + Node Coverage Relationship
• Page-by-Page Description: Entry/Controls/Status/Navigation + Pure ASCII Wireframe
• AC → Interactive Node Mapping: Able to answer "which AC is verified on which page/status"
• Walkthrough/Verification Script: Can flow back to update R1/R2/R3 after verification to form a closed loop

R3 is not a mandatory step: If there are no interaction changes or the interaction is simple and clear, you should skip R3 according to the diversion criteria in the PRD and directly proceed to the design phase.

When to Use / Not to Use

• Usage Scenarios
  • R2 has been completed,

    {FEATURE_DIR}/requirements/prd.md

    exists, and the requirement involves new/changed interactions or unclear interactions that need to be clarified through "text prototype + wireframe" to eliminate implementation/acceptance ambiguities
• Do Not Use When

  • spec-context

    fails (context positioning failed) → Stop immediately

  • {FEATURE_DIR}/requirements/prd.md

    is missing → Stop and return to R2
  • The PRD clearly states "R3 can be skipped" (no interaction changes/simple and clear interactions) → Do not generate

    prototype.md

    ; directly proceed to design after the PRD clarifies the minimum interaction conclusions

Input / Output (File Storage Convention)

• Mandatory Input:

  FEATURE_DIR

  (must be obtained via

  spec-context

  )
• Read

  • {FEATURE_DIR}/requirements/prd.md

    (required: scenarios/rules/AC/verification checklists/prototype diversion conclusions)

  • {FEATURE_DIR}/requirements/solution.md

    (as needed: verification checklist references/decision criteria)

  • {FEATURE_DIR}/requirements/raw.md

    (as needed: evidence entry/original wording)
• Write

  • {FEATURE_DIR}/requirements/prototype.md

    (R3 deliverable, preferably generated according to the template)

Gatekeeping (Must Pass First, Otherwise Stop)

spec-context

FEATURE_DIR=...

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

• spec-context

  fails → Stop

• {FEATURE_DIR}/requirements/prd.md

  is missing → Stop (must not "generate a prototype first and adjust later")

Violating gatekeeping rules = violating the core principle: No matter if "the boss needs a review in 10 minutes/the user is urging/the user doesn't want to run the script", guessing paths and fabricating prototypes without a PRD are strictly prohibited.

Core Process (Diversion → Structured Storage → Traceable Verification)

0) First Perform R3 Diversion (Highly Recommended)

• Do not generate

  prototype.md

• Ensure the PRD has supplemented the minimum interaction conclusions (pages and entries, key controls/fields and verification points)
• Directly proceed to the design phase

1) Extract "Prototype Mandatory Information" from PRD (No New Decisions Allowed)

• Core scenarios (recommended ≤ 3) and success criteria
• AC checklist (categorized by scenario)
• Key rules/criteria (that affect interaction and verification/prompts)
• Risks/dependencies and verification checklist items (reference numbers)

• Stop and return to R2 (first complete the deliverable specifications)

2) Generate Task Flow (Mermaid) and Node Numbering

• Node numbering: T-001…
• At least one end-to-end main link per scenario (key branches like success/failure/cancel/back, etc.)
• Each node must map to a Node ID in the page/popup checklist

3) Generate Page/Popup Checklist (Locatable)

• Pages: P-001…
• Popups: D-001…
• Drawers: W-001…
• Each Node must mark which T-xxx, scenarios, and ACs it covers

4) Write "Implementable" Page Descriptions (Including ASCII Wireframe)

• Entry and purpose (including preconditions; unknowns must not be fabricated, must reference verification checklist numbers)
• ASCII wireframe (mandatory, pure ASCII character drawing)
• Status and feedback (at minimum: normal/loading/empty/error/no permission; submission interactions include success/failure feedback and recovery paths)
• Key verification and error handling (only those affecting ACs)
• Navigation and interaction (success/failure/cancel/close/back; high-risk operations must include a secondary confirmation strategy)

User preferences cannot override constraints: Even if users find ASCII "ugly", ASCII wireframes must be output to ensure portability, reviewability, and traceability. A Figma link can be attached additionally, but ASCII cannot be removed.

5) Generate AC → Interactive Node Mapping (Must Be Traceable)

• Each AC in the PRD must map to at least one page/node and specific verification point (status/copy/button availability/navigation result)
• ACs that cannot be mapped: Regarded as gaps in the prototype or PRD → Flow back to R2 to complete

6) Write Walkthrough/Verification Script (Closed Loop, Not One-Time Deliverable)

• Covers which verification checklist items (reference numbers from PRD/solution)
• Write one task script per core scenario (goal → steps → success criteria → observation points)
• Clarify flow-back rules: What issues require flowing back to R1/R2/R3

Quick reference (Quick Check for High-Frequency Rules)

• Mandatory
  • Run

    spec-context

    first, only use

    FEATURE_DIR

    to construct paths

  • prd.md

    must exist and allow extraction of scenarios + AC + (at least one) verification checklist

  • prototype.md

    must include: task flow (T-xxx), page checklist (P/D/W-xxx), page-by-page ASCII wireframes, AC mapping, walkthrough script
• Prohibited
  • Guessing paths / writing files in unknown contexts
  • Continuing generation when

    prd.md

    is missing ("generate a version first")
  • Writing "to-be-confirmed questions / Open Questions / TBD" checklists (unknowns must reference verification checklists; if missing, flow back to complete)
  • Replacing ASCII with tables/images (a link can be attached additionally, but cannot replace ASCII)
  • Adding new scope/rules/decisions in R3 (R3 only focuses on interaction specification and traceability)

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

• Starting to read/write

  requirements/*.md

  without running

  spec-context

  (or "guessing FEATURE_DIR")
• Planning to "write a prototype first to reserve a spot" even though

  prd.md

  does not exist/lacks ACs
• Using Open Questions/to-be-confirmed checklists to handle uncertainties instead of referencing verification checklists from PRD/solution
• Writing unknowns as knowns (fabricating pages/permissions/data criteria/error strategies, etc.)
• Removing ASCII wireframes to cater to preferences (resulting in non-portability/unreviewability)

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

spec-context

prd.md

prd.md

A Good Example (Minimum Traceable Framework)

• Task flow: T-001 Enter → T-002 Fill in → T-003 Submit successfully / T-004 Verification failed
• Page: P-001 Form page (covers T-001/T-002/T-003/T-004)
• AC mapping: AC-001→P-001/error state; AC-002→P-001/success navigation

Template entry:

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