spec-product-prototype

spec-product-prototype (R3: generate prototype description based on PRD)

Overview

The goal of R3 is to process the {FEATURE_DIR}/requirements/prd.md ofcore scenarios/rules/ACinto {FEATURE_DIR}/requirements/prototype.md：

• task flow（Mermaid）+ node numbering（T-001…）
• page/dialog list(P/D/W-001…) + node coverage relationships
• page-by-page description: entry/controls/states/navigation + pure ASCII wireframes
• AC → interaction node mapping: able to answer “which AC is verified on which page/state”
• walkthrough/verification script: after verification, can flow back to update R1/R2/R3, forming a closed loop

Announce at the start:"I am using the spec-product-prototype skill to generate a walkthrough-able prototype description (prototype.md) based on prd.md."

R3 is not a mandatory step: whether to enter R3 is determined solely by using-aisdlc as the sole router; this skill executes only when routed to R3.

When to use / not use

• When to use
  • R2 has been completed, {FEATURE_DIR}/requirements/prd.mdexists, and the requirement has newly added/changed interactions or interactions that are not clear enough, requiring “text prototype + wireframes” to eliminate implementation/acceptance ambiguity
• Do not use in
  • spec-context failure (context location failure) → stop immediately
  • {FEATURE_DIR}/requirements/prd.md missing → stop and return to R2
  • If you find that “this requirement should actually skip R3” (no interaction changes/interactions are simple and clear) → stop and return to using-aisdlc for re-routing (this skill must not internally rewrite the routing conclusion)

Input / output (persistence convention)

• Hard gate input：FEATURE_DIR(must be obtained by spec-context )
• Read
  • {FEATURE_DIR}/requirements/prd.md(required reading: scenarios/rules/AC/verification checklist/prototype routing conclusion)
  • {FEATURE_DIR}/requirements/solution.md(as needed: verification checklist references/decision criteria)
  • {FEATURE_DIR}/requirements/raw.md(as needed: evidence entry points/original wording)
• Write
  • {FEATURE_DIR}/requirements/prototype.md(R3 artifact, preferably generated according to the template; for the template see <本SKILL.md目录>/assets/prototype-template.md）

Gate (must pass first, otherwise stop)

REQUIRED SUB-SKILL: executing spec-context to obtain context, and echoing FEATURE_DIR=...(allowing (reuse)）。

• spec-context failure → stop
• {FEATURE_DIR}/requirements/prd.md missing → stop(must not “first produce a version of the prototype and then talk”)

Violating the gate = violating the spirit: regardless of “the boss reviews in 10 minutes/the user is pushing/the user does not want to run the script,” guessing paths is prohibited, and fabricating a prototype when the PRD is missing is prohibited.

Core process (structured persistence → traceable verification; this skill does not do the next-step routing)

0) Foolproof check: if R3 should not be entered, stop and return to using-aisdlc

If the PRD explicitly states “no prototype needed/R3 can be skipped,” or based on the input you determine that this time R3 should not be entered, then stop and prompt to return to using-aisdlc; it decides in prd.md Fill in the minimum interaction conclusion or enter design.

1) Extract the "prototype must-have information" from the PRD (no new decisions allowed)

Extract only information directly relevant to the interaction walkthrough (do not branch out into new rules/new scope in R3):

• Core scenarios (recommended ≤ 3) and success criteria
• AC list (grouped by scenario)
• Key rules/definitions (that affect interactions and validation/prompts)
• Risks/dependencies and verification checklist items (reference numbers)

If the PRD lacks AC, or lacks a verification checklist such that it cannot be persisted:

• Stop and return to R2(First fill in the deliverable specification)

2) Generate/update with the template {FEATURE_DIR}/requirements/prototype.md

Prioritize aligning with the template:<本SKILL.md目录>/assets/prototype-template.md(Borrow only the structure; do not treat the unknown as known). Steps 3–7 below are the specific requirements for filling in each section according to the template.

3) Generate the task flow (Mermaid) and node numbering

• Node numbering: T-001…
• Each scenario must have at least one end-to-end main path (key branches such as success/failure/cancel/back)
• Each node must map to a Node ID in the page/modal list

4) Generate the page/modal list (locatable)

• Pages: P-001…
• Modals: D-001…
• Drawers: W-001…
• Each Node must indicate which T-xxx it covers, which scenarios, and which ACs it is associated with

5) Write an "implementable" page description for each page (including ASCII wireframes)

One section per page/node, which must include:

• Entry and purpose (including preconditions; do not guess when unknown, and must reference verification checklist numbers)
• ASCII wireframe (required, pure ASCII character art)
• States and feedback (at least: normal/loading/empty/error/no permission; submission-type interactions include success/failure feedback and recovery paths)
• Key validation and error handling (write only those that affect AC)
• Navigation and interaction (success/failure/cancel/close/back; high-risk operations must specify a secondary confirmation strategy)

