implementation-planning

实施规划

将已批准的需求或规范转化为可执行的交付计划。 这项技能是一门规划规范——产出的是计划，不是代码、规范，也不是生命周期编排。

何时加载此技能

当输入为已批准的需求、规范或决策，且任务是制定一份考虑依赖关系、顺序安排、风险和验证的具体交付计划时，加载此技能。

触发条件	示例
需要为已批准的 SPEC.md 或产品简报制定交付计划	“为支付结账规范规划实施方案”
跨团队或多仓库功能需要协调工作	“规划身份迁移变更在三个服务中的推出方案”
数据迁移需要分阶段执行计划	“规划包含回滚阶段的架构迁移”
高风险或影响重大的变更需要推出策略	“规划身份验证提供方替换的分阶段推出方案”
多个工作流需要依赖关系映射和关键路径分析	“梳理平台升级的依赖关系和关键路径”

何时不应使用

• 批准前的探索或需求挖掘——输入尚不是已批准的需求。转至 product-discovery。
• 从头编写规范——目前还没有已批准的规范。转至 spec-driven-development。
• 编码、实施或架构设计——计划已经完成，现在该执行了。转至 backend-engineering、frontend-engineering 或 software-architecture-analysis。
• neckbeard 从问题到 PR 的交付流程——此技能负责规划工作，不负责执行 neckbeard 生命周期关卡、交付包排序或阶段编排。交付执行是另一项工作。
• 前置决策尚未获批——如果需求或规范尚未获批，请停止。规划未批准的工作是明确的停止条件。记录缺少的审批并升级处理；不要制定计划。
• 整个运行需要控制平面协议——围绕计划及其执行所需的意图约定、工作分类、自主性门控、以分流为目的的审查和失败路由。转至 bmad。此技能负责产出交付计划；bmad 负责端到端运行从意图到交付的协议。

规划完成后，如需进行持续的里程碑审查、预测变更、赞助人决策和项目收尾，请转至 technical-project-management。 如需协调多个相关项目、共享产能、项目群收益或转型成果，请转至 technical-program-management。 详细的工作分解和依赖计划维护仍由此处负责。

入口关卡：前置审批

开始任何规划工作之前，请确认输入的需求或规范已由有权决策者批准。已批准的输入是指已通过审查关卡的内容（SDD 规范审查、产品简报批准、架构决策记录获接受，或同等流程）。

如果输入尚未批准：

1. 停止。 不要产出计划草案、部分工作分解，或“假定已批准”的材料。
2. 明确说明缺少的审批：待定的决策是什么，以及必须由谁（角色或姓名）批准。
3. 转至相应的上游技能：
   • 尚无规范 → spec-driven-development
   • 需求尚未验证 → product-discovery
   • 架构决策尚未确定 → adr-authoring

设置此关卡是因为，建立在未获批准的基础上的计划会浪费所有下游团队的时间，并制造虚假的确定性。

核心工作流

1. 接收已批准的输入。 阅读已批准的需求、规格说明或决策记录。记录来源、批准日期、批准人，以及任何明确的约束或非目标。

2. 分解为工作项。 将已批准的范围拆分为可独立交付价值的垂直切片或工作流。优先采用垂直切片（端到端能力），而不是水平分层（先数据库，再 API，最后 UI）。每个切片都必须有明确的完成标准。

3. 梳理依赖关系。 找出所有依赖：上游输入、下游使用方、共享服务、数据存储、平台能力、团队可用性，以及外部供应商或合作团队。区分硬依赖（阻塞项）和软依赖（偏好项）。将它们记录在依赖记录中。

4. 确定关键路径。 梳理决定最早完成时间的最长依赖工作链。标记任何一旦延迟就会推迟关键路径的依赖。

5. 分配负责人。 每个工作流和每项依赖都必须有负责人。负责意味着对完成情况承担责任，不一定要亲自执行工作。按姓名或角色记录负责人。

6. 安排顺序并行化。 按照依赖关系安排工作顺序，并尽可能提高并行度。明确哪些切片可以并行开展，哪些必须按顺序进行，以及并行轨道需要在哪里同步。

