用途
task-finish 是一个提交前质量门禁 Skill，在 commit 之前触发，只负责代码质量自检，不负责复盘。其定位是：提交前自检发现问题的成本是上线后的 1/10。复盘沉淀在需求关闭时由 task-manager 触发。
触发词：提交代码、自检、准备提交。
主要能力
第一步：判断自检深度
根据改动规模选择自检模式：
- 单文件小改动（修 typo、调样式、改注释）→ 跳过，直接提交
- 改动 ≤3 文件且不涉及公共接口 → 快速自检（5 项）
- 改动 >3 文件 / 涉及公共接口 / 核心业务逻辑 → 深度自检（15 项）
第二步：CR 自检（Self Code Review）
用「审查别人代码」的视角审查自己的代码。执行方式包括：
- 先 git diff 审查自己的改动：逐文件看 diff，而不是凭记忆
- 对照清单逐项检查：不需要每条都适用，但每条都过一遍脑子
- 发现问题当场修：不要想着「先提交再说」
- 不确定的地方主动说：在提交时告知用户「这里我不确定 X，建议关注」
快速自检清单（≤3 文件改动）
- 改动解决了目标问题？跑一遍核心路径确认
- 没有遗留 debug 代码？console.log、print、TODO hack
- 命名清晰、无硬编码敏感信息？密钥、token、密码
- 没有混入不相关变更？改动范围最小化
- 代码能正常运行？改后验证，不是「我觉得对」
深度自检清单（>3 文件 / 公共接口 / 核心逻辑）
正确性检查：
- 改动是否真的解决了目标问题？跑一遍核心路径确认
- 边界情况是否处理？空值、零值、超长输入、并发场景
- 错误处理是否完整？异常不会被吞掉，错误信息有意义
- 是否引入了回归？改动是否可能破坏现有功能
设计检查：
- 改动范围是否最小化？有没有混入不相关的变更
- 命名是否自解释？新增的函数/变量/类型名能否让人一眼理解
- 是否重复造轮子？项目里有没有已有的工具或模式可以复用
- 复杂度是否合理？有没有过度抽象或不必要的间接层
安全检查：
- 外部输入是否校验？用户输入、API 参数、URL 参数
- 有没有硬编码的敏感信息？密钥、token、密码、内部地址
- SQL/命令拼接是否安全？是否使用了参数化查询
- 前端是否防 XSS？动态内容是否正确转义
可维护性检查：
- 没有遗留 debug 代码（console.log、print、TODO hack）
- 复杂逻辑是否有注释说明「为什么」
- 公共接口的改动是否向后兼容？不兼容是否已标注
使用方式
在准备提交代码时触发。Skill 会引导按改动规模选择自检深度，然后按对应清单逐项检查，发现问题当场修复。
在与其他 Skill 的衔接中，工作流位置为：task-start（启动：对焦需求 + 设计方案）→ task-execute（执行：持续编码 + 跨会话进度管理）→ task-finish（本 skill，提交前自检）。
自检通过后提交代码，并包含以下衔接动作：
- 文档同步提醒（按改动内容判断，可能同时命中多条）：
- 涉及新模块 / 模块间交互变更？→ 提醒更新 architecture/ 或 user-guide/（docs-management.Synthesize）
- 涉及依赖/工具链/环境配置变更？→ 提醒更新 guides/
- 涉及部署流程/基础设施变更？→ 提醒更新 runbooks/
- 涉及上线服务？→ 提示跑 security-audit（安全审查）
- 准备发版？→ 引导到 release skill
提交完成后，主动询问用户：「这个需求是否彻底完成？如果是，可以标记 done 触发复盘和经验沉淀。」
用户确认完成后，由 task-manager 标 done，触发复盘 + 经验沉淀 + docs-management.Ingest。
适用场景
适用于需要在提交代码前进行质量自检的开发工作流，尤其适合与 task-start、task-execute、task-manager 等 Skill 配合使用，形成从启动、执行到提交前自检再到复盘沉淀的完整流程。
限制
- 复盘不在 task-finish 中触发。因为「编码完成」不等于「需求完成」——后续可能还有手动测试、bug 修复、调整。复盘在需求被用户明确标记为 done 时，由 task-manager 触发，确保覆盖完整的交付过程。
- 但 task-finish 有责任提醒：提交代码后主动询问用户是否需要关闭需求，避免复盘被遗忘。
- 本 skill 只负责代码质量门禁。