SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsspec-product-prototype

spec-product-prototype

General & other

View repository

Updated 10-16 08:49

About this skill

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/ACsinto {FEATURE_DIR}/requirements/prototype.md：

  • task flow（Mermaid）+ node numbering（T-001…）
  • page/modal list(P/D/W-001...) + node coverage relationships
  • page-by-page description: entry/controls/states/transitions + pure ASCII wireframes
  • AC -> interaction node mapping: can 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

At the start, announce:"I am using the spec-product-prototype skill to generate a walkthrough-ready prototype description (prototype.md) based on prd.md."

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

When to use / not use

  • When to use
    • R2 has been completed, {FEATURE_DIR}/requirements/prd.mdexists, and the requirements include new/changed interactions or the interactions are not clear enough, requiring "text prototype + wireframe" to eliminate implementation/acceptance ambiguity
  • Do not use when
    • spec-context fails (context locating failure) -> stop immediately
    • {FEATURE_DIR}/requirements/prd.md is 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-aidlc for re-routing (this skill must not internally rewrite the routing conclusion)

Input / Output (persistence conventions)

  • Hard gate input：FEATURE_DIR(must be obtained by spec-context )
  • Read
    • {FEATURE_DIR}/requirements/prd.md(required reading: scenarios/rules/ACs/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/original wording)
  • Write
    • {FEATURE_DIR}/requirements/prototype.md(R3 artifact, preferably generated according to the template; see the template in <本SKILL.md目录>/assets/prototype-template.md）

Gate (must pass first, otherwise stop)

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

  • spec-context failure -> stop
  • {FEATURE_DIR}/requirements/prd.md missing -> stop(do not "first produce a prototype draft and then talk")

Violating the gate = violating the spirit: regardless of "the boss will review 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 flow (structured persistence -> traceable verification; this skill does not perform the next-step routing)

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

If the PRD explicitly states "no prototype needed/R3 can be skipped", or based on the input you determine that R3 should not be entered this time, then stop and prompt to return to using-aidlc; let it decide in prd.md Fill in the minimal interaction conclusion or proceed to design.

1) Extract the “prototype-essential information” from the PRD (adding new decisions is prohibited)

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

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

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

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 be mappable 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 page by page (including an ASCII wireframe)

One section per page/node, which must include:

  • Entry and purpose (including preconditions; do not invent unknowns, and must reference verification checklist IDs)
  • 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 include a secondary confirmation strategy)

User preferences cannot override constraints: even if the user thinks ASCII is “ugly”, an ASCII wireframe must still be output to ensure portability, reviewability, and traceability. A Figma link may be additionally attached, but the ASCII must not 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 entries are covered (reference the IDs in the PRD/solution)
  • Write one task script for each core scenario (goal→steps→success criteria→observation points)
  • Specify the return rules clearly: which issues return to R1/R2/R3

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

Post-completion output and automatic routing (must be executed)

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

  1. Output ROUTER_SUMMARY(in YAML form, for the Router to decide):
ROUTER_SUMMARY:
  stage: R3
  artifacts:
    - "{FEATURE_DIR}/requirements/prototype.md"
  needs_human_review: false
  blocked: false
  block_reason: ""
  notes: "软检查点：原型建议走查；如不触发硬中断 Router 可继续自动推进"

  1. Immediately execute using-aidlc: send the above ROUTER_SUMMARY Passed as routing input to using-aidlc, the Router determines the next step andautomatically proceeds(no need to wait for the user to say "continue").

    • If the Router determines it can auto-continue: within the same conversation turn, continue executing the next worker skill (e.g., R4, D0, etc.)
    • If the Router triggers a hard interruption: stop and output the blocking reason, required input, and candidate next steps

  2. Conversation output: before calling using-aidlc, you may briefly state "The artifacts for this stage have been written to disk; calling using-aidlc to route the next step."

Quick reference (high-frequency rules cheat sheet)

  • 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 scenarios + AC + (at least one) verification checklist
    • prototype.md must contain: task flow (T-xxx), page list (P/D/W-xxx), per-page ASCII wireframes, AC mapping, walkthrough script
  • Forbidden
    • guessing paths / writing files in an unknown context
    • prd.md continuing to generate when missing ("just put out a first version and see")
    • writing a "questions to be confirmed / Open Questions / TBD" list (unknowns must reference the verification checklist; if missing, loop back to fill them in)
    • drawing wireframes as tables/images instead of ASCII (links may be additionally attached, but cannot substitute)
    • adding scope/rules/decisions in R3 (R3 only does interaction specification and traceability)

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

  • without running spec-context start reading/writing requirements/*.md(or start "guessing FEATURE_DIR")
  • prd.md does not exist/lacks AC, yet still plans to "write a prototype first to hold the slot"
  • using an Open Questions/to-be-confirmed list to carry uncertainty, instead of referencing the PRD/solution verification checklist
  • writing unknowns as knowns (inventing pages/permissions/data definitions/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 violations Required countermeasure
"The boss will review in 10 minutes, send out the prototype first" without running spec-context；prd.md still forcing a write when missing; guessing directories and content If the gate fails, stop; the only deliverable allowed is a "blocking description + next step (first fill in the PRD/run spec-context)"; delivering an invented prototype is forbidden
"The PRD isn't written yet/or doesn't even exist, but let's align on the interaction first" fabricating pages and rules from common sense, causing later drift Missing prd.md → go back to R2; first stabilize the scenarios/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; Figma/screenshot links may be attached in 0. Basic Information as a supplement, but cannot replace ASCII
"Just write the details yourself following common practice" over-inventing (pagination/permissions/exception strategies/field validation, etc.) and writing an Open Questions list R3: No new decisions may be added; write uncertainties asassumptions and cite verification checklist numbers; if the PRD/solution has no verification checklist, return 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/success redirect