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

spec-product-prd

Writing & research

View repository

Updated 10-16 08:46

About this skill

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

Overview

The goal of R2 is to transcribe the {FEATURE_DIR}/requirements/solution.md ofrecommended decisionsinto {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)
  • Converge uncertainty: In the PRD,do not includean "open questions / Open Questions" list; unknown items all go into theverification checklist(Owner/deadline/signal/action)
  • Do not repeat R1: Solution comparison/rationale for choice/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 acceptance-ready PRD (prd.md) based on solution.md."

When to use / when not to use

  • When to use
    • R1 is complete and has produced requirements/solution.md, and the delivery specifications (scope/AC/milestones/risks and dependencies) need to be frozen for an independent PRD review
  • Do not use when
    • spec-context fails (context location failed) → 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 (file 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 entry point/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: executing spec-context to obtain context, and echo back FEATURE_DIR=...(allowing (reuse)）。

  • spec-context failure → stop
  • {FEATURE_DIR}/requirements/solution.md missing → stop(must not "ship a first PRD draft and deal with it later")

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

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

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

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-aidlc, which will decide whether to append a Mini-PRD in solution.md or proceed to subsequent stages.

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

1) From solution.md Extract the “deliverable information” from the PRD

Take the content in solution.md that is directly related to delivery/acceptance and extract it into a checklist (do not introduce new conclusions):

  • one-sentence goal, In/Out, MVP boundaries
  • core scenarios (recommended ≤ 3) and success criteria
  • feature items (breakdown-able) and priority (P0/P1/P2 or Must/Should/Could/Won’t)
  • business rules/definitions that will affect AC (quote them if possible; if uncertain, put them in the verification checklist)
  • known risks/dependencies/assumptions (transfer them to the PRD 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 likely to go 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; 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 (review immediately after writing)

  • In/Out is consistent with solution.md and unambiguous
  • every core scenario has AC (can be directly converted into test cases)
  • feature priority is consistent with milestones: MVP covers Must/P0
  • business rules/definitions are traceable; non-traceable items have entered the verification checklist
  • key exceptions and boundaries cover cases that affect AC (permissions/failures/idempotency, etc.)
  • the document does not contain a “issues to be confirmed / Open Questions / pending items” checklist

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

Output and automatic routing after completion (must be executed)

prd.md after is written to disk,mustcomplete the following actions (in order, omissible):

  1. output ROUTER_SUMMARY(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-aidlc: pass the above ROUTER_SUMMARY as routing input to using-aidlc, and the Router will determine the next step andautomatically proceed(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-aidlc, you may briefly state “The artifacts for this stage have been written to disk; now calling using-aidlc to route the next step.”

Quick reference (quick lookup of high-frequency rules)

  • must
    • first execute spec-context to get context, and only use FEATURE_DIR to compose the path
    • required reading solution.md, the PRD only performs “transcription/specification” and does not add new decisions
    • the PRD must include: In/Out, core scenarios, AC, verification checklist (Owner/deadline/signal/action)
  • prohibited
    • guessing the path (for example, manually writing .aidlc/specs/...）
    • solution.md still generating a PRD when it is missing (“write first then ask / produce a first version first”)
    • Write a "Questions to be confirmed/Open Questions/To be determined" list (replace with a verification checklist table)

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

  • Did not run spec-context and started reading/writing requirements/*.md(or started "guessing FEATURE_DIR")
  • solution.md does not exist/has not converged, yet still plans to "write a PRD first to hold the spot"
  • In the PRD, a list such as 待确认 / Open Questions / 待定 / TBD appears
  • AC is full of subjective words ("friendly/clear/reasonable/as soon as possible") without verifiable actions
  • Milestones are written, but feature priorities do not match 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 violation Required countermeasure
“The boss will review in 10 minutes... write first, ask later” Skip spec-context / guess the path / write the PRD first and supplement the basis later If the gate does not pass, stop; when delivery is needed first, you may only deliver a "verification checklist + next-step actions," not a "guessed PRD"
“Guess the path, correct it later if wrong” Write to the wrong directory, causing all subsequent references/traceability to break Only recognize FEATURE_DIR=... output; all paths are joined with $FEATURE_DIR Concatenate
“If there is no solution, still produce a first version of the PRD” Use raw + common sense to fill in the blanks, causing scope and decisions to drift solution.md is missing/not converged → Stop and return to R1(first stabilize the decision entry point)
“Just mark all uncertainties as questions to be confirmed” An Open Questions list appears in the PRD; no one is responsible, and it cannot converge Use the Section 8 verification checklist table: Owner/deadline/signal/action are all complete; "to be confirmed" no longer appears in other sections
“For simple requirements, just write an issue/checklist” Delivery specs are scattered outside the system and cannot be traced or iterated Simple requirements either go through R2, or a Mini-PRD is appended in solution.md ; using an issue as a substitute for persisting to disk is prohibited

A good example (rewriting "questions to be confirmed" into an executable verification checklist)

Bad wording (prohibited)：

  • To be confirmed: what is the maximum number of export rows?
  • To be confirmed: what are the performance metrics?

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

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