review-full

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

STARTER_CHARACTER = 🔎

STARTER_CHARACTER = 🔎

Full Review

全库审查

Review the entire codebase across 9 focus areas, each by one subagent reading a repomix-packed snapshot. The nine areas' findings then run through the same scripted collate, merge, rank, and isolated-judge verification chain review-deep uses, so a full review gets the same deduplication and Critical/High verification, not just a consolidated report.

Available on Claude Code (through this plugin) and Codex. Fails preflight by name on OpenCode and Hermes Agent, neither of which can dispatch a subagent to a named reviewer type.

从 9 个重点领域审查整个代码库，每个领域由一个 subagent 读取 repomix 打包的快照完成。这九个领域的发现结果随后会进入 review-deep 所使用的同一套脚本化汇总（collate）、合并（merge）、排序（rank）和独立 judge 验证链，因此全库审查不仅会生成一份汇总报告，还会执行相同的去重及 Critical/High 问题验证。

可通过 Claude Code（通过此 plugin）和 Codex 使用。在 OpenCode 和 Hermes Agent 上，preflight 会因缺少具名 reviewer 而失败，因为二者都无法将 subagent 派发到指定的 reviewer 类型。

Arguments

参数

If the user provided a path with the invocation, treat it as the target directory relative to the repo root. Otherwise pack the whole repo. That is the deliberate default, already accepted by whoever invoked this skill, not a decision to re-confirm.

This skill runs

context: fork

, dispatched as a subagent with no user present to answer a prompt. Never pause before dispatch to confirm scope, cost, or model spend. If cost matters, that call was made before invocation, by passing a narrower path.

如果用户在调用时提供了路径，则将其视为相对于 repo 根目录的目标目录。否则，打包整个 repo。这是调用此 skill 的人明确接受的默认设置，无需再次确认。

此 skill 通过

context: fork

运行，以 subagent 形式派发，现场没有用户可回答 prompt。派发前绝不要暂停以确认范围、成本或模型用量。如果成本很重要，相关决定应已在调用前通过传入更窄的路径作出。

Step 1: Preflight

第 1 步：Preflight

Determine your harness. In Claude Code,

HARNESS=claude

and

PLUGIN_ROOT

is this plugin's root, two directories up from this SKILL.md. In Codex,

HARNESS=codex

;

PLUGIN_ROOT

does not apply there, since the nine Codex reviewer agents live at a fixed path, not inside a plugin.

bash

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

checks every tool, agent file, and MCP server this skill needs, prints one

PASS

FAIL

line per check, and exits 1 on any

FAIL

. On success it also prints

LABEL

(the reviewer source name behind

$LABEL-<area>.md

) and

AGENT_PREFIX

(the namespace prefix for the nine subagent types;

clanker-code-review:

in Claude Code, empty in Codex). The

$S

guard catches a partial or corrupted plugin or skill install.

确定当前 harness。在 Claude Code 中，

HARNESS=claude

，

PLUGIN_ROOT

是此 plugin 的根目录，即从本 SKILL.md 向上两级。在 Codex 中，

HARNESS=codex

；

PLUGIN_ROOT

不适用，因为九个 Codex reviewer agent 位于固定路径，而不是 plugin 内部。

bash

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 -P)"

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

会检查此 skill 所需的每个工具、agent 文件和 MCP server，并为每项检查输出一行

PASS

或

FAIL

，只要出现任何

FAIL

就以状态码 1 退出。成功时还会输出

LABEL

（

$LABEL-<area>.md

背后的 reviewer 来源名称）和

AGENT_PREFIX

（九个 subagent 类型的 namespace 前缀；在 Claude Code 中为

clanker-code-review:

，在 Codex 中为空）。

$S

守卫可检测不完整或损坏的 plugin 或 skill 安装。

Step 2: Resolve Target and Prepare

第 2 步：解析目标并进行准备

bash

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

then

find -delete

rather than

rm -rf

. A

safe-rm

