review-full

STARTER_CHARACTER = 🔎

全面审查

通过 9 个子 Agent，分别阅读 Repomix 打包的快照，对整个代码库进行 9 个重点领域的审查。随后，各领域的发现都会经过与 review-deep 相同的脚本化汇总、合并、排序和隔离裁定验证流程，因此全面审查也会进行相同的去重和 Critical/High 验证，而不只是生成一份汇总报告。

可在 Claude Code（通过此插件）和 Codex 上使用。在 OpenCode 和 Hermes Agent 上会按名称在预检阶段失败，因为这两者都无法向指定的审查者类型分派子 Agent。

参数

如果用户在调用时提供了路径，则将其视为相对于仓库根目录的目标目录。否则打包整个仓库。这是有意设定的默认行为，调用此技能的人已经接受了这一点，无需再次确认。

此技能以 context: fork 运行，作为子 Agent 分派，此时没有用户在场回答提示词。分派前切勿暂停以确认范围、成本或模型开销。如果成本有影响，调用前就已通过传入范围更窄的路径作出决定。

步骤 1：预检

确定你的运行环境。在 Claude Code 中，HARNESS=claude，且 PLUGIN_ROOT 是此插件的根目录，位于此 SKILL.md 向上两级的位置。在 Codex 中，HARNESS=codex；PLUGIN_ROOT 不适用，因为 9 个 Codex 审查者 Agent 位于固定路径，而不在插件内。

S="${CLAUDE_SKILL_DIR}/../review-deep/scripts"   # replace ${CLAUDE_SKILL_DIR} with this SKILL.md's own directory on a non-Claude harness
[ -f "$S/init_run.py" ] || { echo "scripts not found at $S"; exit 1; }
HARNESS=claude
PLUGIN_ROOT="$(cd "${CLAUDE_SKILL_DIR}/../.." && pwd)"

OUT=$(python3 "$S/preflight.py" --tier full --harness "$HARNESS" --plugin-root "$PLUGIN_ROOT")
STATUS=$?
echo "$OUT"
[ "$STATUS" -eq 0 ] || exit 1
LABEL=$(echo "$OUT" | sed -n 's/^LABEL=//p')
AGENT_PREFIX=$(echo "$OUT" | sed -n 's/^AGENT_PREFIX=//p')

preflight.py 会检查此技能所需的每个工具、Agent 文件和 MCP 服务，每项检查打印一行 PASS 或 FAIL，并在出现任何 FAIL 时以状态码 1 退出。成功时，它还会打印 LABEL（$LABEL-<area>.md 背后的审查者来源名称）和 AGENT_PREFIX（9 种子 Agent 类型的命名空间前缀；在 Claude Code 中为 clanker-code-review:，在 Codex 中为空）。$S 防护检查可捕获不完整或损坏的插件或技能安装。

步骤 2：解析目标并准备

PROJECT_ROOT=$(git rev-parse --show-toplevel)
PROJECT_ROOT=$(cd -P "$PROJECT_ROOT" && pwd -P)
TARGET_PATH="<user-provided path or empty>"
[ -z "$TARGET_PATH" ] && TARGET_PATH="$PROJECT_ROOT"

