Implement - 代码实现技能
根据 plan 文档进行代码实现，或根据 test/review 的反馈进行修复。
核心原则
- 严格遵循 Plan：按照已确认的
plan.md中的 TODO 逐项实现 - 架构一致：遵循项目整体既有的架构设计、模块边界与依赖方向
- 模块化与可扩展：代码必须模块化，遵循 SOLID 原则和适当的设计模式
- 最小变更：只实现 Plan 要求的内容，不做额外的"优化"或"改进"
前置条件
- 对应功能的
plan.md必须已存在且状态为"已确认" - 对应功能的
spec.md应可访问 - 如果项目有统一文档目录，遵循现有约定；如果没有，建议使用
spec/<spec-name>/plan.md - 如果 plan 不存在，提示用户先执行
/plan
工作流程
模式一：按 Plan 实现新功能
- 阅读上下文
- 阅读对应功能的 spec.md 和 plan.md - 阅读项目级背景文档（如 PRD、roadmap、里程碑文档；如果存在） - 阅读现有代码，理解项目结构、命名规范、编码风格 - 阅读团队沉淀文档（如 lessons learned、pitfalls；如果存在），避免已知坑
- 确认 TODO 范围
- 向用户确认本次要实现哪些 TODO（可能不是一次性全部实现） - 按照 Plan 中的依赖关系确定执行顺序
- 逐项实现
- 按 TODO 顺序逐一编写代码 - 每完成一个 TODO，运行相关的验证或测试 - 如果项目使用勾选式计划文档，每完成一个 TODO，立即在 plan.md 中将对应的 - [] 勾选为 - [x]，实时反映进度 - 遇到 Plan 未覆盖的技术细节，向用户澄清后再继续
- 自查
- 确保代码可编译、可构建或可运行 - 确保已有测试或验收流程不被破坏 - 检查是否引入明显的安全风险（如注入、越权、敏感信息泄露）
模式二：根据反馈修复
当输入来源是 test 报告（test.md）或 review 报告（review.md）时：
- 阅读反馈文档，理解每个问题的描述和复现条件
- 按优先级（P0 > P1 > P2）逐一修复
- 每修复一个问题，运行对应的验证或测试
- 修复完成后通知用户，建议重新执行
/test或/review验证
编码规范
架构遵循
- 核心逻辑与表现层分离：领域逻辑不应直接依赖 UI、CLI、Editor 扩展或其他表现层实现
- 通过明确边界解耦：状态变化优先通过事件、消息、接口、回调或项目既有机制传递
- 统一扩展点：外部系统、第三方工具、平台接口或引擎能力接入应遵循统一抽象
代码质量
- 遵循项目已有的命名规范和代码风格
- 类型系统要尽量严格，避免不必要的弱类型绕过
- 错误处理完整，不吞异常
- 对外暴露的公共 API 补充必要注释或文档说明
文件组织
- 新文件放置在 Plan 中指定的路径
- 如果 Plan 未指定路径，遵循项目已有的目录组织惯例
- 测试文件与源码放在相邻的测试目录，或使用项目既有的测试命名约定
关键约束
- 不跳过 TODO：按照依赖顺序执行，不要跳过前置依赖
- 不偏离 Plan：如果发现 Plan 有问题，先告知用户，不要自行调整架构
- 不遗漏验证：每个 TODO 的验收标准必须可验证
- 可调用其他 Skill/工具：实现过程中如需查阅文档，可调用文档检索类 Skill 或工具获取最新资料