shim on

PATH

(as in some dotfiles setups) moves paths to Trash and exits non-zero on a missing path even under

-f

, which breaks the wipe on a first run.

bash

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

。某些 dotfiles 配置中的

PATH

上可能存在

safe-rm

shim，它会将路径移至 Trash，并且即使带有

-f

，在路径不存在时也会以非零状态退出，这会破坏首次运行时的清理。

Step 3: Start the Run

第 3 步：启动运行

bash

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

Prints

RUN_DIR

and

COMMIT

RUN_DIR

${XDG_CACHE_HOME:-~/.cache}/review-full/<repo>-<commit12>

, outside the repository. On a clean working tree

COMMIT

is HEAD. On a dirty one,

init_run.py

snapshots the working tree into an unreferenced commit over HEAD, so Step 7's judges read the same uncommitted edits the nine reviewers see in Step 5.

run.json

carries

kind: full

and

ticket_label: review-full

bash

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>

，位于 repo 之外。工作树干净时，

COMMIT

为 HEAD；工作树有未提交改动时，

init_run.py

会将工作树快照为 HEAD 之上的一个无引用 commit，从而确保第 7 步的 judge 读取到的未提交改动与第 5 步九个 reviewer 读取到的完全一致。

run.json

记录了

kind: full

和

ticket_label: review-full

。

Step 4: Pack and Build the Ledger

第 4 步：打包并构建 Ledger

bash

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 reads

.repomixignore

from the project root automatically.

--include

is packed from the project root even for a subpath target, so paths in the output stay root-relative; confirm this on the first run against a subpath, since whether

--include

changes that is unverified.

ledger.py --repomix

reads every

<file path>

entry out of the pack, so the ledger matches exactly what the reviewers can see. The reviewers work from the repomix pack directly, not from

partition.py

's components;

report.py

's coverage section is what actually reads them.

bash

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 会自动读取 repo 根目录中的

.repomixignore

。即使目标是子路径，

--include

也会从 repo 根目录开始打包，因此输出中的路径保持相对于根目录；首次针对子路径运行时需要确认这一点，因为

--include

是否会改变该行为尚未验证。

ledger.py --repomix

会从打包结果中读取每一个

<file path>

条目，因此 ledger 与 reviewer 可见的内容完全一致。Reviewer 直接基于 repomix 打包结果工作，而不是使用

partition.py

生成的组件；实际读取这些组件的是

report.py

的 coverage 部分。

Step 5: Attach and Dispatch

第 5 步：附加并派发

Call

attach_packed_output

with

filePath=REPOMIX_FILE

. Record the returned

outputId

Issue all 9 Agent calls in a single tool block with

run_in_background: false

. Subagents default to running in the background, and a backgrounded fan-out delivers its results in later turns, so Step 6 would verify files no agent has written yet.

Agent type	Area
`${AGENT_PREFIX}reviewer-architecture`	architecture
`${AGENT_PREFIX}reviewer-correctness`	correctness
`${AGENT_PREFIX}reviewer-data`	data
`${AGENT_PREFIX}reviewer-ops`	ops
`${AGENT_PREFIX}reviewer-performance`	performance
`${AGENT_PREFIX}reviewer-quality`	quality
`${AGENT_PREFIX}reviewer-security`	security
`${AGENT_PREFIX}reviewer-solid`	solid
`${AGENT_PREFIX}reviewer-testing`	testing

Each prompt contains:

The
```
outputId
```
from this step.
Instruction to use
```
read_repomix_output
```
and
```
grep_repomix_output
```
for navigation.
Instruction: "Read AGENTS.md (or CLAUDE.md) and .llmdocs/architecture.md (if present) via the repomix output for project context."
Instruction: "Write findings to
```
$STATE_DIR/$LABEL-<area>.md
```
. Use an H2 header followed by findings or exactly
```
No findings.
```
"

使用

filePath=REPOMIX_FILE

调用

attach_packed_output

。记录返回的