TARGET_PATH=$(cd -P "$TARGET_PATH" 2>/dev/null && pwd -P) || { echo "TARGET_PATH does not exist"; exit 1; }
case "$TARGET_PATH" in
  "$PROJECT_ROOT"|"$PROJECT_ROOT"/*) ;;
  *) echo "TARGET_PATH escapes PROJECT_ROOT"; exit 1 ;;
esac

TARGET_NAME=$(basename "$TARGET_PATH")
[ "$TARGET_PATH" = "$PROJECT_ROOT" ] && TARGET_NAME="repo"

STATE_DIR="$PROJECT_ROOT/.llmtmp/review-full"
mkdir -p "$STATE_DIR"
find "$STATE_DIR" -mindepth 1 -delete

使用 mkdir -p，然后使用 find -delete，而不是 rm -rf。PATH 中的 safe-rm 替代命令（某些 dotfiles 配置中会有）会将路径移至废纸篓，并且即使使用 -f，遇到不存在的路径时也会以非零状态码退出，这会导致首次运行时清理失败。

步骤 3：启动运行

python3 "$S/init_run.py" --kind full "$PROJECT_ROOT" "$TARGET_PATH" "$STATE_DIR"

打印 RUN_DIR 和 COMMIT。RUN_DIR 是仓库之外的 ${XDG_CACHE_HOME:-~/.cache}/review-full/<repo>-<commit12>。工作树干净时，COMMIT 为 HEAD。工作树有未提交更改时，init_run.py 会在 HEAD 之上将工作树快照为一个未引用的提交，因此步骤 7 的裁定者会读取与步骤 5 中 9 位审查者所见相同的未提交编辑。run.json 包含 kind: full 和 ticket_label: review-full。

步骤 4：打包并构建台账

REPOMIX_FILE="$STATE_DIR/repomix.xml"
INCLUDE=""
[ "$TARGET_PATH" != "$PROJECT_ROOT" ] && INCLUDE="--include ${TARGET_PATH#"$PROJECT_ROOT"/}/**"
npx repomix -o "$REPOMIX_FILE" --quiet --output-show-line-numbers $INCLUDE "$PROJECT_ROOT"

python3 "$S/ledger.py" "$STATE_DIR" --repomix "$REPOMIX_FILE"
python3 "$S/partition.py" "$STATE_DIR"

Repomix 会自动读取项目根目录中的 .repomixignore。即使目标是子路径，--include 也会从项目根目录开始打包，因此输出中的路径始终相对于根目录；首次针对子路径运行时请确认这一点，因为 --include 是否会改变此行为尚未验证。

ledger.py --repomix 会从打包内容中读取每个 <file path> 条目，因此台账与审查者能看到的内容完全一致。审查者直接使用 Repomix 打包内容，而不是 partition.py 的组件；真正读取这些组件的是 report.py 的覆盖率部分。

步骤 5：附加并分派

调用 attach_packed_output，并设置 filePath=REPOMIX_FILE。记录返回的 outputId。

在同一个工具块中发起全部 9 次 Agent 调用，并设置 run_in_background: false。子 Agent 默认在后台运行，后台扇出会在后续轮次才返回结果，因此步骤 6 会在 Agent 尚未写入文件时检查文件。

Agent 类型	领域
${AGENT_PREFIX}reviewer-architecture	架构
${AGENT_PREFIX}reviewer-correctness	正确性
${AGENT_PREFIX}reviewer-data	数据
${AGENT_PREFIX}reviewer-ops	运维
${AGENT_PREFIX}reviewer-performance	性能
${AGENT_PREFIX}reviewer-quality	质量
${AGENT_PREFIX}reviewer-security	安全
${AGENT_PREFIX}reviewer-solid	solid
${AGENT_PREFIX}reviewer-testing	测试

每个提示词都包含：

1. 此步骤的 outputId。
2. 使用 read_repomix_output 和 grep_repomix_output 进行导航的指示。
3. 指示：“通过 repomix 输出读取 AGENTS.md（或 CLAUDE.md）和 .llmdocs/architecture.md（如果存在），以了解项目背景。”
4. 指示：“将发现写入 $STATE_DIR/$LABEL-<area>.md。使用 H2 标题，后跟发现内容；如果没有发现，则内容必须恰好为 No findings.。”

步骤 6：检查并重新分派

python3 "$S/check_reviews.py" "$RUN_DIR" "$LABEL"

每个领域打印一行 PASS 或 FAIL；如果文件缺失、没有 H2、没有发现且内容又不恰好为 No findings.，或者其中有项目符号无法解析为 normalize.FULL 或 normalize.BARE，则以状态码 1 退出。对每个失败领域的 Agent 重新分派一次，使用与步骤 5 相同的提示词，然后再次运行 check_reviews.py。第二次失败的领域将在步骤 8 中报告为未审查，不再重试。

步骤 7：运行脚本化链条

针对本次运行的 RUN_DIR，运行与 review-deep 的步骤 5 相同的链条。每个模型阶段都作为后台 Bash 调用运行；其调用池会在所有调用完成后返回，完成通知就是继续执行的信号。切勿使用 sleep 轮询正在运行的阶段。将阶段命令本身作为后台调用运行。切勿用 nohup 或尾随的 & 将其分离运行，也切勿通过 tail -f | grep -m1 等待日志行。tail 只有在日志有新内容写入时才会退出，因此日志写入最后一行后，该调用会一直挂起，直到超时。

python3 "$S/checkout.py" "$RUN_DIR"
python3 "$S/normalize.py" "$RUN_DIR"
python3 "$S/collate.py" "$RUN_DIR"         # one model call per component, background
uv run --with scikit-learn --with scipy --with numpy python "$S/windows.py" "$RUN_DIR"
python3 "$S/merge.py" "$RUN_DIR"           # one model call per similarity window, background
python3 "$S/rank.py" "$RUN_DIR"
python3 "$S/verify.py" "$RUN_DIR"          # one model call per Critical or High issue, background
python3 "$S/report.py" "$RUN_DIR"

每个阶段的用途，以及如何运行和检查每次模型调用，请参阅 review-deep 的步骤 5；除 report.py 的标题和覆盖范围部分外，这里没有因类型而异之处。

步骤 8：报告

向操作员报告 report.md 中的计数、已确认的 Critical 和 High 问题，以及 RUN_DIR。该运行目录可作为 review-tickets 技能的有效输入，工单标签为 review-full。

测试

请参阅 review-deep 的“测试”部分。本插件仓库根目录中的同一 evals/ 覆盖此处的所有技能，包括此技能预检层级的 unit/preflight。