Implement

---
name: implement
description: "执行范围明确的代码、配置或文档修改，行为改动默认测试驱动（先红后绿）。按风险验证并完成已授权工作；复杂未知故障用 diagnose，重要设计取舍未定时先澄清。"
---

# Scoped implementation

用户请求、项目规格、计划或 review findings 可直接提供执行范围；review 已授权的修复回边按本轨道状态面记录（state/work_index 出链）接手，不依赖用户复述，无需重新索要授权。行为类改动默认测试驱动，在预先商定的 seams 上先红后绿；无需为常规修改补齐全部流程工件。

## 流程

1. 阅读相关入口、源码、测试和 git 差异，确定目标行为与必要验证；保护无关用户改动。
2. 确定测试 seams：seam 是观察行为的公共边界，不是实现内部。seams 不明确时先与用户商定，或采用已批准 Spec/plan 记录的验收面；细则读 `tdd` skill。
3. 行为改动按 `tdd` 纪律执行：先写失败测试（red），再写刚好让它通过的实现（green），一次一片垂直切片；不预写未来测试、不加投机功能。文档与低风险配置不机械要求先写失败测试。
4. 验证节奏：typecheck 常跑、单个测试文件常跑、完整套件收尾跑一次。新改动影响已验证路径时重跑对应检查；已完成且仍适用的证据可复用，不因换技能重跑。
5. 重构不在 red-green 循环内：行为变绿后的结构收敛由 `review` 识别、授权后另行整理，不与让测试变绿混在一轮。
6. 更新受影响的用户文档和已有恢复记录；没有变化的文档无需修改，不新建重复状态文件。长任务不等收尾：新证据、被排除的假设或关键决策出现时即写入本轨道 state 的 Evidence（新证据）/Next（续点）行，不写其他轨道文件（state 为单数快照：多轨道换轨时先改写 Objective 头，见 plan 多轨道规则）；持续探索后按需重读当前 plan/任务入口，防目标漂移。
7. 按下述完成条件收尾，或继续已授权的后续步骤。只在实质扩大范围、改变验收或遇到授权边界时询问。

## 完成条件

- 低风险、范围清楚的修改可在自审和相关检查后直接完成、按项目要求提交；项目无提交约定时，一组已验证的完整改动默认落一个 commit（信息按项目语言），不以「无要求」悬置不提交；不限于单行修改。
- 复杂行为、多模块合同、权限/数据边界，或用户要求 review 时，使用 `review` 进行更深入评审。`verify` 只是同一入口的别名，不串行追加一轮。
- 必需验收失败或 unknown 时，不宣称对应能力 ready；可以完成独立部分，并具体报告剩余缺口。
- 根因未知且需要调查时用 `diagnose`；明确的局部错误可直接修复，不为了切换技能而停顿。
- 验证强度的参考见 `references/verification-intensity.md`。

## 输出

说明改动、验证（含关键测试证据）、尚存问题及是否提交。需要追踪时记录证据所对应的工作树/配置/输入；简单任务不强制填空表。

## Recommended next skill

- 简单任务已验证：结束或继续用户已授权的下一步。
- 需要深入检查：`review`；未知故障：`diagnose`。
- 本次影响文档或恢复状态需整理：`cleanup`；实质范围变化需要重排依赖：`plan`。