跳转至

PRD命令

创建产品需求文档 — 它是 SDLC 需求阶段的交付物。记录成功需要什么为真以及为什么,并在如何之前停止。实现分解委托给/plan。

输入: $ARGUMENTS

此命令的范围

此命令会做 此命令不会做
框定问题和用户 设计架构
记录成功标准和范围 选择文件或描述模式
列出未解决问题和风险 列出实现任务
写入 .claude/prds/{name}.prd.md 创建实现计划 — 那是/plan

如果你发现自己正在写实现细节,请停下来并删除它。它属于/plan。

反幻觉: 如果信息不足,请写TBD — {方法}による検証が必要。不要编造听起来合理的需求。

工作流

4 个阶段。每个阶段是单一关卡 — 提问,等待用户,然后继续。没有嵌套循环,也没有并行研究仪式。

阶段 1 — FRAME

如果 $ARGUMENTS 为空,提问:

你想构建什么?用 1〜2 句话。

如果已提供,用一句话复述并提问:

我理解了:{复述}。正确吗,需要调整吗?

然后一次性提出框定问题:

  1. 谁有这个问题?(具体角色或细分)
  2. 什么是可观察到的痛点?(描述行为,而不是假设的需求)
  3. 为什么现有方案无法解决?
  4. 为什么是现在? — 什么变化使得做这件事有价值?

等待用户。没有回答(或明确的"skip")不要继续。

阶段 2 — GROUND

寻求证据。这是最短的阶段,也是最重要的:

有什么证据表明这个问题真实存在且值得解决?(用户引用、支持工单、指标、观察到的行为、失败的变通方案 — 任何具体事物)

如果用户没有证据,将 PRD 的 Evidence 部分记录为仮説 — {ユーザーリサーチ | アナリティクス | プロトタイプ}による検証が必要。这样可以保持 PRD 的诚实性。

阶段 3 — DECIDE

一次性提出范围和假设:

  1. 假设 — 请完成:我们相信{能力}能够解决{用户}的{问题}。如果获得{可衡量结果},我们就知道它是正确的。
  2. MVP — 测试假设所需的最小内容是什么?
  3. 范围外 — 即使用户要求,也明确不构建的是什么?
  4. 未解决问题 — 可能改变方法的不确定性是什么?

等待回答。

阶段 4 — GENERATE & HAND OFF

按需创建目录,写入 PRD,并报告。

mkdir -p .claude/prds

输出路径: .claude/prds/{kebab-case-name}.prd.md

PRD模板

# {製品 / 機能名}

## Problem
{2〜3文: 誰が何の問題を抱えていて、未解決のコストは何か?}

## Evidence
- {ユーザーの引用、データポイント、または観察}
- {または: "仮説 — {方法}による検証が必要"}

## Users
- **Primary**: {役割、コンテキスト、ニーズのトリガー}
- **Not for**: {明示的に除外する対象}

## Hypothesis
私たちは**{能力}**が**{ユーザー}**の**{問題を解決}**すると信じています。
**{測定可能な成果}**が得られたら正しいとわかります。

## Success Metrics
| Metric | Target | How measured |
|---|---|---|
| {primary} | {number} | {method} |

## Scope
**MVP** — {仮説をテストするための最小限}

**Out of scope**
- {項目} — {延期する理由}

## Delivery Milestones
<!-- ビジネス成果であり、エンジニアリングタスクではない。/planが各マイルストーンを計画に変換。 -->
<!-- Status: pending | in-progress | complete -->

| # | Milestone | Outcome | Status | Plan |
|---|---|---|---|---|
| 1 | {name} | {ユーザーに見える変更} | pending | — |
| 2 | {name} | {ユーザーに見える変更} | pending | — |

## Open Questions
- [ ] {スコープやアプローチを変える可能性のある質問}

## Risks
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|

---
*Status: DRAFT — 要件のみ。実装計画は/planで保留中。*

向用户报告

PRD created: .claude/prds/{name}.prd.md

Problem:    {一行}
Hypothesis: {一行}
MVP:        {一行}

Validation status:
  Problem  {validated | assumption}
  Users    {concrete | generic — refine}
  Metrics  {defined | TBD}

Open questions: {count}

Next step: /plan .claude/prds/{name}.prd.md
  → /plan が次の保留中のマイルストーンを選択し、実装計画を作成します。

集成

  • /plan <prd-path> — 消费 PRD,并为下一个待处理里程碑创建实现计划。
  • tdd-workflow技能 — 以测试优先方式实现计划。
  • /pr — 创建引用 PRD 和计划的 PR。

成功标准

  • PROBLEM_CLEAR: 问题具体且有证据(或标记为假设)。
  • USER_CONCRETE: 主要用户是具体角色,而不是"用户"。
  • HYPOTHESIS_TESTABLE: 包含可衡量的结果。
  • SCOPE_BOUNDED: 明确的 MVP 和明确的范围外。
  • NO_IMPLEMENTATION_DETAIL: 不包含文件路径、库、任务分解 — 如果包含,则移动到/plan步骤。

本页原文 Markdown:在 AtomGit 查看·内容源自开源项目 ev/ECC