Plan-PRD 模式：Markdown 分阶段规划流程¶

一种轻量级、与 SDLC 对齐的规划工作流，生命周期中的每个阶段都会生成一个可提交的 Markdown 暂存文件，供下一条命令消费。

简版：/plan-prd 编写 PRD，/plan 编写计划，tdd-workflow 技能实现它，/pr 交付它。每个箭头都是磁盘上的文件，而不是内存中的对话。

功能：Markdown 暂存文件¶

每个规划产物都是 .claude/ 下的一个普通 .md 文件：

.claude/
  prds/      # Product Requirements Documents from /plan-prd
  plans/     # Implementation plans from /plan
  reviews/   # Code review artifacts from /code-review

这些文件：

纯 Markdown — 人类可读，可在 PR 中做差异比较，可在 CLI 中 grep。
可提交 — 与代码一起检入，使意图随实现一起传递。
可组合 — 每条命令接受上一阶段的文件作为其 $ARGUMENTS，因此工具链通过路径而非上下文状态进行组合。
可恢复 — 关闭会话，明天打开新会话，再传入文件路径即可。

流程¶

┌───────────────────────────┐
│ /plan-prd "<idea>"        │  Requirements phase
│  → .claude/prds/X.prd.md  │   Problem · Users · Hypothesis · Scope
└─────────────┬─────────────┘
              │
              ▼
┌───────────────────────────┐
│ /plan <prd-path>          │  Design phase
│  → .claude/plans/X.plan.md│   Patterns · Files · Tasks · Validation
└─────────────┬─────────────┘
              │
              ▼
┌───────────────────────────┐
│ tdd-workflow skill         │  Implementation phase
│  → code + tests           │   Test-first, minimal diff
└─────────────┬─────────────┘
              │
              ▼
┌───────────────────────────┐
│ /pr                        │  Delivery phase
│  → GitHub PR               │   Links back to PRD + plan
└───────────────────────────┘

每个框都是一个关卡。你可以：

在关卡之间停止 — 产物会持久保存。
使用产物路径从任意关卡重新开始。
对小工作跳过关卡 — 向 /plan 提供自由文本，并忽略 /plan-prd。
单独运行一个关卡 — /plan "refactor X" 会生成一个对话式计划，不产生产物。

为什么 `/plan-prd` 是 `/plan` 的补充¶

它们回答不同的问题。混用它们会导致范围蔓延。

命令	回答的问题	SDLC 阶段	产物
`/plan-prd`	什么问题？为谁？我们如何知道已完成？	需求	`.claude/prds/{name}.prd.md`
`/plan`	哪些文件、模式和任务能满足需求？	设计 + 实现策略	`.claude/plans/{name}.plan.md`（PRD 模式）或内联（文本模式）

为什么不合并它们？¶

关注点分离。 PRD 询问为什么；计划询问怎么做。将它们捆绑在一起会创建一个过大的命令，两者都做不好，正如旧的 /prp-prd → /prp-plan 组合所展示的（8 阶段盘问，且实现阶段表格混入需求中）。
受众不同。 审阅 PRD 的利益相关者不关心文件路径或类型检查命令。阅读计划的工程师不需要市场调研阶段。
生命周期不同。 PRD 可以保持稳定，而其计划会随着实现假设的变化被多次重写。
可选步骤。 许多变更（缺陷修复、小型重构、单文件新增）不需要 PRD。仅使用 /plan 就足够了。强制每次变更都写 PRD 是官僚主义。

何时使用哪一个¶

在以下情况使用 /plan-prd：

范围不明确或有争议。
多个利益相关者需要在提出解决方案前就问题达成一致。
变更足够大，以至于写下假设比在实现中途重新争论范围更便宜。

在以下情况直接使用 /plan：

需求已经明确（缺陷报告、范围明确的重构、已知迁移）。
工作足够小，对话式计划 + 确认关卡就足够了。
你已经有 PRD — 将其传给 /plan，跳过 /plan-prd。

用法¶

完整流程（范围不明确的功能）¶

# 1. Draft the PRD
/plan-prd "Per-user rate limits on the public API"

# → .claude/prds/per-user-rate-limits.prd.md created
# Answer the framing questions, provide evidence, define hypothesis and scope.

# 2. Pick the next pending milestone and produce a plan
/plan .claude/prds/per-user-rate-limits.prd.md

# → .claude/plans/per-user-rate-limits.plan.md created
# The plan includes patterns to mirror, files to change, and validation commands.
# PRD's Delivery Milestones table updates the selected row to `in-progress`.

# 3. Implement test-first
Use the tdd-workflow skill

# 4. Open the PR
/pr
# → PR body auto-references .claude/prds/... and .claude/plans/...

快速流程（范围已明确）¶

/plan "Add retry with exponential backoff to the notifier"
# Conversational planning, no artifact.
# Confirm, then use the tdd-workflow skill.

引用来自其他位置的现有 PRD¶

# PRD was written by someone else, lives in your repo
/plan docs/rfcs/0042-rate-limiting.prd.md

/plan 会检测任何 .prd.md 路径并切换到产物模式，解析 Delivery Milestones 表格。

为什么暂存文件优于上下文状态¶

可转移：将 PRD 路径放入新会话即可跟上进度 — 无需重放长对话。
可审计：PR 审阅者可以看到你的意图与你构建的内容并列呈现。
版本化：暂存文件在 git 历史中演进，与代码相同。
机器可解析：/plan 以编程方式选择下一个待处理里程碑；/pr 以编程方式在 PR 正文中链接产物。无需提示工程。

/plan-prd — 需求（此模式的入口点）。
/plan — 规划（消费 PRD 或自由文本）。
tdd-workflow 技能 — 测试优先实现。
/pr — 打开一个引用 PRD 和计划的 PR。
/code-review — 审查本地差异或 PR；自动检测 .claude/prds/ 和 .claude/plans/ 作为上下文。

兼容性¶

此模式在现有 prp-* 命令集旁边添加了 ECC 原生的暂存文件命令。旧版 PRP 命令仍然可用，适用于更深入的 PRP 工作流，以及已有 .claude/PRPs/ 工件的用户。

/plan-prd 是 .claude/prds/ 的精简需求入口。
/plan 可以读取 .prd.md 文件并生成 .claude/plans/ 工件，而无需依赖旧版 PRP 目录布局。
/pr 是 ECC 原生的 PR 创建命令，可以引用 .claude/prds/ 和 .claude/plans/。
/prp-prd、/prp-plan、/prp-implement、/prp-commit 和 /prp-pr 仍然是有效的旧版/深度工作流命令。

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