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

spec-product-prd

Writing & research

View repository

Updated 10-16 01:34

About this skill

spec-product-prd (R2: Generate PRD based on the solution)

Overview

The goal of R2 is to take {FEATURE_DIR}/requirements/solution.md inrecommended decisionand transcribe it into {FEATURE_DIR}/requirements/prd.md: enabling R&D to break down tasks, QA to write test cases, and stakeholders to review and accept.

  • Verifiability first: the core of the PRD is scenarios + business rules + AC (testable)
  • Uncertainty convergence: in the PRD,do not appear"Pending confirmation questions / Open Questions" lists; unknowns uniformly go into theverification checklist(Owner/deadline/signal/action)
  • Do not repeat R1: solution comparisons/why chosen/discussion process stay in solution.md; the PRD only writes delivery specifications

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

When to use / not use

  • When to use
    • R1 is complete and has produced requirements/solution.md, and the delivery specification (scope/AC/milestones/risk dependencies) needs to be frozen as a standalone PRD review
  • Do not use when
    • spec-context fails (context location failure) → stop immediately
    • requirements/solution.md does not exist / is clearly not converged (missing conclusion summary/scope In-Out/recommended solution/verification checklist) → stop and return to R1

Input / Output (persistence conventions)

  • Hard gate input：FEATURE_DIR(must be obtained by spec-context )
  • Read
    • {FEATURE_DIR}/requirements/solution.md(required reading, as the sole decision entry point)
    • {FEATURE_DIR}/requirements/raw.md(as needed: evidence supplement entry/original wording)
    • project/memory/glossary.md(if present: terminology and definitions)
  • Write
    • {FEATURE_DIR}/requirements/prd.md(R2 artifact, preferably generated according to the template)

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/solution.md missing → stop(must not "just produce a first version of the PRD and then talk")

Violating the gate = violating the spirit: regardless of "tight schedule/boss pushing/process blockage," guessing paths is prohibited, and skipping is prohibited solution.md to forcibly write the PRD.

Core process (specification persistence; this skill does not do the next-step routing)

0) Foolproof validation: if R2 should not be entered, then stop and return to using-aisdlc

If the upstream routing conclusion is "skip R2 (do not produce prd.md separately)," then this skill should not continue executing (otherwise it would violate the "single router" principle). At this point, stop and prompt to return to using-aisdlc, and let it decide to append a Mini-PRD in solution.md or enter the subsequent phase.

This skill allows retaining the understanding of the convention that "simple requirements may skip R2," but only asfoolproof validation, and must not directly give the next-step routing conclusion here.

1) From solution.md Extract the PRD's "deliverable information"

Extract from solution.md the content directly related to delivery/acceptance into a checklist (do not branch out into new conclusions):

  • One-sentence goal, In/Out, MVP boundary
  • Core scenarios (recommended ≤ 3) and success criteria
  • Feature items (decomposable) and priority (P0/P1/P2 or Must/Should/Could/Won't)
  • Business rules/definitions that will affect AC (cite if possible; if uncertain, put them in the verification checklist)
  • Known risks/dependencies/assumptions (transcribe into the PRD's verification checklist table)

2) Use the template to generate/update {FEATURE_DIR}/requirements/prd.md

Prioritize aligning with the template:<本SKILL.md目录>/assets/prd-template.md(only borrow the structure, do not treat the unknown as known).

Writing requirements (the points most prone to going off track):

  • Scenario-driven: the scenarios in Section 3 must be able to directly derive the AC in Section 6
  • AC testable: each AC can be written as "input/action/expected result" rather than a subjective description
  • Priority aligned with milestones: MVP covers at least P0/Must; the Out/Won't definitions are clear
  • Uncertainty appears only once: write it only in the Section 8 "Risks/Dependencies and Verification Checklist" table

3) R2 self-check (go through it immediately after writing)

  • In/Out is consistent with solution.md and unambiguous
  • Every core scenario has an AC (can be directly converted into test cases)
  • Feature priority is consistent with milestones: MVP covers Must/P0
  • Business rules/definitions are traceable; untraceable items have entered the verification checklist
  • Key exceptions and boundaries cover situations that affect AC (permissions/failures/idempotency, etc.)
  • The document does not contain a "pending confirmation questions / Open Questions / TBD items" list

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

