jackwener /check · 任务完成后的 Diff 审查
使用场景
每次代码改动完成后，在宣称"任务完成"之前必须执行。
目标
确认本次修改：
- 真的满足了用户需求（没漏点）
- 没超出 scope（没顺手加无关改动）
- 通过了项目的验证流程（lint / typecheck / test）
Agent 最常见的失败是自信地宣称"完成了"但实际只测了 happy path。/check 是对抗这种失败的标准动作。
必须步骤
1. 读 git 状态
git status
git diff
git diff --stat
把当前改动的所有文件列出来，逐个评估。
2. 对照原始任务
- 任务的 Goal（来自
/think输出 / spec 的proposal.md）是否完成？ - Non-Goals 有没有被违反？（顺手优化无关代码 = 违反）
- tasks.md 上勾掉了哪些 checkbox？
3. 检查 diff 性质
| 检查项 | 必须答 |
|---|---|
| 是否修改了不该修改的文件？ | 列出每个改动文件，说明必要性 |
| 是否引入新依赖？ | 是 → 必须解释为什么不能用现有依赖 |
| 是否有硬编码 / 临时 workaround？ | 是 → 必须明确 // TODO 标注 |
| 是否更新测试？ | 业务逻辑改动必须配测试，UI 改动至少手测 |
是否动了 L0-protect-core 列出的禁区文件？ |
是 → 立即停下，向用户解释 |
4. 执行项目验证
读取 package.json 的 scripts 段，找出推荐的：
lint→ 跑pnpm linttypecheck→ 跑npx tsc --noEmittest→ 跑pnpm test（如果存在）
每条命令的完整输出贴给用户。失败的不允许吞掉。
如果项目没有上述脚本：明确说"项目暂无 X 命令"。
5. 手测验证
涉及 UI / API 的改动必须手测：
- 改了 page → 浏览器访问看是否渲染正确
- 改了 API →
curl或 dev tools 网络面板验证响应 - 改了数据流 → 关键路径走一遍
6. 输出审查报告
按下面格式输出。
禁止事项
- ❌ 不允许只说"看起来没问题"
- ❌ 不允许在没看 git diff 的情况下总结
- ❌ 不允许忽略失败的测试 / 类型错 / lint warning
- ❌ 不允许把未验证的结果描述成"已完成"
- ❌ 不允许跳过手测就 say done
输出格式
## Summary
（一两句话说做了什么）
## Files Changed
| 文件 | 改了什么 | 必要性 |
|---|---|---|
| ... | ... | ... |
## Verification
- `pnpm lint` → ✓ 无 warning
- `npx tsc --noEmit` → ✓ 无错
- `pnpm test` → ✓ N 个用例全过
- 手测：访问 `/admin/exam/seed_zhang_gaofen` → 详情页正确显示
## Risks
- 风险 1：...
- 风险 2：...
## Next Step
建议接下来：...
与其他 Skill 的关系
- 实施时建议先用
/small-diff控制改动 - 发现需要修的 bug 用
/hunt - 任务结束后用
/update-context沉淀本次发现