outputId

。

在同一个 tool block中发出全部 9 个 Agent 调用，并设置

run_in_background: false

。Subagent 默认在后台运行，而后台 fan-out 会在后续 turn 才交付结果，导致第 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`	测试

每个 prompt 包含：

本步骤返回的
```
outputId
```
。
指示使用
```
read_repomix_output
```
和
```
grep_repomix_output
```
进行导航。
指示：“通过 repomix 输出读取 AGENTS.md（或 CLAUDE.md）以及 .llmdocs/architecture.md（如果存在），以获取 repo 上下文。”
指示：“将发现写入
```
$STATE_DIR/$LABEL-<area>.md
```
。使用 H2 标题并在其后写入发现；如果没有发现，则必须恰好写入
```
No findings.
```
”

Step 6: Check and Re-dispatch

第 6 步：检查并重新派发

bash

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

Prints one

PASS

FAIL

line per area and exits 1 when any fails: the file is missing, has no H2, has no finding and is not exactly

No findings.

, or holds a bullet that parses as neither

normalize.FULL

nor

normalize.BARE

. Re-dispatch each failing area's agent once, using the same prompt as Step 5, then run

check_reviews.py

again. A second failure is reported as not reviewed in Step 8, not retried further.

bash

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

每个领域输出一行

PASS

或

FAIL

，任何一项失败时都以状态码 1 退出：文件缺失、不含 H2、没有发现且内容并非恰好为

No findings.

，或者包含无法解析为

normalize.FULL

或

normalize.BARE

的 bullet。对每个失败领域的 agent 使用与第 5 步相同的 prompt 重新派发一次，然后再次运行

check_reviews.py

。如果第二次仍失败，则在第 8 步报告为未审查，不再继续重试。

Step 7: Run the Scripted Chain

第 7 步：运行脚本化链

Run the same chain review-deep's Step 5 does, over this run's

RUN_DIR

. Run each model stage as a background Bash call; its pool returns when every call has finished, and the completion notification is the signal to continue. Never poll a running stage with

sleep

. Run the stage command itself as the background call. Never detach it with

nohup

or a trailing

, and never wait on a log line with

tail -f | grep -m1

tail

exits only when it next writes, so the call hangs until its timeout once the log gets its last line.

bash

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"

See review-deep's Step 5 for what each stage does and how every model call is run and checked; nothing here differs by kind except

report.py

's header and coverage section.

针对本次运行的

RUN_DIR

，执行 review-deep 第 5 步所用的同一条链。每个 model 阶段都作为后台 Bash 调用运行；其 pool 会在所有调用完成后返回，完成通知就是继续执行的信号。绝不要用

sleep

轮询仍在运行的阶段。应将阶段命令本身作为后台调用运行。绝不要用

nohup

或末尾的

将其脱离，也绝不要用

tail -f | grep -m1

等待某条日志行。

tail

只有在下一次写入时才会退出，因此日志写完最后一行后，该调用会一直挂起直到超时。

bash

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"

每个阶段的作用以及每次 model 调用的运行和检查方式，请参阅 review-deep 的第 5 步；除

report.py

的 header 和 coverage 部分外，此处流程不因 kind 而异。

Step 8: Report

第 8 步：报告

Report the counts from

report.md

, the confirmed Critical and High issues, and

RUN_DIR

to the operator. The run directory is valid input to the review-tickets skill, with ticket label

review-full

向操作者报告

report.md

中的计数、已确认的 Critical 和 High 问题，以及

RUN_DIR

。该运行目录可作为 review-tickets skill 的有效输入，ticket label 为

review-full

。

Tests

测试

See review-deep's Tests section. The same

evals/

at the root of this plugin's repository covers every skill here, including

unit/preflight

for this skill's preflight tier.

请参阅 review-deep 的 Tests 部分。此 plugin 仓库根目录下的同一套

evals/

覆盖这里的所有 skill，包括用于此 skill preflight 层的

unit/preflight

。