CCPM Plan 阶段实战从头脑风暴到 PRD再到可分解的技术 Epic【免费下载链接】ccpmProject management skill system for Agents that uses GitHub Issues and Git worktrees for parallel agent execution.项目地址: https://gitcode.com/GitHub_Trending/ccpm/ccpmPlan规划是 CCPMClaude Code Project Manager五阶段规范驱动开发流程的第一环其核心任务是把一个模糊的想法固化为结构化的 PRD产品需求文档再进一步解析为面向技术实现的技术 Epic。本文以 CCPM 技能包中的 plan.md 为骨架完整讲解 PRD 的编写规范、PRD 到 Epic 的解析流程、质量门槛与编辑守则并结合仓库中的 conventions.md 与配套脚本给出可复制的操作细节。读完本文你将掌握如何在任意 Agent 工作区中产出符合 CCPM 文件约定的 PRD 与 Epic为后续任务分解、GitHub 同步和并行执行铺平道路。CCPM 中的 Plan 阶段定位CCPM 把软件交付生命周期划分为五个阶段Plan捕获需求→ Structure分解任务→ Sync同步 GitHub→ Execute并行执行→ Track状态跟踪。正如 SKILL.md 所描述其核心哲学是需求存在于文件中而不是头脑中Requirements live in files, not heads每个功能先从 PRD 开始变成技术 Epic再分解为 GitHub Issues最终由并行 Agent 执行并保持全程可追溯。Plan 阶段覆盖两件事编写 PRD通过引导式头脑风暴把用户想法沉淀为带 frontmatter 的PRD: name文档解析 PRD把现有 PRD 转换为技术 Epic即.claude/epics/name/epic.md。整个阶段产生的所有文件都遵循统一的目录约定见 conventions.md 的 Directory Structure.claude/ ├── prds/ │ └── feature-name.md # 产品需求文档 └── epics/ ├── feature-name/ │ └── epic.md # 技术 Epic所有跨阶段文件操作frontmatter 结构、日期格式、命名规则都必须先查阅 conventions.md这些约定对 Plan 阶段同样生效。编写 PRD触发条件与预检查触发条件用户想要规划一个新功能、产品需求或工作领域。典型口语触发包括我想构建 X、为 X 写一个 PRD、帮我把这个范围定一下。动笔之前必须完成三项预检查Preflight查重检查.claude/prds/name.md是否已存在——如果存在必须先与用户确认是否覆盖不能静默覆盖已有文档建目录确保.claude/prds/目录存在不存在则创建校验命名功能名必须为 kebab-case小写、仅字母/数字/连字符、以字母开头。不符合时输出固定错误提示❌ Feature name must be kebab-case. Example: user-auth, payment-v2这一命名规则在 conventions.md 的 Naming Conventions 一节中也被强制约定功能名必须小写 kebab-case、与文件名一致。例如user-auth、payment-v2合法而UserAuth、payment_v2、2fa都不合法。头脑风暴先行plan.md 明确要求在写任何内容之前先进行一次真正的头脑风暴Conduct a genuine brainstorming session而不是直接套模板。向用户提出以下五个问题这个功能解决什么问题What problem does this solve?受影响的用户是谁Who are the users affected?成功长什么样What does success look like?明确排除在范围之外的是什么Whats explicitly out of scope?有哪些约束——技术、时间、资源What are the constraints?这五个问题分别对应 PRD 模板中的 Problem Statement、User Stories、Success Criteria、Out of Scope、Constraints Assumptions确保后续文档不是空泛套话而是有真实决策依据。这一先思考再落盘的流程正是 README.md 强调的No Vibe Coding原则在需求阶段的体现。PRD 文件结构与 frontmatter头脑风暴完成后写入.claude/prds/name.md。文件必须包含 frontmatter 与固定章节结构完整模板如下plan.md--- name: feature-name description: one-line summary status: backlog created: run: date -u %Y-%m-%dT%H:%M:%SZ --- # PRD: feature-name ## Executive Summary ## Problem Statement ## User Stories ## Functional Requirements ## Non-Functional Requirements ## Success Criteria ## Constraints Assumptions ## Out of Scope ## Dependencies逐字段说明namekebab-case 功能名与文件名一致description一句话摘要prd-list.sh 与 prd-status.sh 会把它直接展示在列表里因此要写得足够自解释status取值backlog、active或completedconventions.md 的 PRD Frontmatter Schema。plan.md 中新建 PRD 默认backlogcreated必须取系统真实当前时间禁止占位文本。统一使用命令date -u %Y-%m-%dT%H:%M:%SZ生成 ISO 8601 格式UTC这也是 conventions.md 的 Datetime Rule。说明run: ...是 CCPM 文档中的约定写法表示该字段由 Agent 在运行时执行命令生成而不是字面写入的字符串。正文九个章节中## Executive Summary执行摘要应给出一段凝练的全局说明## Problem Statement对齐头脑风暴第一个问题## User Stories用用户故事句式作为…我希望…以便…描述需求## Functional Requirements与## Non-Functional Requirements分别列功能性与非功能性需求## Success Criteria定义可衡量的验收指标## Constraints Assumptions记录约束与假设## Out of Scope显式列出不做的事## Dependencies记录对现有模块、外部服务或依赖项的依赖关系。保存前的质量门槛plan.md 定义了四条硬性质量门槛Quality gates未通过不得保存任何章节都不允许有占位文本No placeholder text in any section用户故事必须包含验收标准User stories include acceptance criteria成功标准必须可衡量Success criteria are measurable范围外内容必须显式列出Out of scope is explicitly listed。这四条门槛把文档写完了与文档写对了区分开是后续解析为 Epic 时不再返工的前提。创建完成后的确认保存成功后向用户输出确认信息并主动给出下一步动作建议✅ PRD created: .claude/prds/name.md Ready to create technical epic? Say: parse the name PRD这样把 Plan 阶段的两个子流程自然地衔接起来。将 PRD 解析为技术 Epic触发条件与预检查触发条件用户希望把现有 PRD 转换为技术实施计划。典型触发语解析 X 的 PRD、为 X 创建 Epic。预检查包含两项验证 PRD 存在且 frontmatter 合法.claude/prds/name.md必须存在且 frontmatter 包含name、description、status、created四个字段与 conventions.md 的 PRD Schema 一致Epic 查重检查.claude/epics/name/epic.md是否已存在存在则先与用户确认是否覆盖。Epic 文件结构与 frontmatter完整阅读 PRD 后产出.claude/epics/name/epic.md模板如下plan.md--- name: feature-name status: backlog created: run: date -u %Y-%m-%dT%H:%M:%SZ progress: 0% prd: .claude/prds/name.md github: (will be set on sync) --- # Epic: feature-name ## Overview ## Architecture Decisions ## Technical Approach ### Frontend Components ### Backend Services ### Infrastructure ## Implementation Strategy ## Task Breakdown Preview ## Dependencies ## Success Criteria (Technical) ## Estimated Effort与 PRD 相比Epic 的 frontmatter 新增了几个关键字段对照 conventions.md 的 Epic Frontmatter Schemaprogress进度百分比新建时为0%后续在任务关闭时按closed / total重新计算prd指向来源 PRD 的路径形成 PRD → Epic 的可追溯链github同步到 GitHub 后填入 Epic Issue 的 URL占位说明(will be set on sync)表示该字段在 Sync 阶段由同步脚本写入见 sync.mdupdatedEpic 每次被编辑时更新的时间戳plan.md 的 Editing 一节要求维护此字段。正文章节则从产品视角切换到技术视角## Architecture Decisions记录关键架构决策与取舍## Technical Approach分 Frontend Components、Backend Services、Infrastructure 三个子层描述技术方案## Implementation Strategy给出实施策略## Task Breakdown Preview是后续 Structure 阶段任务分解的预览## Success Criteria (Technical)定义技术验收标准## Estimated Effort给出工作量估算。三条关键约束plan.md 为 Epic 解析定义了三条约束直接决定后续任务分解的形态任务总量 ≤ 10 个优先简单而非完备prefer simplicity over completeness。这一约束与 structure.md 中小 Epic5 任务顺序创建、中等 Epic5–10 任务分批并行的策略相呼应——超过 10 个任务的 Epic 会显著增加并行协调成本优先复用已有功能在写新代码之前先寻找可复用的现有能力leverage existing functionality避免重复造轮子在任务分解预览中识别并行化机会提前标注哪些任务可以并行为 Structure 阶段设置parallel: true/depends_on/conflicts_with元数据做准备。创建完成后的确认✅ Epic created: .claude/epics/name/epic.md Ready to decompose into tasks? Say: decompose the name epic至此Plan 阶段闭环想法 → 头脑风暴 → PRD → Epic并自然导向下一阶段 Structure任务分解。编辑 PRD 或 Epicplan.md 最后给出编辑守则先读文件再做定向编辑保留所有 frontmatter并更新updated字段为当前时间。结合 conventions.md 的 Frontmatter Update Pattern单字段更新推荐用sed原地替换sed -i.bak /^field:/c\\field: value file rm file.bak例如把某个 Epic 的status改为activesed -i.bak /^status:/c\\status: active .claude/epics/name/epic.md rm .claude/epics/name/epic.md.bak注意事项切勿整体重写文件或删掉 frontmatter 字段——prd、github、progress等字段是后续阶段脚本如 epic-status.sh读取元数据的依据编辑后同步更新updatedEpic/Task 必含该字段PRD 若需要记录修改时间也应维护它需要把 frontmatter 剥离出来给 GitHub 用Sync 阶段场景时使用 conventions.md 提供的双段剥离命令sed 1,/^---$/d; 1,/^---$/d file /tmp/body.mdPlan 阶段的配套脚本佐证Plan 阶段产出的 PRD 与 Epic会在后续 Track 阶段由确定性 bash 脚本读取和展示这也反向约束了本阶段的文件格式必须严格合规。从源码可以看到这些脚本对 frontmatter 字段的依赖prd-list.sh 按status字段把 PRD 分组为 Backlog / In-Progress / Implemented并读取name、description展示——因此新建 PRD 时status: backlog与可读的description缺一不可prd-status.sh 统计各状态 PRD 数量并绘制条形图还会依据状态给出下一步建议如backlog数量 0 时建议Parse backlog PRDs to epics恰好衔接 Plan → Structureepic-list.sh 读取epic.md的name、status、progress、github字段并按状态分组展示同时统计 Epic 目录下的任务文件数量——可见 Epic 解析时把progress: 0%写好、把任务目录结构留好后续统计才能正确工作epic-status.sh 解析epic.md的status/progress/github遍历[0-9]*.md任务文件统计 total / closed / open / blocked 并渲染进度条validate.sh 会校验所有 PRD/Epic 文件是否包含 frontmatter、是否有孤儿任务文件、depends_on引用的任务是否存在——这再次印证 Plan 阶段留下的每一个字段、每一条依赖都会被机器化校验格式即契约。此外若项目尚未初始化.claude/不存在track.md 要求先运行 init.sh它会创建prds/、epics/等目录结构并检查 gh CLI 与认证确保 Plan 阶段的目录约定就绪。小结Plan 阶段的最佳实践清单先头脑风暴后写文档——五个引导问题全部对齐后再落盘命名严守 kebab-case否则直接报错拒绝PRD 与 Epic 的 frontmatter 严格遵循 conventions.md 的 Schema时间用date -u %Y-%m-%dT%H:%M:%SZ生成过质量门槛再保存无占位文本、用户故事带验收标准、成功标准可衡量、Out of Scope 显式列出Epic 控制在 ≤10 个任务、优先复用、预判并行化编辑走定向 sed 更新保留 frontmatter 并维护updated字段把确认 下一步建议输出给用户引导进入decompose the name epic的 Structure 阶段。Plan 阶段产出的.claude/prds/name.md与.claude/epics/name/epic.md将作为后续任务分解structure.md、GitHub 同步sync.md、并行执行execute.md与状态跟踪track.md的唯一事实来源——写好这一份文档等于为整条规范驱动交付流水线打下了可追溯的地基。【免费下载链接】ccpmProject management skill system for Agents that uses GitHub Issues and Git worktrees for parallel agent execution.项目地址: https://gitcode.com/GitHub_Trending/ccpm/ccpm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考