review-commit 是开发流水线（dev-pipeline）中的第 5 阶段技能，处理代码构建完成之后的全部环节，一直覆盖到提交与部署。该技能文件及其 references 目录承载流程本身；过往循环中积累的经验（涉及 SQLite、MCP、REST、同步、移动端、测试质量陷阱、CLI 特殊行为等）放在独立的 review-lessons 技能中，只在实际遇到对应情形时按需加载，不在阶段开始时加载。
【开始前：层级、泳道与预算】 层级取自编排器的 size-tiers 参考，决定运行多少审查员以及循环可花费多少确认轮。例如 T2 表示两名审查员，R1 加最多 2 轮确认。泳道定义哪个模型负责构建、哪个负责审查，模型名称只在 lanes.md 中出现。用户指令（如“review loop 3 次”“三个审查员全上”）可覆盖本轮任务的预算或审查员集合。
【审查序列】 步骤 A 执行一次；步骤 B 在预算内循环；步骤 C 是最后的门禁。
步骤 A——双轴单轮（先做，成本低）：两个并行子代理分别沿两条轴审查 diff：规范轴（仓库约定、12 种 Fowler 代码坏味道、过度设计检查、顺带改动检查）和规格轴（是否忠实于规格/issue）。两条轴的结论不合并、不重新排序。先做快速失败检查：基准引用必须可解析，diff 必须非空。每个发现标注为 BLOCKING / MAJOR / MINOR / NIT，以具名发现的形式进入步骤 B。T0 层级跳过此步。
步骤 B——R1 审查，随后进入确认轮：R1 以该层级的审查泳道审查变更 diff。只有 BLOCKING/MAJOR 会保持循环开启，MINOR/NIT 进入延后清单且不触发新一轮。确认轮审查的是修复 diff，而不是重新审查整个变更；修复行之外的内容标记为 OUT-OF-SCOPE-N 并延后（除非复现出 BLOCKING）。只有仍有未决发现的审查员会被重新调度。每层级有硬性预算（T1 为 1 轮、T2 为 2 轮、T3 为 3 轮确认轮），预算用尽时停止，并向用户给出发布、再跑一轮或重新设计三个选项。出现第二个同类发现、无进展、或多数发现由修复本身引起时提前停止。修复前先复现；每个修复都要验证已落地，且其测试在缺少该修复时会失败。
步骤 C——提交/部署门禁：未经审查（至少 R1，且无未决 BLOCKING/MAJOR）不得推送；T0 且无行为变化的变更可按用户指示直接推送。未经三位审查员门禁不得上线部署——所有三个审查泳道须对净 diff 给出 SHIP，在循环收敛后运行一次。这是用户的常驻指令，适用于所有层级。打标签或发布前参照发布卫生文档。
【循环期间谁写代码】 构建泳道负责实现与修复；编排器独立验证，不手写非平凡修复。平凡修复（约 10 行以内、机械性、无设计选择，如拼写错误、缺失导入、明确的差一错误）可由编排器直接完成，但必须说明。不确定是否平凡时，交给构建方。审查员只读运行；构建方不提交，由编排器在自行验证后提交。
【常用用户指令对照】 “review loop N 次”对应 R1 加最多 N−1 轮确认（共 N 次审查），SHIP 时提前停止；“先构建再用 codex 审查”或“cursor 构建、codex 审查”对应构建→R1→修复→如有阻塞/重要问题则一轮确认；“修复并重审”对应修复轮后对修复 diff 做确认轮；“循环审到干净”指在层级预算内直到无未决阻塞/重要问题，然后询问用户；“发布/部署”走步骤 C，上线部署需三位审查员门禁。
【收敛检查】 每轮未决 BLOCKING/MAJOR 数量应比上一轮少；每轮的台账行记录停止条件所读的计数。若计数不下降则停止——再跑一轮也修不好让情况变糟的修复。
【经验按需加载】 review-lessons 是索引，常见条目包括：审查员 BLOCKING 与简报或契约测试矛盾、通过但不检查任何内容的测试与属性测试、功能已接线但生产环境失效、数据完整性/迁移/幂等性、CLI 参数与 git 机制及推送卫生、修复轮在错误层进行与双边修复等。