| name | task-finish |
| version | 1.1.0 |
| last_updated | "2026-04-08T00:00:00.000Z" |
| repository | https://github.com/312362115/claude |
| changelog | skills/task-finish/CHANGELOG.md |
| description | 提交前质量门禁：CR 自检（快速/深度）。在 commit 之前触发。 只负责代码质量自检，不负责复盘——复盘在需求标 done 时由 task-manager 触发。 触发词：提交代码、自检、准备提交。 工作流位置：task-start → task-execute → task-finish（自检）→ task-manager（需求关闭时复盘）
|
提交前自检（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 文件 / 公共接口 / 核心逻辑）
正确性检查：
设计检查：
安全检查：
可维护性检查：
与其他 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 有责任提醒：提交代码后主动询问用户是否需要关闭需求，避免复盘被遗忘。