7. 设计发布策略。 定义变更如何进入生产环境：一次性发布、分阶段发布（按客户、地区或百分比）、金丝雀发布、通过功能标志控制，或组合使用。定义每个阶段的发布步骤、门槛和时长。

8. 设计回滚与恢复方案。 为每个发布阶段定义回滚路径：什么情况会触发回滚、如何执行、需要多长时间，以及回滚后会留下什么状态。适用时还应包含数据回滚。

9. 根据原始需求进行验证。 将每个工作流追溯到已批准的输入。确认没有遗漏，也没有纳入额外内容。记录任何有意作出的范围决策。

10. 识别尚未解决的决策和风险。 列出规划期间无法解决的所有决策，以及所有残余风险。为每项指定负责人和解决期限。

产出

实施计划包含以下部分。模板位于 templates/。

产出	模板	用途
工作拆分	templates/implementation-plan-template.md	垂直切片、工作流、完成标准、负责人
依赖与交接记录	templates/dependency-record.md	依赖关系图、关键路径、团队间交接约定
风险、决策与验证记录	templates/risk-decision-verification.md	风险、尚未解决的决策、假设、验证清单

跨团队与跨仓库规划

此技能不假定只有一个仓库或团队。当已批准的需求涉及多个仓库、团队或组织时：

• 将每个仓库或团队边界视为一个依赖接口——定义其约定（API、架构、事件或交接材料）及负责人。
• 规划集成检查点，在这些节点共同验证跨团队工作，而不只是在最后验证。
• 明确指出协调机制：共享日历、同步会议、Slack 频道或状态仪表板。
• 对于迁移，纳入切换策略（并行运行、一次性切换、分阶段迁移）和回填／对账计划。

分阶段推出与迁移规划

当变更存在重大风险时，计划必须包含分阶段推出策略。请参阅 references/discovery-brief.md，了解此技能的推出规划与 release-engineering 的流水线设计及 site-reliability-engineering 基于 SLO 的渐进式推出之间的关系。

分阶段推出计划至少应定义：

• 阶段：阶段数量、每个阶段的门槛条件，以及各阶段的持续时间。
• 可观测性：用于确认各阶段运行正常的指标、日志或信号。
• 回滚触发条件：每个阶段触发回滚的具体条件。
• 恢复路径：如何回滚数据、配置和流量。

对于数据迁移，还应包含：

• 过渡期间的双写或回填策略。
• 迁移期间的架构兼容性（向前和向后兼容）。
• 移除旧路径之前的切换与核对。

移交给专业技能

此技能产出一份计划。专业技能负责执行计划。规划与执行之间的移交是一条明确的边界——不要让规划延伸到实施阶段。

当计划涵盖……	移交给
规范撰写或正式阶段门槛	spec-driven-development
未经验证需求的发现	product-discovery
QA 策略、测试规划或验证设计	qa-methodology
计划相关的意图契约、自主性门控或故障路由	bmad
发布流水线、晋级门槛或金丝雀机制	release-engineering
内部开发者平台或 CI/CD 基础设施	platform-engineering
安全要求、威胁建模或安全设计	secure-software-engineering
可靠性目标、SLO、事件响应或运营就绪度	site-reliability-engineering
需要正式 ADR 的架构决策	adr-authoring
API 契约设计或演进	api-design-and-evolution
数据流水线、架构或存储设计	data-engineering

如果上面列出的某项专业技能已负责计划中的某个部分（例如，推出机制由 release-engineering 负责），此技能会引用该专业技能的产出，而不会重新推导。计划会注明专业技能产物及其负责人；不会重复专业技能的方法。

文件索引

路径	加载时机
references/discovery-brief.md	了解此技能负责的内容，以及移交给相邻技能的内容
templates/implementation-plan-template.md	制定完整的实施计划
templates/dependency-record.md	梳理依赖关系、关键路径和移交契约
templates/risk-decision-verification.md	记录风险、未解决的决策和验证可追溯性