SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsprd-write

prd-write

Writing & research

View repository

Updated 10-16 01:16

About this skill

PRD Writing

Turn product intent into a requirements document that can be reviewed, handed off, and continuously maintained. The PRD is the decision record for this feature; it does not repeat the confirmed global product rules, nor is it a pixel-by-pixel UI implementation description.

Scope of Use

  • Complete mode: first version of a product, a major new module, or a proposal that needs to realign the problem, users, strategy, and metrics. Additional criterion: there is no reusable experience baseline, and this time involves a change in positioning or business model → it is also complete mode. "Already iterating" is not a prerequisite for incremental mode—the fact that the project does not yet have a product does not mean this matter is not significant.
  • Incremental mode (default): an already iterating product adds or adjusts one feature. Clearly write the change this time and its relationship to the experience baseline.
  • Small bugs, copy corrections, or fully clarified engineering tasks do not need a complete PRD; use the repository's existing issue/task process.
  • If the requirements are still verbal and the boundaries have not been clarified, first use requirement-clarify to conduct a round of interviews; if the user asks to review an existing PRD, hand it to grill-with-prd; if product-level experience rules need to be established, first use product-experience-foundation。
  • If the context has already been thoroughly discussed and there is no need to reuse an experience baseline, you can use context-to-prd—it is the same as this documentin structure and produces the same prd.md, and is a "lightweight alternative without interviews"; choose one of the two, do not run them consecutively. When a baseline needs to be reused or an incremental PRD needs to be written, this Skill must be used.

Before Starting: Determine the Context

  1. Determine the feature name, using the hyphenated format <feature-name>; the target path is docs/prd/<feature-name>/prd.md。
  2. Read the repository conventions, relevant existing PRDs, affected pages, and related code. When a PRD already exists, first ask the user to choose: update, create a separate feature directory, or keep the original text.
  3. Find docs/product/<project-name>/：
    • When the target product is clear, read product-context.md, the relevant platform (c-end/ or admin/) of ux-foundations.md and patterns.md, as well as component-promotion-log.md(if it exists).
    • When there are multiple products or the directory cannot be determined, ask the user to specify; do not choose a baseline out of thin air.
    • When there is no baseline, continue writing the feature PRD, but mark "no experience baseline"; if this is the first version or the existing page experience is inconsistent, it is recommended to later run product-experience-foundation, and do not fabricate product-level rules on your own.
  4. Collect the requirements, research, data, competitors, screenshots, existing flows, and engineering constraints provided by the user. Mark facts as sources; mark reasonable inferences as [INFERRED], and list content that cannot be confirmed as open questions.
  5. Choose the mode: when an existing and applicable baseline is available, prefer incremental mode; use complete mode only when the complete strategic context is truly valuable.

Core Rules for Incremental PRDs

Each incremental PRD must clearly define four categories of content:

Category What to write Where to put it
Reuse baseline The navigation, page patterns, copy, states, or component rules followed this time 体验关系
Feature-local Flows, fields, permissions, and exception states that exist only for this feature 需求与验收
Candidate for promotion Patterns that may be reused in the future but have not yet become product rules 体验关系
Intentional deviation Where it differs from the baseline, the reason, the affected parties, and the write-back decision 体验关系
  • Do not repeat menus, basic controls, overlays, or empty/loading/error rules already defined in the baseline; replace them with links and a brief "reuse" note.
  • An unconfirmed one-off pattern can only be marked as a candidate and must not be treated directly as a global component or general flow.
  • If a pattern has already been adopted by two confirmed features, or is explicitly confirmed by the product, prompt to use product-experience-foundation to update patterns.md and the promotion record.
  • When the PRD conflicts with the baseline, record the deviation; do not silently overwrite the baseline.

Output structure

Based on template.md . Incremental mode must retain sections 0, 1, 2, 5, 7, 8, 9, and 10; sections 3, 4, and 6 may be condensed to "reuse existing conclusions" or omitted. Full mode should fill in all applicable sections.

How to write requirements and acceptance criteria

Organize by user-verifiable behavior, not by piling up pages or technical tasks:

### R1 创建任务
作为运营人员，我可以从任务列表新增任务，以便安排工作。

验收标准：
- 点击“新增任务”打开沿用 Admin 表单规则的弹窗。
- 必填项校验失败时，字段旁显示错误且不提交。
- 保存成功后关闭弹窗、刷新列表并显示成功反馈。
- 无创建权限的角色不显示入口，且接口仍拒绝该操作。
  • Clearly state roles, trigger conditions, main flow, state changes, permissions, exceptions, and acceptance results.
  • Add metrics, analytics events, migrations, interfaces, or data dependencies only when they have business value; do not invent solutions for unknown implementation details.
  • Place prototypes, design specs, competitive evidence, etc. in the same feature directory and link to them from the PRD:design.md、prototype.html、demo.md are all optional artifacts.

Collaboration and follow-up routing

  1. After completing the draft, use grill-with-prd to review scope, contradictions, boundaries, exceptions, and open questions, and write the confirmed conclusions back into the PRD.
  2. When external visual evidence is needed, use web-design-extractor; when an independent high-fidelity review prototype is needed, use design-spec-prototyper; when a clickable high-fidelity prototype that fits the project's current state is needed, use pm-frontend-prototype。
  3. At delivery, explain: PRD path, mode, baseline read, reuse rules, candidates/deviations, open questions, and next review action.

Common issues

  • Writing the PRD as a full product manual: For incremental features, write only the changes and link everything else to the baseline.
  • Treating design details as requirements: Describe user goals, states, and acceptance; leave visual details to the design spec or prototype.
  • No non-scope: Clearly state what will not be done this time to avoid treating future ideas as commitments by default.
  • Pretending the baseline is confirmed: Historical pages can only serve as observational evidence; their authority differs from that of explicit decisions.
  • Hiding uncertainty: Explicitly place missing roles, policies, data, or exception handling in open questions.

Pre-delivery checklist

  • The feature directory and prd.md path are correct, and existing documents have not been accidentally overwritten.
  • Full or incremental mode has been selected, with the reason stated.
  • The relevant product experience baseline has been read or is explicitly missing.
  • The incremental PRD lists reuse, local, candidates, and deviations (write "none" if there are none).
  • Scope, non-scope, roles, states, permissions, exceptions, and acceptance can be reviewed.
  • Uncertain content has source markers or open questions and has not been disguised as fact.
  • If this overturns the upstream clarify.md confirmed conclusion, the PRD states which version prevails.
  • After writing, scan once for garbled Chinese characters:grep -rnI $'\xef\xbf\xbd' docs/prd/<feature-name>/