The cost of finding problems in pre-commit self-review is 1/10 of that after release. This skill is only responsible forcode quality gate. Retrospective capture is triggered by task-manager when the requirement is closed.
Step 1: Determine the depth of self-review
准备提交
│
├─ 单文件小改动（修 typo、调样式、改注释）？
│ └─ YES → 【跳过】直接提交
│
├─ 改动 ≤3 文件，不涉及公共接口？
│ └─ YES → 【快速自检】执行第二步的快速清单（5 项）
│
└─ 改动 >3 文件 / 涉及公共接口 / 核心业务逻辑？
└─ YES → 【深度自检】执行第二步的完整清单（15 项）
Step 2: CR self-review (Self Code Review)
Review your own code from the perspective of "reviewing someone else's code".
Execution method
- First
git diffreview your own changes: look at the diff file by file, not from memory - Check item by item against the checklist: not every item needs to apply, but run every item through your mind
- Fix problems on the spot when found: do not think "commit first and deal with it later"
- Proactively mention uncertain points: when committing, tell the user "I am not sure about X here, recommend paying attention"
Quick self-review checklist (≤3 file changes)
| # | Check item | Key point |
|---|---|---|
| 1 | Does the change solve the target problem? | Run through the core path to confirm |
| 2 | No leftover debug code? | console.log、print、TODO hack |
| 3 | Clear naming, no hardcoded sensitive information? | Keys, tokens, passwords |
| 4 | No unrelated changes mixed in? | Minimize the scope of changes |
| 5 | Does the code run normally? | Verify after changes, not "I think it is right" |
Deep self-review checklist (>3 files / public interfaces / core logic)
Correctness check：
- Does the change really solve the target problem? Run through the core path to confirm
- Are edge cases handled? Null values, zero values, extremely long input, concurrency scenarios
- Is error handling complete? Exceptions will not be swallowed, and error messages are meaningful
- Has a regression been introduced? Could the change break existing functionality
Design check：
- Is the scope of changes minimized? Are unrelated changes mixed in
- Are names self-explanatory? Can newly added function/variable/type names be understood at a glance
- Are you reinventing the wheel? Is there an existing tool or pattern in the project that can be reused
- Is the complexity reasonable? Is there over-abstraction or unnecessary indirection
Security check：
- Is external input validated? User input, API parameters, URL parameters
- Is there hardcoded sensitive information? Keys, tokens, passwords, internal addresses
- Is SQL/command concatenation safe? Are parameterized queries used
- Is the frontend protected against XSS? Is dynamic content correctly escaped
Maintainability check：
- No leftover debug code (console.log, print, TODO hack)
- Do complex logic sections have comments explaining "why"
- Are changes to public interfaces backward compatible? If not, has it been marked
Connection with other skills
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
Retrospectives are not triggered in task-finish. Because "coding complete" does not equal "requirement complete"—there may still be manual testing, bug fixes, and adjustments afterward. The retrospective is triggered by the task-manager when the requirement is explicitly marked as done by the user, ensuring the full delivery process is covered. But task-finish has the responsibility to remind: After submitting the code, proactively ask the user whether the requirement should be closed, to avoid the retrospective being forgotten.