HVE Core功能规划器详解PRD如何变成可执行的工作项层级【免费下载链接】hve-coreA refined collection of Hypervelocity Engineering components (instructions, prompts, agents, and skills) to start your project off right, or upgrade your existing projects to get the most out of GitHub Copilot项目地址: https://gitcode.com/GitHub_Trending/hv/hve-core如果你写过 PRD产品需求文档却经常卡在需求写完了工作项怎么拆这一步那么 HVE Core 的功能规划器Functional Planner值得你花10分钟了解。它是 HVE Core 中的只读规划代理能把一份 PRD 自动拆解为可直接落地的工作项层级Epic → Story → Task并生成可评审的交接文件支持 Azure DevOps、GitHub、Jira 三大工作追踪平台。全程不改动你的追踪器评审通过后才由执行环节创建工单——这是它最新手友好的设计。为什么需要 PRD 到工作项的自动化拆解传统的做法是产品文档写完后PM 手动打开 Azure DevOps 或 GitHub一条一条建 Epic、建 Story、填字段、挂父子关系。这个过程有三个典型痛点层级不一致同一份 PRD不同人拆出来的粒度五花八门平台割裂ADO、GitHub、Jira 各拆一遍词汇和字段完全不同规划与执行混在一起拆错一条追踪器里就多一条垃圾工单HVE Core 的思路是把拆和建彻底分开规划阶段只读执行阶段才写。官方在为什么背管有效中解释了这一设计——探索可以随时反复跑因为只读不会造成任何破坏所有风险集中到一个受控的执行环节。功能规划器在 HVE Core 中的位置HVE Core 按项目生命周期组织工具。PRD 到工作项的转化发生在分解Decomposition阶段位于产品定义之后、冲刺规划之前。官方生命周期指南见 Stage 4: Decomposition其中明确列出了各入口工具类型作用functional-plannerAgent从对话代理选择器选取从 PRD 规划工作项层级只读backlog-managerAgent跨追踪器的发现、分诊、背管/backlog-plan task-planSkill把分配给我的工作富集为实施交接/backlog-execute runSkill把评审过的交接文件应用到追踪器功能规划器的代理定义位于 .github/agents/project-planning/functional-planner.agent.md配套技能文档见 functional-planner skill 参考与 Functional Planner 代理参考。三步走从 PRD 到可执行层级第一步让功能规划器只读拆解 PRD在 Copilot Chat 的代理选择器中选中Functional Planner给出一份 PRD 路径即可。官方式示例来自 分解阶段指南将 docs/project-planning/customer-onboarding-v2.md 中的 PRD 转换为 Azure DevOps 工作项层级每个主要功能区域一个 Epic每项能力一个 User Story每个实施步骤一个 Task所有工单打上 onboarding-v2 标签。规划器会做四件事解析平台从工作区的 remote 与追踪目录.copilot-tracking/自动判断是 ADO、GitHub 还是 Jira无需你手动声明只读发现检查目标仓库现有 issue/工单避免重复创建Jira 场景还会做字段发现因为故事点等字段 ID 因实例而异选择拆解视角可选 generic通用、scrum 或 kanban 三种 lens 来塑造拆解粒度但最终工单类型和父子关系仍以平台实际支持的能力为准产出交接文件生成handoff.md等规划产物存放在.copilot-tracking/对应平台根目录下关键行为细节每条需求要么映射到一个计划工单要么被显式标记为缺口gap拿不准的字段或关系会被标为needs_review而不是猜测。这就是它比一次性生成类工具更可靠的原因。第二步人工评审交接文件交接文件是纯 Markdown你不同意某条建议时直接改一行文本即可而不是事后去追踪器里纠偏。规划产物与执行之间隔着这道评审层级方案在被创建之前就有机会被纠正。第三步用执行环节落地评审通过后运行/backlog-execute run真正创建层级。执行环节自带完整安全协议Dry-run 预览/backlog-execute run --dry-run先验证完整序列报告将会改变什么但不发任何调用自主性分级默认 Partial 档——字段/标签更新自动执行而创建工单、分配迭代、状态流转等操作需要你确认内容净化API 调用前剥离内部追踪引用防止规划期临时 ID 泄漏到工单内容里逐操作日志每完成一步都记录中断后重跑会跳过已完成操作不会创建重复项整个执行工作流的安全设计详见 Execution 工作流端到端串联发现→分诊→冲刺规划→执行见 Using Workflows Together。平台差异一次规划三处落地功能规划器替换了早期的ADO PRD to WIT和Jira PRD to WIT两个平台专属代理并补齐了它们都没有的 GitHub 支持见 PRD Planning Workflow 迁移说明。三个平台的迭代容器绑定不同概念Azure DevOpsGitHubJira迭代容器Iteration PathMilestoneSprint层级深度四级类型规则Issue 子 IssueEpic / Story / 子任务工作量字段Story Points无原生字段可用 size 标签约定实例级自定义字段 ID真正的平台能力缺口比如 GitHub Milestone 没有开始日期会被显式记录在规划文件中而不是悄悄近似处理——假设可见比假设隐藏更安全。新手上手建议从只读开始先用/backlog-plan discover摸底背管再上功能规划器学习曲线是渐进的工作流之间用/clear切换上下文每个工作流独立运行混用上下文结果不可靠PRD 要写清验收标准规划器不替你补需求它不撰写缺失的需求需求质量决定拆解质量GitHub 场景issue 创建后可批量加入 GitHub Project 看板做冲刺跟踪 想深入了解各规划代理BRD Builder、PRD Builder、Security Planner 等的职责分工可阅读 项目规划代理总览PRD 本身的编写方法见 BRD PRD Builders 指南。小结HVE Core 功能规划器把PRD → 可执行工作项层级这件高认知负荷的事拆成了只读规划 → 人工评审 → 受控执行三个可单独使用的环节。你不需要一次接受整套流水线哪怕只用它生成一份可评审的层级方案也已经比手动拆解更一致、更可追溯。【免费下载链接】hve-coreA refined collection of Hypervelocity Engineering components (instructions, prompts, agents, and skills) to start your project off right, or upgrade your existing projects to get the most out of GitHub Copilot项目地址: https://gitcode.com/GitHub_Trending/hv/hve-core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 HVE Core功能规划器详解：PRD如何变成可执行的工作项层级
HVE Core功能规划器详解PRD如何变成可执行的工作项层级【免费下载链接】hve-coreA refined collection of Hypervelocity Engineering components (instructions, prompts, agents, and skills) to start your project off right, or upgrade your existing projects to get the most out of GitHub Copilot项目地址: https://gitcode.com/GitHub_Trending/hv/hve-core如果你写过 PRD产品需求文档却经常卡在需求写完了工作项怎么拆这一步那么 HVE Core 的功能规划器Functional Planner值得你花10分钟了解。它是 HVE Core 中的只读规划代理能把一份 PRD 自动拆解为可直接落地的工作项层级Epic → Story → Task并生成可评审的交接文件支持 Azure DevOps、GitHub、Jira 三大工作追踪平台。全程不改动你的追踪器评审通过后才由执行环节创建工单——这是它最新手友好的设计。为什么需要 PRD 到工作项的自动化拆解传统的做法是产品文档写完后PM 手动打开 Azure DevOps 或 GitHub一条一条建 Epic、建 Story、填字段、挂父子关系。这个过程有三个典型痛点层级不一致同一份 PRD不同人拆出来的粒度五花八门平台割裂ADO、GitHub、Jira 各拆一遍词汇和字段完全不同规划与执行混在一起拆错一条追踪器里就多一条垃圾工单HVE Core 的思路是把拆和建彻底分开规划阶段只读执行阶段才写。官方在为什么背管有效中解释了这一设计——探索可以随时反复跑因为只读不会造成任何破坏所有风险集中到一个受控的执行环节。功能规划器在 HVE Core 中的位置HVE Core 按项目生命周期组织工具。PRD 到工作项的转化发生在分解Decomposition阶段位于产品定义之后、冲刺规划之前。官方生命周期指南见 Stage 4: Decomposition其中明确列出了各入口工具类型作用functional-plannerAgent从对话代理选择器选取从 PRD 规划工作项层级只读backlog-managerAgent跨追踪器的发现、分诊、背管/backlog-plan task-planSkill把分配给我的工作富集为实施交接/backlog-execute runSkill把评审过的交接文件应用到追踪器功能规划器的代理定义位于 .github/agents/project-planning/functional-planner.agent.md配套技能文档见 functional-planner skill 参考与 Functional Planner 代理参考。三步走从 PRD 到可执行层级第一步让功能规划器只读拆解 PRD在 Copilot Chat 的代理选择器中选中Functional Planner给出一份 PRD 路径即可。官方式示例来自 分解阶段指南将 docs/project-planning/customer-onboarding-v2.md 中的 PRD 转换为 Azure DevOps 工作项层级每个主要功能区域一个 Epic每项能力一个 User Story每个实施步骤一个 Task所有工单打上 onboarding-v2 标签。规划器会做四件事解析平台从工作区的 remote 与追踪目录.copilot-tracking/自动判断是 ADO、GitHub 还是 Jira无需你手动声明只读发现检查目标仓库现有 issue/工单避免重复创建Jira 场景还会做字段发现因为故事点等字段 ID 因实例而异选择拆解视角可选 generic通用、scrum 或 kanban 三种 lens 来塑造拆解粒度但最终工单类型和父子关系仍以平台实际支持的能力为准产出交接文件生成handoff.md等规划产物存放在.copilot-tracking/对应平台根目录下关键行为细节每条需求要么映射到一个计划工单要么被显式标记为缺口gap拿不准的字段或关系会被标为needs_review而不是猜测。这就是它比一次性生成类工具更可靠的原因。第二步人工评审交接文件交接文件是纯 Markdown你不同意某条建议时直接改一行文本即可而不是事后去追踪器里纠偏。规划产物与执行之间隔着这道评审层级方案在被创建之前就有机会被纠正。第三步用执行环节落地评审通过后运行/backlog-execute run真正创建层级。执行环节自带完整安全协议Dry-run 预览/backlog-execute run --dry-run先验证完整序列报告将会改变什么但不发任何调用自主性分级默认 Partial 档——字段/标签更新自动执行而创建工单、分配迭代、状态流转等操作需要你确认内容净化API 调用前剥离内部追踪引用防止规划期临时 ID 泄漏到工单内容里逐操作日志每完成一步都记录中断后重跑会跳过已完成操作不会创建重复项整个执行工作流的安全设计详见 Execution 工作流端到端串联发现→分诊→冲刺规划→执行见 Using Workflows Together。平台差异一次规划三处落地功能规划器替换了早期的ADO PRD to WIT和Jira PRD to WIT两个平台专属代理并补齐了它们都没有的 GitHub 支持见 PRD Planning Workflow 迁移说明。三个平台的迭代容器绑定不同概念Azure DevOpsGitHubJira迭代容器Iteration PathMilestoneSprint层级深度四级类型规则Issue 子 IssueEpic / Story / 子任务工作量字段Story Points无原生字段可用 size 标签约定实例级自定义字段 ID真正的平台能力缺口比如 GitHub Milestone 没有开始日期会被显式记录在规划文件中而不是悄悄近似处理——假设可见比假设隐藏更安全。新手上手建议从只读开始先用/backlog-plan discover摸底背管再上功能规划器学习曲线是渐进的工作流之间用/clear切换上下文每个工作流独立运行混用上下文结果不可靠PRD 要写清验收标准规划器不替你补需求它不撰写缺失的需求需求质量决定拆解质量GitHub 场景issue 创建后可批量加入 GitHub Project 看板做冲刺跟踪 想深入了解各规划代理BRD Builder、PRD Builder、Security Planner 等的职责分工可阅读 项目规划代理总览PRD 本身的编写方法见 BRD PRD Builders 指南。小结HVE Core 功能规划器把PRD → 可执行工作项层级这件高认知负荷的事拆成了只读规划 → 人工评审 → 受控执行三个可单独使用的环节。你不需要一次接受整套流水线哪怕只用它生成一份可评审的层级方案也已经比手动拆解更一致、更可追溯。【免费下载链接】hve-coreA refined collection of Hypervelocity Engineering components (instructions, prompts, agents, and skills) to start your project off right, or upgrade your existing projects to get the most out of GitHub Copilot项目地址: https://gitcode.com/GitHub_Trending/hv/hve-core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考