SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场implementation-planning

implementation-planning

编程与开发

查看项目

更新于 10-16 04:27

技能介绍

用途

Implementation Planning 技能用于创建可执行的实施计划（PLAN），将功能拆解为遵循 TDD 原则的可执行任务。其目标是让开发者能够独立按照计划工作，无需额外澄清。

主要能力

  • 从模板创建新的 PLAN
  • 完成已有 implementation-plan.md 中的阶段
  • 定义任务顺序与依赖关系
  • 规划 TDD 循环（Prime → Test → Implement → Validate）
  • 处理 docs/specs/ 目录下的任何 implementation-plan.md 文件

计划完成标准

一个计划在满足以下条件时视为完成：

  • 开发者可以独立遵循，无需额外上下文
  • 每个任务产生可验证的交付物（而非仅活动）
  • 所有 PRD 验收标准映射到具体任务
  • 所有 SDD 组件都有对应的实施任务
  • 依赖关系明确，不存在循环依赖

使用方式

模板

PLAN 模板位于 template.md，需严格使用该结构。将模板写入规格目录的步骤：

  1. 读取模板：plugins/start/skills/implementation-plan/template.md
  2. 写入规格目录：docs/specs/[NNN]-[name]/implementation-plan.md

计划重点

计划必须回答以下问题：

  • WHAT 产生价值？（交付物，而非活动）
  • IN WHAT ORDER 任务按什么顺序执行？（依赖与排序）
  • HOW TO VALIDATE 如何验证正确性？（测试优先方法）
  • WHERE 每个任务在哪里被规定？（链接到 PRD/SDD 章节）

保持计划可执行且聚焦：使用任务描述、顺序和验证标准；省略时间估算、资源分配和实施代码。

任务粒度原则

跟踪产生可验证结果的逻辑单元。TDD 循环是执行方法，而非单独跟踪的条目。

好的跟踪单元（产生结果）：

  • "Payment Entity" → 产生：带测试的可工作实体
  • "Stripe Adapter" → 产生：带测试的可工作集成
  • "Payment Form Component" → 产生：带测试的可工作 UI

不好的跟踪单元（过于细碎）：

  • "Read payment interface contracts" → 准备工作，非交付物
  • "Test Payment.validate() rejects negative amounts" → 属于更大结果的一部分
  • "Run linting" → 验证步骤，非交付物

结构模式

- [ ] **T1.1 Payment Entity** `[activity: domain-modeling]`

  **Prime**: Read payment interface contracts `[ref: SDD/Section 4.2; lines: 145-200]`

  **Test**: Entity validation rejects negative amounts; supports currency conversion; handles refunds

  **Implement**: Create `src/domain/Payment.ts` with validation logic

  **Validate**: Run unit tests, lint, typecheck

复选框跟踪 "Payment Entity" 作为一个单元，Prime/Test/Implement/Validate 是嵌入的指导。

TDD 阶段结构

每个任务遵循以下模式中的红-绿-重构：

  1. Prime Context：阅读相关规格章节，理解接口与契约，加载模式与示例
  2. Write Tests (Red)：在实现前测试行为，引用 PRD 验收标准，覆盖正常路径与边界情况
  3. Implement (Green)：构建以通过测试，遵循 SDD 架构，使用已发现的模式
  4. Validate (Refactor)：运行自动化测试，检查代码质量（lint、format），验证规格符合性

任务元数据

在计划中使用以下标注：

- [ ] T1.2.1 [Task description] `[ref: SDD/Section 5; lines: 100-150]` `[activity: backend-api]`
元数据 描述
[parallel: true] 可并发运行的任务
[component: name] 用于多组件功能
[ref: doc/section; lines: X-Y] 链接到规格
[activity: type] 用于专家选择的提示

循环模式

对每个需要定义的阶段，遵循以下迭代过程：

  1. 发现阶段：阅读 PRD 和 SDD 以理解需求与设计；识别每个实施领域所需的活动；启动并行专家代理调查任务排序与依赖、测试策略、风险评估、验证方法
  2. 文档阶段：用任务定义更新 PLAN；添加规格引用（[ref: ...]）；仅聚焦当前正在定义的阶段；严格遵循模板结构
  3. 审查阶段：向用户展示任务拆解；展示依赖与排序；突出并行机会；等待用户确认后再进入下一阶段

每个循环自问：是否已阅读相关 PRD 和 SDD 章节？所有任务是否可追溯到规格需求？任务间依赖是否清晰？并行任务是否真能并行运行？每个阶段是否包含验证步骤？是否已获得用户确认？

规格符合性

每个阶段应包含一个验证任务：

- [ ] **T1.3 Phase Validation** `[activity: validate]`

  Run all phase tests, linting, type checking. Verify against SDD patterns and PRD acceptance criteria.

对于复杂阶段，验证嵌入在每个任务的 Validate 步骤中。

偏差协议

当实施需要偏离规格时：记录偏差并给出明确理由；在继续前获得批准；当偏差改进设计时更新 SDD；在计划中记录所有偏差以便追溯。

验证清单

完整清单见 validation.md。关键门槛：

  • 所有规格文件路径正确且存在
  • 上下文准备章节完整
  • 所有实施阶段已定义
  • 每个阶段遵循 TDD：Prime → Test → Implement → Validate
  • 阶段间依赖清晰（无循环依赖）
  • 并行工作正确标记 [parallel: true]
  • 提供活动提示用于专家选择 [activity: type]
  • 每个阶段引用相关 SDD 章节
  • 每个测试引用 PRD 验收标准
  • 最终阶段定义集成与 E2E 测试
  • 项目命令与实际项目设置匹配
  • 开发者可以独立遵循此计划

输出格式

PLAN 工作完成后报告：

📋 PLAN Status: [spec-id]-[name]

Phases Defined:
- Phase 1 [Name]: ✅ Complete (X tasks)
- Phase 2 [Name]: 🔄 In progress
- Phase 3 [Name]: ⏳ Pending

Task Summary:
- Total tasks: [N]
- Parallel groups: [N]
- Dependencies: [List key dependencies]

Specification Coverage:
- PRD requirements mapped: [X/Y]
- SDD components covered: [X/Y]

Next Steps:
- [What needs to happen next]

适用场景

  • 从模板创建新的 PLAN
  • 完成已有 implementation-plan.md 中的阶段
  • 定义任务序列与依赖
  • 规划 TDD 循环
  • 处理 docs/specs/ 下的 implementation-plan.md 文件

限制

  • 计划省略时间估算、资源分配和实施代码
  • 需要 PRD 和 SDD 作为输入
  • 偏差需获得批准并记录
  • 示例参考见 examples/phase-examples.md，验证清单见 validation.md