一句话

交付前对当前分支做一轮结构化评审：查 bug、意图贴合度和测试覆盖，修掉关键问题，提交并开出或更新 PR。

何时用

• 适合：改完了想让人系统过一遍再发；PR 前的最后一公里。
• 不适合：只想要风格清理（用 ctk-deslop）；只要验证某个具体说法（用 ctk-verify-this）。

怎么用

评审这个分支相对 main 的改动，跑相关测试，没问题就提交开 PR

1. 收集上下文：对 base 的 diff、未提交改动、近期 commit、用户意图。
2. 跑改动行为对应的目标测试；没有就决定是否补测试或记录缺口。
3. 按正确性、回归、安全、意图贴合评审；diff 大时用并行子代理。
4. 先修关键问题再定稿，选择性提交，推送并开出或更新 PR。

产出

• 分级结论（critical / warning / note）、测试与结果、PR URL。

要点与坑

• 优先级：正确性、安全、回归高于风格；pre-commit 挂了修问题而不是 --no-verify。
• 判 PR 就绪用 gh pr checks（覆盖全部挂载检查），不只用 GitHub Actions 命令。

关联

• 前置：ctk-deslop · 下游：ctk-loop-on-ci · 同类：ctk-make-pr-easy-to-review
• 所属：00-ctk-概览