User preference cannot override constraints: even if the user thinks ASCII is "ugly", ASCII wireframes must still be output to ensure portability, reviewability, and traceability. A Figma link may be attached additionally, but the ASCII cannot be removed.

6) Generate the AC → interaction node mapping (must be traceable)

Requirements:

• Every AC in the PRD must map to at least one page/node and a specific verification point (state/copy/button availability/navigation result)
• ACs that cannot be mapped: treat as prototype or PRD gaps → Return to R2 to fill in

7) Write the walkthrough/verification script (closed loop, not a one-off artifact)

• Which verification checklist items are covered (reference the numbers in the PRD/solution)
• Write one task script for each core scenario (goal→steps→success criteria→observation points)
• Specify the return rules: which issues return to R1/R2/R3

After completion:Immediately call using-aisdlc to route the next step.

Output and automatic routing after completion (must be executed)

prototype.md After persisting,mustcomplete the following actions (in order, cannot be omitted):

1. Output ROUTER_SUMMARY(in YAML form, for Router decision-making):

ROUTER_SUMMARY:
  stage: R3
  artifacts:
    - "{FEATURE_DIR}/requirements/prototype.md"
  needs_human_review: false
  blocked: false
  block_reason: ""
  notes: "软检查点：原型建议走查；如不触发硬中断 Router 可继续自动推进"

1. Immediately execute using-aisdlc: use the above ROUTER_SUMMARY Passed as routing input to using-aisdlc, the Router determines the next step andautomatically advances(no need to wait for the user to say “continue”).

   • If the Router determines that automatic continuation is possible: continue executing the next worker skill (such as R4, D0, etc.) within the same conversation turn
   • If the Router triggers a hard interrupt: stop and output the blocking reason, required input, and candidate next steps

2. Conversation output: before calling using-aisdlc, you may briefly state “the artifacts for this stage have been persisted; calling using-aisdlc to route the next step.”

Quick reference (high-frequency rules quick lookup)

• Must
  • first execute spec-context to obtain context, and only use FEATURE_DIR to assemble paths
  • Must have prd.md and be able to extract the scenario + AC + (at least one) verification checklist
  • prototype.md must include: task flow (T-xxx), page inventory (P/D/W-xxx), per-page ASCII wireframes, AC mapping, walkthrough script
• Prohibited
  • guessing paths / writing files in an unknown context
  • prd.md continuing to generate when missing (“ship a first version and figure it out later”)
  • writing a “pending confirmation questions / Open Questions / TBD” list (unknowns must reference the verification checklist; if missing, loop back to fill the gap)
  • drawing wireframes as tables/images instead of ASCII (links may be attached additionally, but cannot replace it)
  • adding new scope/rules/decisions in R3 (R3 only does interaction specification and traceability)

Red-flag checklist (if any one appears: stop and correct)

• Not running spec-context and already starting to read/write requirements/*.md(or starting to “guess FEATURE_DIR”)
• prd.md does not exist/is missing AC, yet still planning to “write a prototype first just to hold the spot”
• using Open Questions/pending confirmation lists to carry uncertainty instead of referencing the PRD/solution verification checklist
• writing unknowns as knowns (making up pages/permissions/data semantics/error strategies, etc.)
• deleting ASCII wireframes to cater to preferences (making them non-portable/non-reviewable)

Common excuses and countermeasures (high-frequency points in baseline testing)

Excuse (verbatim/near-verbatim)	Common violating behavior	Required countermeasure action
“The boss reviews in 10 minutes, send out the prototype first”	Not running spec-context；prd.md and still forcing a write when missing; guessing directories and content	If the gate does not pass, stop; only deliver a “blocking explanation + next step (first supplement the PRD/run spec-context)”, and it is prohibited to deliver a made-up prototype
“The PRD is not written yet/or does not even exist, but let’s align on the interaction first”	fabricating pages and rules with common sense, causing subsequent drift	Missing prd.md → return to R2; first stabilize the scenario/AC/verification checklist, then do R3
“Don’t use ASCII, it’s too ugly; tables/screenshots are better”	deleting ASCII wireframes, making them unreadable/non-reviewable across environments	ASCII must be retained; a Figma/screenshot link may be attached in 0. Basic Information as a supplement, but it cannot replace ASCII
“Just write the details yourself following common practice”	over-fabricating (pagination/permissions/exception strategies/field validation, etc.), and writing an Open Questions list	R3: No new decisions allowed; write uncertainties asassumptions and cite verification checklist numbers; if the PRD/solution has no verification checklist, loop back to R2 to fill it in

A good example (minimal traceable skeleton)

• Task flow: T-001 enter → T-002 fill in → T-003 submit successfully / T-004 validation fails
• 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/successful redirect