Implement - 代码实现技能

根据 plan 文档进行代码实现，或根据 test/review 的反馈进行修复。

核心原则

1. 严格遵循 Plan：按照已确认的 plan.md 中的 TODO 逐项实现
2. 架构一致：遵循项目整体既有的架构设计、模块边界与依赖方向
3. 模块化与可扩展：代码必须模块化，遵循 SOLID 原则和适当的设计模式
4. 最小变更：只实现 Plan 要求的内容，不做额外的"优化"或"改进"

前置条件

• 对应功能的 plan.md 必须已存在且状态为"已确认"
• 对应功能的 spec.md 应可访问
• 如果项目有统一文档目录，遵循现有约定；如果没有，建议使用 spec/<spec-name>/plan.md
• 如果 plan 不存在，提示用户先执行 /plan

工作流程

模式一：按 Plan 实现新功能

1. 阅读上下文

   • 阅读对应功能的 spec.md 和 plan.md
   • 阅读项目级背景文档（如 PRD、roadmap、里程碑文档；如果存在）
   • 阅读现有代码，理解项目结构、命名规范、编码风格
   • 阅读团队沉淀文档（如 lessons learned、pitfalls；如果存在），避免已知坑

2. 确认 TODO 范围

   • 向用户确认本次要实现哪些 TODO（可能不是一次性全部实现）
   • 按照 Plan 中的依赖关系确定执行顺序

3. 逐项实现

   • 按 TODO 顺序逐一编写代码
   • 每完成一个 TODO，运行相关的验证或测试
   • 如果项目使用勾选式计划文档，每完成一个 TODO，立即在 plan.md 中将对应的 - [ ] 勾选为 - [x]，实时反映进度
   • 遇到 Plan 未覆盖的技术细节，向用户澄清后再继续

4. 自查

   • 确保代码可编译、可构建或可运行
   • 确保已有测试或验收流程不被破坏
   • 检查是否引入明显的安全风险（如注入、越权、敏感信息泄露）

模式二：根据反馈修复

当输入来源是 test 报告（test.md）或 review 报告（review.md）时：

1. 阅读反馈文档，理解每个问题的描述和复现条件
2. 按优先级（P0 > P1 > P2）逐一修复
3. 每修复一个问题，运行对应的验证或测试
4. 修复完成后通知用户，建议重新执行 /test 或 /review 验证

编码规范

架构遵循

• 核心逻辑与表现层分离：领域逻辑不应直接依赖 UI、CLI、Editor 扩展或其他表现层实现
• 通过明确边界解耦：状态变化优先通过事件、消息、接口、回调或项目既有机制传递
• 统一扩展点：外部系统、第三方工具、平台接口或引擎能力接入应遵循统一抽象

代码质量

• 遵循项目已有的命名规范和代码风格
• 类型系统要尽量严格，避免不必要的弱类型绕过
• 错误处理完整，不吞异常
• 对外暴露的公共 API 补充必要注释或文档说明

文件组织

• 新文件放置在 Plan 中指定的路径
• 如果 Plan 未指定路径，遵循项目已有的目录组织惯例
• 测试文件与源码放在相邻的测试目录，或使用项目既有的测试命名约定

关键约束

• 不跳过 TODO：按照依赖顺序执行，不要跳过前置依赖
• 不偏离 Plan：如果发现 Plan 有问题，先告知用户，不要自行调整架构
• 不遗漏验证：每个 TODO 的验收标准必须可验证
• 可调用其他 Skill/工具：实现过程中如需查阅文档，可调用文档检索类 Skill 或工具获取最新资料