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.

MRD Writing Rules

• Start from the market problem, not the feature list.
• Treat MRD as a "market bet memo": it should help the organization decide whether to invest.
• Use concrete user scenarios: "who is blocked, when, by what, and what they do now."
• Write high-level capabilities, not button-level implementation.
• Include "not doing now" to prevent scope creep.
• Use measurable signals: adoption, retention, conversion, task success, paid intent, sales cycle, support load, or cost saved.
• Include falsification: what evidence would make the team stop, narrow, or rethink the idea.

Optional Web Research

For current market size, regulations, competitor claims, pricing, recent product launches, or funding/news, browse and cite reliable sources. If browsing is unavailable or unnecessary, write "market data pending verification" rather than inventing numbers.

Final Response

Keep the final reply short:

• Link to the generated MRD file.
• Link to generated SVG files if any.
• Mention whether assumptions were made or web research was used.