用途：把一个非平凡的变更交付为少量连贯、已验证的检查点，最后接一次集成的智能体评审门。核心目标是编码前先发现设计缺陷，编码后用聚焦证明发现实现缺陷，同时避免对同一变更反复评审。
适用条件：仅当用户明确要求分检查点规划/构建，或指定了评审门时才使用；不要从“端到端做完”这类笼统请求，或从变更跨越多个层次来自行推断。琐碎编辑应跳过。多数工作建议一至三个检查点。
流水线：跟踪清单包含 CP0（本地计划与验证，先不写生产代码）、CP1..N（逐个实现检查点，每个跑聚焦项目门）、CP-final（全量验证 + 有界全变更智能体评审 + 交接）。写任何代码前先建分支，绝不在默认分支上工作。
CP0：把任务拆成最少数量、可编译且可独立验证的检查点，每个带自己的门（类型检查/静态检查/聚焦测试/构建），明确依赖顺序。先探索真实代码（读实际文件与调用点），再把计划记入任务跟踪器；仅在计划需要超出跟踪器的持久细节时，才用草稿文档（如 PLAN-<slug>.md）。计划需覆盖已验证的当前状态（含 file:line 引用）、设计决策、各检查点范围与门、风险。用真实代码验证计划；仅当用户或当前智能体指令明确要求并行评审时，才用独立子智能体压测不同关注点，否则本地做同样检查。不要对计划文档运行 agent-review，因为运行器看到的是改动文件，而非计划所描述未改动的实现。若建了草稿计划文档，验证后、进入 CP1 前删除。存在未解决的具体设计决策时不要开始 CP1；若解决它会扩大或实质改变所请求任务，应询问用户。
CP1..N：把检查点分组为可编译的连贯单元（如先全部后端，再全部 iOS），按单元实现检查点，保持编辑在正确的归属边界，同一变更内更新文档。跑检查点门：项目的类型检查/静态检查/聚焦测试，客户端代码则跑构建，修到通过。不要在每个检查点自动运行 agent-review；聚焦证明就是检查点门，集成变更在 CP-final 评审。仅当用户明确要求对该检查点逐点评审时才跑。提交检查点（仅当用户授权提交时）。被触碰文件之外的问题，只有当所请求行为会因此变错时才在范围内，其余归为后续工作。
CP-final：更新同目录文档与会话变更日志；跑全量门（完整类型检查/静态检查/测试套件与干净构建）；对完整变更跑一次有界的 agent-review 落地评审，已提交分支用 branch 模式，未提交则用 local 模式；第 1 轮使用正确性、安全、结构简洁、模块化、复用合并契约；对照真实代码核实发现，只修范围内阻塞项；接受的修复改动了源码后，重跑相关证明并进入下一收敛轮；仅当第 2 轮又产生一个被接受且修复会改源码的阻塞项时才允许第 3 轮；第 3 轮后停止并报告未解决发现，不要循环到干净。若用户要求发布，用可用的 GitHub 工作流开启或完成 PR，并确认 CI 通过且 PR 可合并。停在就绪状态，不要合并或部署，报告合并/发布就绪度由负责人决定。
参考：子智能体计划验证提示模板、agent-review 命令、门矩阵与陷阱见 references/playbook.md；评审引擎契约与标志见 .agents/skills/agent-review/SKILL.md。
限制：仅按用户显式要求触发；评审轮次有上限（最多到第 3 轮）；不负责合并或部署；具体命令与门矩阵未在资料中完整给出，需查阅上述参考文件。