企业官网建设流程全解析

awesome-copilot 之 breakdown-feature-prd 技能：基于 Epic 自动生成高质量 Feature 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

导读

本文围绕 awesome-copilot 仓库中 breakdown-feature-prd 技能 展开，讲解如何让 GitHub Copilot 扮演资深产品经理，把 Epic 中的高层级功能想法拆解成一份可供工程团队直接落地、并可进一步生成技术规格说明的 Feature PRD。读完本文，你将掌握该技能的触发方式、PRD 八大章节的标准结构、上下文输入模板，以及它在前置 Epic 规划、后置实现计划与测试规划这一完整工作流中的位置，还能结合仓库源码理解技能的元数据约定与校验机制。

技能定位：从 Epic 到 Feature 的产品需求翻译机

在大型 SaaS 平台中，Epic 描述的是一个横跨多个功能、需要多个迭代交付的大能力，而单个 Feature 才是工程团队真正要落地的交付单元。breakdown-feature-prd技能的核心使命，正是充当两者之间的"翻译机"：

• 输入：Epic 中某一条高层级 feature 或 enabler 的粗略想法，加上父级 Epic 文档；
• 输出：一份结构化、无歧义的 Feature PRD，保存为 Markdown 文档，作为工程团队的唯一事实来源（single source of truth），并作为后续生成技术规格说明的输入。

该技能在 SKILL.md 中明确要求 Agent 以"大型 SaaS 平台资深产品经理"的身份工作，并在信息不足时主动提出澄清问题，确保功能的所有方面在进入开发前被充分定义——这避免了常见的"需求一句话、开发全靠猜"问题。

技能元数据与仓库校验机制

每个技能都是一个自包含文件夹，内含一份SKILL.md指令文件，Agent 按需加载（渐进式披露）。breakdown-feature-prd的元数据定义如下：

--- name: breakdown-feature-prd description: 'Prompt for creating Product Requirements Documents (PRDs) for new features, based on an Epic.' ---

这份 frontmatter 并非摆设，仓库的 validate-skills.mjs 会严格校验每个技能：

• name必须是只含小写字母、数字和连字符的字符串，且必须与技能文件夹名完全一致（校验逻辑见 validate-skills.mjs）；
• description必须满足最小与最大长度约束（见 validate-skills.mjs）；
• 技能文件夹内必须存在SKILL.md，且 frontmatter 必须能被解析；
• 捆绑资源（assets）单个文件不得超过 5MB（见 validate-skills.mjs）。

也就是说，description中"Prompt for creating Product Requirements Documents (PRDs) for new features, based on an Epic"这一句话，既是给 Agent 的功能提示，也是通过仓库校验的必需字段。

输出位置约定

技能规定输出为完整 Markdown 格式的 PRD，保存到：

/docs/ways-of-work/plan/{epic-name}/{feature-name}/prd.md

路径中的{epic-name}与{feature-name}为占位符，分别替换为实际 Epic 名称与功能名称。这一约定与仓库中同系列的 breakdown 技能保持完全一致（可对比 breakdown-epic-pm 输出的epic.md、breakdown-epic-arch 输出的arch.md、breakdown-feature-implementation 输出的implementation-plan.md），保证了整个规划目录树在docs/ways-of-work/plan/下整齐可寻。

PRD 八大章节结构详解

技能规定了 Feature PRD 的标准结构，共八个章节。每一节都有明确的填写要求，下面逐一展开。

1. Feature Name（功能名称）

为功能起一个清晰、简洁、有描述性的名称。名称应能独立表达功能语义，便于在后续 Issue、实现计划、测试计划中被引用。例如不要用"优化体验"这种含糊表述，而要用"支持从 URL 导入菜谱"这类可检索的名称。

2. Epic（父级 Epic）

链接到父级 Epic 的 PRD 与架构文档。这是需求追溯（traceability）的关键：Feature PRD 必须能够回溯到 Epic 层的业务目标与架构决策。在配套工作流中，Epic 层文档由 breakdown-epic-pm（产出 Epic PRD）与 breakdown-epic-arch（产出 Epic 架构规格）生成，Feature PRD 在此章节引用它们。

3. Goal（目标）

目标章节包含三个子项，均给出了明确的篇幅要求：

• Problem（问题）：用 3-5 句话描述该功能要解决的用户问题或业务需求。要求聚焦、量化，避免空泛；
• Solution（解决方案）：解释该功能如何解决上述问题，说明核心机制而非实现细节；
• Impact（影响）：说明期望改善的业务结果或指标，例如用户参与度（user engagement）、转化率（conversion rate）等，为后续成功度量提供锚点。

