用途：deep-review 用于多评审者代码审查。它并行启动按领域划分的评审者，交叉核对各自发现是否存在矛盾与收敛，然后发布一条带行内评论的结构化 GitHub 审查。适合涉及 3 个以上子系统、超过 500 行，或需要安全、并发、数据库等专业领域知识的 PR；也适合希望获得相互交叉核对的独立视角，而非单遍审查的场景。单领域小改动或快速单遍审查应改用 .claude/skills/code-review/。
主要能力：先做比例检查，若 PR 少于 3 个文件且少于 100 行改动，建议改用 code-review；纯文档 PR 建议改用 doc-check。支持重审检测，会读取上次审查后的作者回复、对比分支变化，并生成 prior-findings.md 分类表（Resolved、Acknowledged、Contested、No response），仅将 Contested 与 No response 带入新审查。评审者分两层：Tier 1 结构类（测试审计、边界用例、契约审计、结构分析、性能、数据库、安全、产品、前端、重复检查、Go 架构、并发），Tier 2 细枝末节类（现代化、风格）。
使用方式：需具备并行启动子代理的能力，否则应改用 code-review。先创建输出目录：export REVIEW_DIR="/tmp/deep-review/$(date +%s)" 与 mkdir -p "$REVIEW_DIR"。可用 gh pr view {number} --json reviews --jq '.reviews[] | select(.body | test("P[0-4]|\\Obs\\|\\Nit\\")) | .submittedAt' | head -1 检测既往审查。评审者只读，自行获取 diff，并将发现写入 $REVIEW_DIR/{role-name}.md；编排者逐个读取文件而非批量读取，以免混淆评审者声音。
限制：严重度采用 P0–P4，与 code-review 的 🔴🟡🔵 不同但可近似对应（P0–P1 ≈ 🔴，P2 ≈ 🟡，P3–P4 ≈ 🔵）。不适用于纯文档或纯配置 PR、约 50 行以内的单文件改动，以及作者要求快速审查的情况。资料未提供收费、价格、平台支持范围等信息。