{产品 / 功能名}
【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC
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
| # | Milestone | Outcome | Status | Plan |
|---|---|---|---|---|
| 1 | {name} | {用户可见的变化} | pending | — |
| 2 | {name} | {用户可见的变化} | pending | — |
Open Questions
- {可能改变范围或方案的问题}
Risks
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| --- | --- | --- | --- |
Status: DRAFT — 仅含需求。实现计划由 /plan 承接。
几个值得强调的设计意图： - **Problem 段落**要求"2～3 句"，强制作者在写清楚与写简短之间取得平衡；"放任不管的成本"是判断问题是否值得解决的价值锚点。 - **Evidence 段落**是反注水规则的主要落点：没有证据就诚实地标注为"假设 + 验证方法"。 - **Users 段落**把"Primary"与"Not for"并列，明确排除对象能防止范围蔓延（scope creep）。 - **Hypothesis** 使用固定句式把"能力 → 用户 → 问题 → 可测量成果"四要素一次性钉死，为后续的成功指标提供依据。 - **Delivery Milestones 是业务成果而非工程任务**——模板注释明确写道"`/plan` 将每个里程碑转化为计划"。这一行注释是 `/plan` 消费 PRD 的契约（见下文交接协议）。 ## 生成后的用户报告 写盘完成后，命令向用户输出如下报告，把生成结果压缩成可快速审阅的一屏：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 将选择下一个 pending 里程碑并生成实现计划。
注意报告末尾的 **Validation status** 三行：这是对 PRD 质量的即时自检——问题是否已有证据、用户是否具体、指标是否已定义，任何一个标为 "assumption" / "generic" / "TBD" 都提示 PRD 尚有短板。 ## 从 PRD 到实现：与 /plan 的交接协议 `/plan`（[commands/plan.md](https://link.gitcode.com/i/45fe54a830e0ea475f7c1fa64f71a46a)）接受四种输入模式： | 输入 | 模式 | 行为 | |---|---|---| | `path/to/name.prd.md` | PRD 工件模式 | 读取 PRD，选择下一个 pending 的交付里程碑或实施阶段，写入 `.claude/plans/{name}.plan.md` | | 其他任意 markdown 路径 | 参考模式 | 把文件当作上下文读取，产出内联计划 | | 自由文本 | 对话模式 | 产出内联计划 | | 空输入 | 澄清模式 | 询问要计划什么 | 在 PRD 工件模式下，`/plan` 会：按需创建 `.claude/plans/` 目录；如果 PRD 含 `Delivery Milestones` 表，**只把选中的行从 `pending` 更新为 `in-progress`**，并把该行的 `Plan` 单元格设为生成的计划文件路径；如果遇到旧版 `.claude/PRPs/prds/` 格式的 `Implementation Phases`，则直接读取而不迁移路径（[commands/plan.md](https://link.gitcode.com/i/711962d8f53fa05260f561f537034bc4)）。 `/plan` 生成的计划文件遵循固定结构（Source PRD / Selected Milestone / Complexity / Summary / Patterns to Mirror / Files to Change / Tasks / Validation / Risks / Acceptance），其中 **Patterns to Mirror** 会从代码库中检索命名、错误处理、日志、数据访问、测试等类别的既有约定作为实现镜像，找不到相似代码时就明确声明"不存在，不要凭空发明模式"（[commands/plan.md](https://link.gitcode.com/i/59f6a848c4770af61095b885f41241ff)）。这份计划与 PRD 一样，同样是可提交、可恢复、可被下一个阶段消费的 Markdown 工件。 ## Markdown 分阶段规划流程：为什么交接介质是文件而非对话 `/plan-prd` 属于 ECC 的 **Plan-PRD Pattern**（[docs/PLAN-PRD-PATTERN.md](https://link.gitcode.com/i/37ce60e17c0d357e07a890e2276ff7ac)）：生命周期每个阶段都产生一个可提交的 Markdown **staging 文件**，由下一个命令消费。文档的原话是："每个箭头都是磁盘上的一个文件，而不是内存中的一段对话。".claude/ prds/ # /plan-prd 生成的产品需求文档 plans/ # /plan 生成的实现计划 reviews/ # /code-review 生成的代码评审工件
这些文件具备四种特性：**纯 Markdown**（人类可读、可在 PR 中 diff、可在 CLI 中 grep）、**可提交**（与代码一起入库，意图随实现传递）、**可组合**（每个命令以上一阶段的文件路径作为 `$ARGUMENTS`，工具链通过路径组合而非上下文状态）、**可恢复**（关闭会话，明天用文件路径即可续接）。 流程全景：/plan-prd " " 需求阶段 → .claude/prds/X.prd.md（Problem · Users · Hypothesis · Scope） ↓ /plan 设计阶段 → .claude/plans/X.plan.md（Patterns · Files · Tasks · Validation） ↓ tdd-workflow skill 实现阶段 → code + tests（Test-first, minimal diff） ↓ /pr 交付阶段 → GitHub PR（回链 PRD + plan）
每个方框都是一道**门（gate）**：可以在门间停下（工件持久化）；可以从任意门用工件路径重启；小改动可以跳过门（直接给 `/plan` 传自由文本）；也可以单独跑一道门（`/plan "refactor X"` 产出纯对话式计划，不产生工件）。 ### 为什么 /plan-prd 是 /plan 之外的独立命令 两者回答的问题不同，混用会造成范围蔓延（[docs/PLAN-PRD-PATTERN.md](https://link.gitcode.com/i/4b6f6ee669e3580e4be5edea628ddaeb)）： | 命令 | 回答的问题 | SDLC 阶段 | 工件 | |---|---|---|---| | `/plan-prd` | *什么问题？为谁？怎么知道做完了？* | 需求 | `.claude/prds/{name}.prd.md` | | `/plan` | *哪些文件、模式、任务能满足需求？* | 设计 + 实现策略 | `.claude/plans/{name}.plan.md`（PRD 模式）或内联（文本模式） | 不合并的理由有四：**关注点分离**（PRD 问 why，计划问 how；旧版 `/prp-prd` → `/prp-plan` 的 8 阶段盘问把实现阶段表格混进需求文档，正反面教材）；**受众不同**（评审 PRD 的干系人不关心文件路径和类型检查命令；读计划的工程师不需要市场调研阶段）；**生命周期不同**（PRD 可以保持稳定，而计划会随实现假设变化被反复重写）；**可选性**（缺陷修复、小重构、单文件新增不需要 PRD，强制每个改动都写 PRD 是官僚主义）。 何时用 `/plan-prd`：范围不清晰或存在争议；多个干系人需要在动手前对齐问题；改动大到"把假设写下来比中途反复重议范围更便宜"。何时直接用 `/plan`：需求已明确（缺陷报告、有边界的重构、已知迁移）；改动小到对话式计划 + 确认门控足够；已有 PRD——直接传给 `/plan` 跳过 `/plan-prd`。 ## 端到端工作流：从想法到合入 PR ### 完整流程（范围不清晰的功能） ```bash # 1. 起草 PRD /plan-prd "为公共 API 增加按用户限流" # → .claude/prds/per-user-rate-limits.prd.md 已创建 # 回答框定问题、提供证据、定义假设与范围。 # 2. 选择下一个 pending 里程碑并生成计划 /plan .claude/prds/per-user-rate-limits.prd.md # → .claude/plans/per-user-rate-limits.plan.md 已创建 # 计划包含 Patterns to Mirror、Files to Change、Validation 命令。 # PRD 的 Delivery Milestones 表中选中行被更新为 in-progress。 # 3. 测试先行实现 使用 tdd-workflow 技能（skills/tdd-workflow/SKILL.md） # 4. 打开 PR /pr # → PR 正文自动引用 .claude/prds/... 与 .claude/plans/...快速流程（范围已清晰）
/plan "为 notifier 增加指数退避重试" # 对话式规划，无工件。确认后使用 tdd-workflow 技能。引用仓库中已有的 PRD
/plan docs/rfcs/0042-rate-limiting.prd.md【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