4. User Personas（用户画像）

描述该功能的目标用户。画像是用户故事的"主语来源"，定义得越具体，后续用户故事与验收标准就越可验证。建议包含用户角色、使用场景、核心诉求、能力背景等信息。

5. User Stories（用户故事）

用户故事必须遵循标准句式：

As a <user persona>, I want to <perform an action> so that I can <achieve a benefit>.

即"作为某用户画像，我想要执行某动作，以便获得某收益"。要求覆盖主路径与边界情况（primary paths and edge cases），确保 Happy Path 之外的异常场景也进入需求视野。

6. Requirements（需求）

需求拆分为两组：

• Functional Requirements（功能需求）：系统"必须做什么"的详细清单。技能特别强调"具体且无歧义"（specific and unambiguous），这是 PRD 作为工程唯一事实来源的底线；
• Non-Functional Requirements（非功能需求）：约束与质量属性清单，包括性能、安全、可访问性、数据隐私等。非功能需求决定了系统"做得多好"，常被遗漏却在后期返工成本极高。

7. Acceptance Criteria（验收标准）

为每条用户故事或主要需求提供一组验收标准。技能推荐两种清晰格式：

• Checklist（勾选清单）：可逐项勾选验证的测试性要求列表；
• Given/When/Then（给定/当/那么）：行为驱动开发（BDD）句式，例如"给定用户已登录，当用户从 URL 导入菜谱时，那么系统应成功解析并展示预览"。

验收标准将用于验证功能是否完整且正确，因此必须是可测试的，不能是"系统应表现良好"这类主观表述。

8. Out of Scope（范围外）

明确列出本功能不包含的内容，防止范围蔓延（scope creep）。这一章节看似简单，却是在多 Feature 并行时保持边界清晰、避免隐性承诺的有效工具。

Context Template 上下文模板

技能末尾给出了驱动 Agent 工作的上下文模板，用户只需填充三项即可启动：

- **Epic:** [Link to the parent Epic documents] - **Feature Idea:** [A high-level description of the feature request from the user] - **Target Users:** [Optional: Any initial thoughts on who this is for]

其中Target Users是可选项。若Feature Idea提供的信息不足以完成 PRD 各章节，技能要求 Agent 先提出澄清问题，而不是自行臆造需求。

在完整工作流中的位置：Epoch 式需求分解链

breakdown-feature-prd不是孤立存在的，它处于仓库中一套完整的"需求分解链"中间环节。从仓库中同系列的技能可以清晰看到这条链路：

从代码结构看，breakdown-plan 明确把 "Feature PRD" 列为输入之一，并定义 Epic → Feature → Story/Enabler → Test 的工作项层级；breakdown-test 也把 Feature PRD 列为测试规划的输入文档。因此可以推断：Feature PRD 的质量直接决定了下游实现计划、Issue 拆解与测试策略的质量，这正是该技能强调"具体且无歧义"的原因。

使用方式与安装

breakdown-feature-prd属于 Agent Skills（自包含指令文件夹）。参考 docs/README.skills.md 中的通用说明，安装与使用方式如下：

1. 安装技能（需要 GitHub CLI v2.90.0+）：

   gh skills install github/awesome-copilot breakdown-feature-prd

2. 或手动拷贝：将 skills/breakdown-feature-prd 文件夹整体复制到本地 skills 目录；

3. 触发使用：在提示中引用该技能，或让 Agent 自动发现它。之后按 Context Template 提供 Epic 链接、Feature 想法与目标用户信息，Agent 即会以产品经理身份产出完整的 Feature PRD 并写入约定路径。

实战要点小结

• 信息不足先澄清：技能明确要求 Agent 在信息不足时提问，这是产出高质量 PRD 的前提；
• 验收标准可测试：每条用户故事都要配套可勾选或 Given/When/Then 形式的验收标准，作为开发完成度的判定依据；
• 范围边界要显式：Out of Scope 与 Goal 同等重要，显式排除才能防范围蔓延；
• 衔接上下游文档：第 2 章节引用 Epic 文档，产出文档又会被实现计划与测试规划引用，形成完整追溯链；
• 遵守路径与命名约定：输出固定到docs/ways-of-work/plan/{epic-name}/{feature-name}/prd.md，name字段与文件夹名一致，才能通过仓库的 validate-skills.mjs 校验。

【免费下载链接】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