After completion, output and automatic routing (must be executed)

prd.md Aftermustcomplete the following actions (in order, cannot be omitted):

  1. Output ROUTER_SUMMARY(in YAML form, for Router decision-making):
ROUTER_SUMMARY:
  stage: R2
  artifacts:
    - "{FEATURE_DIR}/requirements/prd.md"
  needs_human_review: false
  blocked: false
  block_reason: ""
  notes: "软检查点：PRD 建议评审；如不触发硬中断 Router 可继续自动推进"

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

    • If the Router determines that it can automatically continue: continue executing the next worker skill (such as R3, D0, etc.) in the same conversation turn
    • 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-aisdlc, you may briefly state "The artifacts for this stage have been written to disk; calling using-aisdlc to route the next step."

Quick reference (quick lookup of high-frequency rules)

  • Must
    • first execute spec-context to obtain context, and use only FEATURE_DIR to assemble the path
    • Required reading solution.md, the PRD only performs "transcription/specification" and does not add new decisions
    • The PRD must contain: In/Out, core scenarios, AC, verification checklist (Owner/deadline/signal/action)
  • Prohibited
    • guessing the path (for example, manually writing .aisdlc/specs/...）
    • solution.md still generating a PRD when it is missing ("write first then ask / produce a first version")
    • Write an "Open Questions / Items to Be Determined" list (replace it with a verification checklist table)

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

  • Without running spec-context you start reading/writing requirements/*.md(or start "guessing FEATURE_DIR")
  • solution.md does not exist / has not converged, yet you still plan to "write the PRD first to hold the slot"
  • The PRD contains 待确认 / Open Questions / 待定 / TBD and similar lists
  • ACs are full of subjective words ("friendly/clear/reasonable/as soon as possible") without verifiable actions
  • Milestones are written, but feature priorities do not align with the MVP scope (the MVP does not cover P0/Must)

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

Excuse (verbatim/near-verbatim) Common violating behavior Required countermeasure action
“The boss will review in 10 minutes... write first, ask later” Skip spec-context / guess paths / write the PRD first and backfill the basis later If the gate fails, stop; when something must be delivered first, you may only deliver a "verification checklist + next actions," not a "guessed PRD"
“Guess the path, fix it if wrong” Write to the wrong directory, causing all subsequent references/traceability to break Only recognize FEATURE_DIR=... output; concatenate all paths with $FEATURE_DIR concatenation
“Even without a solution, produce a first version of the PRD” Use raw material + common sense to fill in the blanks, causing scope and decision drift solution.md missing/unconverged → Stop and return to R1(first stabilize the decision entry point)
“Just mark all uncertainties as open questions” The PRD contains an Open Questions list, with no one responsible and no way to converge Use the verification checklist table in Section 8: Owner/deadline/signal/action all complete; "to be confirmed" no longer appears in other sections
“For a simple requirement, just write an issue/checklist” Delivery specifications are scattered outside the system and cannot be traced or iterated A simple requirement should either go through R2, or within solution.md append a Mini-PRD; using an issue as a substitute for written artifacts is prohibited

A good example (rewriting "open questions" into an executable verification checklist)

Bad writing (prohibited)：

  • To be confirmed: what is the maximum number of exported rows?
  • To be confirmed: what is the performance metric?

Good writing (written into the verification checklist table in Section 8 of the PRD)：

Risk/Assumption/Dependency Verification signal Method Owner Deadline Trigger action
Assumption: MVP synchronous export is acceptable within ≤50,000 rows Export time ≤30s and does not trigger timeout/memory alerts Stress test with real data distribution; record P95 DEV 3 days after review If the threshold is exceeded: switch to the asynchronous export approach, and update the PRD milestones and ACs