使用 awesome-copilot 的 breakdown-epic-pm 技能编写 Epic 级产品需求文档（PRD）
【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot
在大型 SaaS 平台的规划流程中，Epic 级 PRD 是从高层想法走向技术实现的第一个关键产物：它把模糊的业务愿景翻译成工程团队可以依赖的"唯一事实来源"，并作为生成技术架构规格的输入。本指南基于当前开源仓库 awesome-copilot 中的 breakdown-epic-pm 技能 展开，讲解如何让 GitHub Copilot 扮演资深产品经理，把一次性的 Epic 想法转化为结构完整、可直接驱动架构设计的 Markdown PRD。读完本文，你将掌握该技能的目标设定、八段式 PRD 结构、上下文模板的用法，以及它与仓库中架构拆解、功能级 PRD、项目计划和测试规划等配套技能的衔接方式。
技能定位：从 Epic 想法到 PRD 的翻译器
breakdown-epic-pm是 awesome-copilot 仓库skills/目录下的一个 Agent Skill。其SKILL.md的 frontmatter 中name为breakdown-epic-pm，description明确了职责边界："Prompt for creating an Epic Product Requirements Document (PRD) for a new epic. This PRD will be used as input for generating a technical architecture specification."——也就是说，该技能的输出不是终点而是起点，它生成的 PRD 会被进一步消费，用于产出 Epics 级技术架构规格。
该技能与同仓库的 breakdown-epic-arch（把 PRD 翻译成高层技术架构）、breakdown-feature-prd（把 Epic 中的 Feature/Enabler 细化成功能级 PRD）共同构成"先产品、后架构、再功能"的逐层拆解流水线，并被 project-planning 插件 打包为可一键安装的/project-planning:breakdown-epic-pm斜杠命令。
技能目标：以专家产品经理身份工作
SKILL.md的 Goal 部分要求 Agent 扮演"大型 SaaS 平台的专家产品经理"，核心职责是把高层想法翻译为详细的 Epic 级 PRD，并确立该 PRD 的地位：
- 作为工程团队的唯一事实来源（single source of truth）；
- 作为生成 Epic 级**技术架构规格（technical architecture specification）**的输入。
技能同时给出两条工作准则：
- 信息不足时主动提问：如果用户请求中的信息不足以覆盖 Epic 的各个方面，Agent 应提出澄清问题，而不是臆测填充。这与仓库中 first-ask、what-context-needed 等技能"先弄清范围再动手"的理念一脉相承。
- 完整输出：产出应是完整的、Markdown 格式的 Epic PRD。
输出格式与保存路径约定
该技能规定了标准化的落盘路径：
/docs/ways-of-work/plan/{epic-name}/epic.md其中{epic-name}是 Epic 的短名。这一路径约定并非孤例——仓库中的配套技能使用同一目录族：breakdown-epic-arch输出到/docs/ways-of-work/plan/{epic-name}/arch.md，breakdown-feature-prd输出到/docs/ways-of-work/plan/{epic-name}/{feature-name}/prd.md，breakdown-plan则产出project-plan.md与issues-checklist.md。统一的目录结构让"Epic 命名空间"下的产品文档、架构文档、功能文档与计划文档可以互相链接、层层追踪，这与 breakdown-plan 强调的"从 Epic 级规划到单个实现任务的完整可追踪性"目标完全一致。
Epic PRD 的八段式标准结构
SKILL.md定义了 8 个必需章节，逐一说明如下。
1. Epic Name（Epic 名称）
为 Epic 给出一个清晰、简洁且具描述性的名称。名称是后续所有文档（架构规格、功能 PRD、GitHub Issue）引用的锚点，应当一眼就能传达业务意图，例如"多租户计费重构"而不是"计费 2.0"。
2. Goal（目标）
目标章节必须拆成三个子项：
- Problem（问题）：用 3～5 句话描述该 Epic 要解决的用户问题或业务需求。要写到"为什么现在必须做"的程度。
- Solution（解决方案）：从高层解释 Epic 如何解决上述问题。此处不涉及具体技术选型——技术细节留给 breakdown-epic-arch 生成的架构规格。
- Impact（影响）：说明预期改善的成果或指标，例如用户参与度、转化率、收入等。为后续 Success Metrics 提供可度量的方向。
3. User Personas（用户画像）
描述该 Epic 的目标用户。画像应具体到可以支撑后面的用户旅程与验收判断：身份、使用场景、核心诉求与痛点。目标用户也可以在后续的 Context Template 中由用户预填初稿，再经 Agent 完善。
4. High-Level User Journeys（高层用户旅程）
描述该 Epic 启用的关键用户旅程与工作流。旅程是高层的端到端叙事（用户如何发现、使用、完成目标），不必细化到界面控件——那是功能级 PRD（见 breakdown-feature-prd 的 User Stories 章节）的职责。
5. Business Requirements（业务需求）
- Functional Requirements（功能需求）：从业务视角出发的详细清单，说明 Epic 必须交付什么。每条应明确、无歧义，可作为后续验收的依据。
- Non-Functional Requirements（非功能需求）：约束与质量属性清单，例如性能、安全、可访问性、数据隐私。质量属性在后续测试阶段会进一步对应到 breakdown-test 中引用的 ISO 25010 质量模型（功能适合性、性能效率、安全性、可维护性等八大特性），因此此处写得越具体，后续测试策略越有据可依。
6. Success Metrics（成功指标）
列出用于衡量 Epic 成败的关键绩效指标（KPIs）。这些指标应与第 2 章的 Impact 呼应，并最终在 breakdown-plan 的项目计划中以 "Success Criteria" 的形式落为可测的目标值。
7. Out of Scope（不在范围内）
明确列出本 Epic不包含的内容，以避免范围蔓延（scope creep）。显式的边界声明是大型规划文档专业性的体现：它既保护工程团队不被隐性需求突袭，也为后续功能拆解（哪些 Feature 放本 Epic、哪些放后续 Epic）提供了判断依据。
8. Business Value（业务价值）
给出业务价值的量级估计（例如 High / Medium / Low），并附简短理由。该估值会在 breakdown-plan 的"Priority and Value Matrix"中与优先级一起被翻译成 GitHub 标签（如value-high、value-medium、value-low），成为 Issue 自动化的输入。
Context Template 上下文模板
SKILL.md末尾提供了一段最小上下文模板，用于启动对话：
- **Epic Idea:** [A high-level description of the epic from the user] - **Target Users:** [Optional: Any initial thoughts on who this is for]Epic Idea是必填的用户输入，即 Epic 的高层描述——哪怕只有一两句话，Agent 也会据此展开，并在信息不足时提出澄清问题。Target Users是可选输入，用于预填用户画像的初步想法。
实际使用时，直接把这段模板粘贴到对话中并替换方括号内容即可，例如：
- **Epic Idea:** 为 B2B 客户提供自助式用量分析与账单导出能力，替代当前的邮件账单。 - **Target Users:** 企业客户的财务管理员与采购负责人。在拆解流水线中的位置：PRD 之后会发生什么
为了把breakdown-epic-pm的输出用到位，需要理解它在仓库"Epic > Feature > Story/Enabler > Test"规划层级中的上游与下游关系（该层级结构在 breakdown-plan 中有完整定义）：
- 输入：用户的一次性 Epic 想法 + 可选的目标用户初稿。
- 本技能：产出 Epic PRD（
epic.md）。 - 下游——架构：breakdown-epic-arch 以 Epic PRD 为输入，扮演资深软件架构师，产出高层架构规格（
arch.md），内容包括 Mermaid 系统架构图（用户层、应用层、服务层、数据层、基础设施层）、技术栈、技术价值与 T 恤尺码估算。其 Context Template 第一项就是 "Epic PRD:[The content of the Epic PRD markdown file]"——可见 PRD 是架构的硬性输入。 - 下游——功能：breakdown-feature-prd 从 Epic 中选取 Feature/Enabler，细化成功能级 PRD，其章节（Goal、User Personas、User Stories、Requirements、Acceptance Criteria、Out of Scope）与 Epic PRD 一脉相承，并增加了 Given/When/Then 形式的验收标准。
- 下游——计划与测试：breakdown-plan 汇总各产物生成 GitHub 项目计划与 Issue 清单；breakdown-test 基于 PRD、技术拆解与实现计划制定测试策略。
可以这样概括完整链路：Epic 想法 →（breakdown-epic-pm）→ Epic PRD →（breakdown-epic-arch）→ 架构规格 →（breakdown-feature-prd）→ 功能 PRD →（breakdown-plan / breakdown-test）→ 项目计划与测试策略。
安装与使用方式
该技能在仓库中的安装与启用有以下几种途径：
方式一：通过插件安装（推荐）
breakdown-epic-pm已被打包进 project-planning 插件（插件清单中extensions["com.github.awesome-copilot"].skills数组明确列出了./skills/breakdown-epic-pm/）。使用 Copilot CLI 安装插件：
copilot plugin install project-planning@awesome-copilot安装后即可通过斜杠命令/project-planning:breakdown-epic-pm触发，插件的命令说明见 plugins/project-planning/README.md。
方式二：作为独立 Skill 安装
根据 docs/README.skills.md 的说明，技能是包含SKILL.md指令文件的独立文件夹，可随需加载。安装方式：
- 使用 GitHub CLI：
gh skills install github/awesome-copilot breakdown-epic-pm（需要 GitHub CLI v2.90.0+）； - 或者将技能文件夹手动复制到本地 skills 目录。
使用方式：在对话中粘贴 Context Template 并填充 Epic 想法；Agent 会以产品经理身份展开 PRD，信息不足时先提问澄清，最终将完整 PRD 保存到约定的/docs/ways-of-work/plan/{epic-name}/epic.md路径，供后续架构拆解直接引用。
小结
breakdown-epic-pm解决的是大型 SaaS 规划中"从想法到可执行需求"的第一个落地问题：通过为 Agent 设定产品经理角色、强制八段式 PRD 结构、约定统一落盘路径与最小上下文模板，它保证了每个 Epic 都有内容完整、边界清晰、可直接驱动技术架构的 PRD 产出。配合 breakdown-epic-arch、breakdown-feature-prd、breakdown-plan 与 breakdown-test，团队即可在 GitHub Copilot 的支持下跑通从业务想法到架构、功能、计划与测试的完整规划流水线。
【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
