312362115 提交前自检（Task Finish）
提交前自检发现问题的成本是上线后的 1/10。 本 skill 只负责代码质量门禁。复盘沉淀在需求关闭时由 task-manager 触发。
第一步：判断自检深度
准备提交
│
├─ 单文件小改动（修 typo、调样式、改注释）？
│ └─ YES → 【跳过】直接提交
│
├─ 改动 ≤3 文件，不涉及公共接口？
│ └─ YES → 【快速自检】执行第二步的快速清单（5 项）
│
└─ 改动 >3 文件 / 涉及公共接口 / 核心业务逻辑？
└─ YES → 【深度自检】执行第二步的完整清单（15 项）
第二步：CR 自检（Self Code Review）
用"审查别人代码"的视角审查自己的代码。
执行方式
- 先
git diff审查自己的改动：逐文件看 diff，而不是凭记忆 - 对照清单逐项检查：不需要每条都适用，但每条都过一遍脑子
- 发现问题当场修：不要想着"先提交再说"
- 不确定的地方主动说：在提交时告知用户"这里我不确定 X，建议关注"
快速自检清单（≤3 文件改动）
| # | 检查项 | 要点 |
|---|---|---|
| 1 | 改动解决了目标问题？ | 跑一遍核心路径确认 |
| 2 | 没有遗留 debug 代码？ | console.log、print、TODO hack |
| 3 | 命名清晰、无硬编码敏感信息？ | 密钥、token、密码 |
| 4 | 没有混入不相关变更？ | 改动范围最小化 |
| 5 | 代码能正常运行？ | 改后验证，不是"我觉得对" |
深度自检清单（>3 文件 / 公共接口 / 核心逻辑）
正确性检查：
- 改动是否真的解决了目标问题？跑一遍核心路径确认
- 边界情况是否处理？空值、零值、超长输入、并发场景
- 错误处理是否完整？异常不会被吞掉，错误信息有意义
- 是否引入了回归？改动是否可能破坏现有功能
设计检查：
- 改动范围是否最小化？有没有混入不相关的变更
- 命名是否自解释？新增的函数/变量/类型名能否让人一眼理解
- 是否重复造轮子？项目里有没有已有的工具或模式可以复用
- 复杂度是否合理？有没有过度抽象或不必要的间接层
安全检查：
- 外部输入是否校验？用户输入、API 参数、URL 参数
- 有没有硬编码的敏感信息？密钥、token、密码、内部地址
- SQL/命令拼接是否安全？是否使用了参数化查询
- 前端是否防 XSS？动态内容是否正确转义
可维护性检查：
- 没有遗留 debug 代码（console.log、print、TODO hack）
- 复杂逻辑是否有注释说明"为什么"
- 公共接口的改动是否向后兼容？不兼容是否已标注
与其他 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-finish 中触发。 因为"编码完成"不等于"需求完成"——后续可能还有手动测试、bug 修复、调整。 复盘在需求被用户明确标记为 done 时，由 task-manager 触发，确保覆盖完整的交付过程。 但 task-finish 有责任提醒：提交代码后主动询问用户是否需要关闭需求，避免复盘被遗忘。