用途：把代码审查变成可重复流程，而非随机评论。核心原则是尽早、频繁审查。强制审查时机：完成重要功能后、workflow-execute-plans 每批（默认每批 3 个任务）结束后、合并到主分支前。可选时机：卡住时、大重构前、修复复杂 bug 后。
发起审查需提供最小信息集：1）确定审查范围（git SHA），常用基线为 main：BASE_SHA=$(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master)；HEAD_SHA=$(git rev-parse HEAD)。若只审查最近一次提交：BASE_SHA=$(git rev-parse HEAD~1)；HEAD_SHA=$(git rev-parse HEAD)。2）准备审查依据：WHAT_WAS_IMPLEMENTED（1-3 条要点）与 PLAN_OR_REQUIREMENTS（计划摘录或需求文档路径）。3）获取 diff 证据：git diff --stat "$BASE_SHA..$HEAD_SHA" 与 git diff "$BASE_SHA..$HEAD_SHA"。
执行方式二选一：方法 A 子代理审查，使用模板 review-merge-readiness/code-reviewer.md 填入占位符执行；方法 B 自审，按模板清单逐项检查并输出同样结构化结果。
输出必须结构化，包含：Strengths（至少 1 条具体优点）；Issues 按严重度分类——Critical（必须修复：安全/数据丢失/功能 bug/会导致生产事故）、Important（应当修复：架构差/缺错误处理/测试缺口/需求不对齐）、Minor（可选：风格/小优化/文档润色）；Assessment（可合并性 Yes/No/With fixes 加 1-2 句技术理由）。每个 Issue 需含位置 file:line、问题、影响、最小修复建议。
与其他审查技能的关系：review-clean-code 偏可维护性与代码异味；review-react-best-practices 偏 React/Next.js 性能模式；本技能偏需求对齐、生产就绪与合并结论。只需“能否合并”结论时用本技能；需深度健康检查可另调 review-clean-code。限制：资料未提供具体平台支持范围、安装方式与收费信息。