leikegeek/implementation-planning

---

name: implementation-planning displayName: 实施计划与任务拆解 description: 基于技术方案文档，将实施工作拆解为可执行的任务清单，对任务进行分类（基础设施/编码），将编码任务按业务边界归组生成子代理派发方案，定义测试策略，为 B2 编排模式做准备。 triggers: ["任务拆解", "实施计划", "开发计划"] autoTrigger: true version: '1.2.0'

实施计划与任务拆解

技能目标

将技术方案转化为可执行的任务清单，区分基础设施任务和编码任务，将编码任务按业务边界归组生成子代理派发方案，为 B2 编排模式做准备。

核心原则

1. 先分类后归组：先将任务分为基础设施任务和编码任务，只有编码任务参与业务边界归组
2. 依赖可见：明确标注任务间依赖和组间依赖，支持调度决策
3. 业务边界归组：将相关联的编码任务按业务模块归组，每组交给一个子代理在隔离上下文中执行
4. TDD 导向：每个编码任务包含对应的测试文件
5. 可追溯：每个任务关联需求编号和技术方案章节

Profile 补充

• 本 skill 只定义跨技术栈的拆解和派发方法。
• 后端项目叠加 backend-implementation-planning，细化接口、服务、数据访问、消息和迁移任务。
• 前端项目叠加 frontend-feature-implementation 及对应 Vue/React 专项 skill，细化页面、组件、状态和 API 联调任务。

工作流程

1. 分析技术方案

从技术方案文档中提取：

• 需要新增/修改/删除的文件或目录
• 涉及的工程层级（入口层、业务编排、数据/状态、UI/接口、基础设施等，以当前项目画像为准）
• 数据、状态、接口或页面契约变更
• 涉及的业务模块/功能域
• 对应测试或验证方式

2. 拆解任务清单

每个任务包含：

任务ID：T-001
描述：实现订单筛选入口与请求参数校验
层级：入口层
业务模块：订单筛选
影响文件：path/to/entry-file
测试文件：path/to/entry-test
依赖：无
TDD：写入口行为测试 → 实现最小逻辑 → 验证通过

3. 任务分类

将所有任务分为两类，决定后续的处理方式：

基础设施任务（由主 Agent 在编排模式下直接执行）：

• 项目搭建（脚手架、目录结构初始化）
• 数据库迁移（schema 创建、Alembic/Flyway 迁移脚本）
• 配置初始化（配置文件、环境变量、CI/CD 脚本）
• 依赖管理（pom.xml / package.json / pyproject.toml 变更）
• 全局公共基础设施（工具类、通用异常处理、全局拦截器、构建配置、全局样式或运行时配置）

编码任务（参与业务边界归组，委派子代理执行）：

• 业务逻辑实现（后端接口/服务/数据访问、前端页面/组件/状态等）
• API 接口开发
• 业务领域模型、页面模型或状态流实现
• 业务相关的测试编写

分类原则：基础设施任务通常是后续编码任务的前置依赖，且不属于某个特定业务模块。如果一个任务既涉及基础设施又涉及业务逻辑，按主要职责归类。

4. 标注依赖关系

生成依赖图，明确：

• 哪些任务无依赖（独立）
• 哪些任务必须顺序执行（有依赖）
• 任务间的依赖方向
• 基础设施任务与编码任务之间的依赖

依赖标注格式：

[基础设施] T-001 (独立)
[基础设施] T-002 (依赖 T-001)
[编码-订单模块] T-003 (依赖 T-002) ─┐
[编码-订单模块] T-004 (依赖 T-002) ─┤
[编码-通知模块] T-005 (依赖 T-002) ─┘
[编码-集成] T-006 (依赖 T-003, T-005)

5. 业务边界归组与派发方案

仅对编码任务按所属业务模块/功能域归组，生成子代理派发方案：

归组规则：

• 影响同一业务链路的入口、业务逻辑、数据/状态和测试任务归为一组
• 前后端分离的项目中，前端和后端各自作为独立的业务边界组
• 跨模块的集成任务（如多模块联调）单独标记为"顺序执行"组
• 每组内部标注执行顺序（按组内任务间的依赖关系排序）

组间依赖标注：

• 标注哪些组的产出是其他组的前置依赖
• 标注组间传递的接口、组件、状态或数据契约
• 基于组间依赖生成建议派发顺序（拓扑排序）

派发判定：

• 编码任务的业务边界分组数 >= 2 → 建议进入编排模式（主 Agent 转为编排者，逐组串行派发子代理）
• 编码任务的业务边界分组数 < 2 → 建议主 Agent 直接执行（拆子代理的上下文隔离收益不足以覆盖调度开销）

6. 定义测试策略

结合 testing skill，确定：

• 核心路径测试用例
• 边界条件测试用例
• 异常场景测试用例
• Mock 策略（哪些依赖需要 mock）

产出

# 实施计划 SV-xxxxx

## 任务清单

### 基础设施任务（主 Agent 直接执行）

| 任务ID | 描述 | 影响文件 | 依赖 |
|--------|------|----------|------|
| T-001  | 项目脚手架搭建 | ... | 无 |
| T-002  | 数据库 schema 迁移 | ... | T-001 |

### 编码任务（参与业务边界归组）

| 任务ID | 描述 | 层级 | 业务模块 | 影响文件 | 依赖 |
|--------|------|------|---------|----------|------|
| T-003  | 订单筛选入口 | 入口层 | 订单筛选 | ... | T-002 |
| T-004  | 订单筛选业务逻辑 | 业务层 | 订单筛选 | ... | T-002 |
| T-005  | 结果通知逻辑 | 业务层 | 通知服务 | ... | T-002 |

## 依赖图
（mermaid 图或文本依赖图，区分基础设施和编码任务）

## 子代理派发方案

### 派发判定
- 任务总数：N 个，其中基础设施任务 X 个，编码任务 Y 个
- 编码任务业务边界分组数：Z 个
- 判定结果：>= 2 组，建议进入编排模式 / < 2 组，建议主 Agent 直接执行

### 分组

| 组ID | 业务边界 | 包含任务 | 组内顺序 | 组间依赖 |
|------|---------|---------|---------|---------|
| G-01 | 订单筛选核心链路 | T-003, T-004, T-008 | T-004 → T-003 → T-008 | 无 |
| G-02 | 通知联动链路 | T-005, T-006 | T-005 → T-006 | 依赖 G-01（使用订单筛选结果契约） |
| G-03 | 展示与交互链路 | T-009, T-010, T-011 | T-009 → T-010 → T-011 | 依赖 G-01（使用查询接口或状态契约） |
| 顺序执行 | 跨模块集成 | T-007, T-012 | T-007 → T-012 | 依赖 G-01 + G-02 |

### 组间接口契约
- G-01 → G-02：订单筛选结果契约
- G-01 → G-03：`POST /api/orders/filter` 接口定义
- G-01 + G-02 → 顺序执行组：各模块的集成契约

### 建议派发顺序
G-01 → G-02 → G-03 → 顺序执行组（**组间默认串行**；与 `commands/code.md` B2 一致：仅当用户明确确认「允许并行」时才可改为对无依赖组同时派发）

## 测试策略摘要
（核心测试点和 Mock 策略）