# Task Finish

> 提交前质量门禁：CR 自检（快速/深度）。在 commit 之前触发。 只负责代码质量自检，不负责复盘——复盘在需求标 done 时由 task-manager 触发。 触发词：提交代码、自检、准备提交。 工作流位置：task-start → task-execute → task-finish（自检）→ task-manager（需求关闭时复盘）

- Skill: `312362115/task-finish` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add 312362115/task-finish`
- Raw SKILL.md: https://api.skillmd.com/api/skills/312362115/task-finish/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: 312362115 (https://skillmd.com/u/312362115)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/312362115/task-finish

---


# 提交前自检（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 文件改动）

| # | 检查项 | 要点 |
|---|--------|------|
| 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 有责任提醒**：提交代码后主动询问用户是否需要关闭需求，避免复盘被遗忘。