Write Mrd

Write MRD

Purpose

Turn a product idea into a decision-ready MRD. The MRD must prove why the opportunity is worth pursuing before drifting into PRD-level feature details.

Default output: a Markdown file saved to the current project's markdown/ directory. Create the directory if missing.

Inputs

Accept any of these:

• A one-line product idea.
• A product concept plus target users, market, competitors, or business model.
• A rough draft MRD to rewrite.
• A request to generate a lightweight MRD, full MRD, or opportunity analysis.

If the idea is understandable but incomplete, proceed and mark missing facts as Assumptions or To Validate. Ask a question only when the product idea, target user, and use scenario are all too ambiguous to infer.

Required Workflow

1. Normalize the idea

   • Extract product name or working title, target customer, user scenario, pain point, existing alternatives, proposed value, business goal, and unknowns.
   • If the user gives no title, create a concise Chinese or English title from the idea.

2. Choose MRD depth

   • Use a lightweight MRD for small features, early exploration, or vague ideas.
   • Use a full MRD for new products, new markets, major capabilities, monetization changes, or user requests for complete/正式 MRD.
   • In both cases, keep MRD distinct from PRD: MRD explains why worth doing, PRD explains how exactly to build.

3. Build the MRD argument

   • Follow references/mrd-playbook.md for the writing logic.
   • Use assets/mrd-template.md as the output skeleton when useful.
   • Do not mechanically fill every field if evidence is weak; label assumptions and validation needs clearly.

4. Add useful visuals

   • Include at least one diagram in every MRD.
   • Prefer Mermaid for opportunity flow, user journey, stakeholder map, decision tree, or metric logic.
   • ASCII text is acceptable for compact comparisons or small decision paths.
   • If SVG is best, save it as a separate .svg file in the same markdown/ directory and reference it from the MRD with ![description](filename.svg).
   • Diagrams must clarify reasoning, not decorate the article.

5. Save files

   • File naming:
     • Chinese: markdown/<产品或主题>-MRD-<YYYYMMDD>.md
     • English: markdown/<product-or-topic>-mrd-<YYYYMMDD>.md
   • Use kebab-case or compact Chinese names; avoid spaces.
   • If generating SVG, name it markdown/<same-prefix>-figure-1.svg, figure-2.svg, etc.
   • Include source links when web/current facts are used.

6. Self-check before final response

   • The MRD answers: target customer, scenario pain, existing alternatives, market opportunity, differentiation, high-level capabilities, success metrics, risks, and falsification conditions.
   • It does not over-specify UI, APIs, database schemas, or detailed implementation unless the user explicitly asks.
   • It contains at least one visual.
   • It names assumptions and unknowns instead of pretending uncertain facts are known.
   • It ends with a concrete validation/watchlist section.
   • The Markdown file exists in markdown/; any SVG references point to existing files.