提交前自检（Task Finish）

提交前自检发现问题的成本是上线后的 1/10。 本 skill 只负责代码质量门禁。复盘沉淀在需求关闭时由 task-manager 触发。

第一步：判断自检深度

准备提交
  │
  ├─ 单文件小改动（修 typo、调样式、改注释）？
  │   └─ YES → 【跳过】直接提交
  │
  ├─ 改动 ≤3 文件，不涉及公共接口？
  │   └─ YES → 【快速自检】执行第二步的快速清单（5 项）
  │
  └─ 改动 >3 文件 / 涉及公共接口 / 核心业务逻辑？
      └─ YES → 【深度自检】执行第二步的完整清单（15 项）

第二步：CR 自检（Self Code Review）

用"审查别人代码"的视角审查自己的代码。

执行方式

1. 先 git diff 审查自己的改动：逐文件看 diff，而不是凭记忆
2. 对照清单逐项检查：不需要每条都适用，但每条都过一遍脑子
3. 发现问题当场修：不要想着"先提交再说"
4. 不确定的地方主动说：在提交时告知用户"这里我不确定 X，建议关注"

快速自检清单（≤3 文件改动）

深度自检清单（>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 有责任提醒：提交代码后主动询问用户是否需要关闭需求，避免复盘被遗忘。