Write Prd

Write PRD

Core Rule

Turn the user's idea into a PRD that helps a team decide, build, test, launch, and review the product work. A good PRD is not a feature list; it is a clear product bet:

problem -> user -> goal -> evidence -> scope -> behavior -> acceptance -> launch validation

Save the final PRD as Markdown under the current project's markdown/ directory. Create the directory if missing.

Inputs

Use the user's prompt as the source idea. If the prompt is vague, infer conservatively and write assumptions explicitly in the PRD. Ask a clarification question only when the missing information would materially change the product direction, such as target user, business domain, or platform.

If the user provides source notes, meeting records, screenshots, tickets, links, or existing docs, use them as evidence. If current market, competitor, pricing, regulation, or live product data is required and not provided, verify with reliable sources before using specific claims.

Workflow

1. Normalize the idea

   • Identify the product/domain, target user, triggering scenario, problem, proposed solution, and expected business outcome.
   • Separate user problem from requested solution. For example, "export Excel" may mean reporting, sharing, audit, migration, or offline analysis.
   • Name the PRD topic in a short Chinese or English slug.

2. Build the product argument

   • Write a one-sentence product bet: "For [user], in [scenario], solve [problem], by [solution], measured by [metric]."
   • State assumptions when evidence is absent.
   • Include existing alternatives or workarounds; a new product competes with the user's current behavior.
   • Define goals and non-goals before writing feature details.

3. Design the PRD structure

   • Read references/prd-template.md when drafting the document.
   • Keep sections practical. Do not pad with generic market background.
   • Scale detail with risk: simple internal tools can be concise; payment, data, permission, compliance, AI, or customer-facing flows need stronger edge cases and acceptance criteria.

4. Add diagrams

   • Include at least one useful diagram.
   • Prefer Mermaid for workflows, user journeys, state transitions, data flow, decision trees, and metric chains.
   • ASCII text is acceptable for simple state tables or wireframe sketches.
   • If using SVG, output the .svg file separately in markdown/ and reference it from the PRD with a relative Markdown image link, for example ![流程图](prd-topic-flow-20260609.svg).
   • Diagrams must support reasoning; do not add decorative graphics.

5. Write feature requirements

   • For each major capability, cover: user story, main path, edge cases, permissions, data rules, system behavior, analytics/events, and acceptance criteria.
   • Do not prescribe technical architecture unless the user asks. Product should define behavior, constraints, and verification, not implementation internals.
   • For AI features, specify input, output, quality bar, editability, failure modes, human review, data retention, and safety boundaries.

6. Define validation

   • Include result metrics, process metrics, and guardrail metrics.
   • Define launch plan, rollout scope, rollback conditions, and post-launch review timing.
   • Include stop conditions: what evidence means the team should stop, rollback, or change hypothesis.

7. Save and verify

   • File name: markdown/<topic>-prd-<YYYYMMDD>.md.
   • If SVG diagrams are created, use markdown/<topic>-<diagram-name>-<YYYYMMDD>.svg.
   • After writing, verify the Markdown file exists and includes a diagram, goals/non-goals, requirements, acceptance criteria, metrics, launch plan, and open questions.