• Pure-C / pure-C++ codebases — use

  c-review

  instead.
• Smart contracts (Solana programs / NEAR contracts / Ink!) — use

  solana-vulnerability-scanner

  or the contract-specific skill.
• Kernel-mode Rust drivers without userspace allocator — coverage is incomplete; flag as advisory only.
• Secrets/key memory hygiene (zeroization,

  Zeroize

  /

  ZeroizeOnDrop

  /

  secrecy

  usage, lingering stack/heap copies) — use the

  zeroize-audit

  skill; rust-review does not cover memory zeroization.

coordinator: write context.md → build_run_plan.py → TaskCreate × M
          → spawn primer (foreground) → spawn M workers (parallel)
          → classify Phase-7 outcomes + write findings-index.txt
          → dedup-judge → fp-judge → report safety net (SARIF + REPORT.md) → return REPORT.md

context.md

plan.json

worker-prompts/

findings/

findings-index.d/

findings-index.txt

coverage/

run-summary.md

dedup-summary.md

fp-summary.md

REPORT.md

REPORT.sarif

${RUST_REVIEW_PLUGIN_ROOT}/scripts/*.py

prompts/clusters/unsafe-boundary.md

scripts/build_run_plan.py

1. Native Claude Code —

   ${CLAUDE_PLUGIN_ROOT}

   , accepted if

   Bash: ls "${CLAUDE_PLUGIN_ROOT}/prompts/clusters/unsafe-boundary.md"

   resolves.
2. Codex —

   ${CODEX_PLUGIN_ROOT}

   (set it the same way if that var is present and resolves the marker).
3. Fallback search — covers Codex installs under

   ~/.codex

   , Claude installs under

   ~/.claude

   , and a local checkout / repo run:

   Bash: find ~/.claude ~/.codex . -path '*/plugins/rust-review/prompts/clusters/unsafe-boundary.md' -print -quit 2>/dev/null

   . Take the match and strip the trailing

   /prompts/clusters/unsafe-boundary.md

   to get the root (the home dirs are searched before

   .

   so an installed copy wins over any vendored copy in the audited repo).

RUST_REVIEW_PLUGIN_ROOT

python3 "${RUST_REVIEW_PLUGIN_ROOT}/scripts/..."

• finding_scope_root

  — the user-requested audit subtree. Workers may only file findings whose vulnerable location is inside this subtree.

• context_roots

  — read-only repo roots/files workers and judges may inspect to verify reachability, callers, wrappers, build flags, mitigations, and threat-model details. Default to

  .

  unless the user explicitly forbids broader context. Reading context outside

  finding_scope_root

  is allowed; filing findings there is not.

• "

  unsafe

  is rare, so hand-skip the memory-safety cluster." Don't edit the cluster list — set

  has_unsafe

  accurately in Phase 1 and let

  build_run_plan.py

  decide. Every memory-safety bug class (UAF, double-free, uninitialized reads,

  Vec::set_len

  , union UB) requires

  unsafe

  , so the planner runs the whole

  memory-safety

  cluster when

  has_unsafe=true

  and correctly omits it when

  false

  — there is no "run it anyway." The unsafe-boundary cluster is different: it has no

  requires

  and always runs (consolidated; its safety-doc and

  repr(C)

  hygiene apply to FFI declarations even without visible

  unsafe { }

  blocks).
• "The compiler caught it." The borrow checker proves absence of safe-code data races; it proves nothing about unsafe blocks, panic reachability, ABBA deadlocks, atomic-load/store sequencing, or FFI ABI mismatch.
• "

  unwrap()

  is fine if it's

  // SAFETY: documented infallible

  ."

  // SAFETY:

  documents

  unsafe

  operations, not infallibility claims. An

  unwrap()

  on documented-infallible input is still risky if the documentation is wrong — file as low severity and let the FP judge decide.
• "

  has_unsafe=false

  so skip the run." Pure safe-Rust crates still have panic-DoS, atomic races, drop-panics, and trait-implementation hazards. Run the always-on clusters.
• "Background spawns parallelize the workers." They do not —

  Agent

  calls in a single assistant message already run concurrently.

  run_in_background=true

  defeats the Phase 6a primer cache, so every worker pays full cache-creation (

  cache_read_input_tokens=0

  ) and the ~15 K-token primer is wasted M times. Default: omit

  run_in_background

  from worker spawns.
• "I'll re-derive the cluster list / paths / pass prefixes inline instead of running

  build_run_plan.py

  ." The script is the only authority for selection and rendering. Paraphrasing it drops fields that the worker self-check requires, producing

  worker-N abort: spawn prompt malformed

  . Always run the script and

  Read plan.json

  .
• "The run partially succeeded — I'll just write

  REPORT.md

  from what completed." Hiding partial runs behind a successful report is a correctness bug. If any Phase-5 cluster task is not

  completed

  , surface it prominently in

  run-summary.md

  and the final response.
• "Zero findings — skip Phase 8." Always run both judges and Phase 8b: dedup-judge writes a minimal no-op

  dedup-summary.md

  on an empty index, fp-judge writes empty

  REPORT.md

  /

  REPORT.sarif

  , and Phase 8b's SARIF generator emits

  results: []

  for the empty case. SARIF consumers depend on a stable artifact set.
• "

  Bash: ls README*

  is fine for the preflight." Under zsh, an unmatched glob aborts the whole compound command before

  2>/dev/null

  runs. Use

  find

  (never fails on no-match) — and not

  Glob

  , which is unavailable to an agent that also holds

  Bash

  .

STOP — read this before composing the spawn message.

Workers MUST be spawned foreground (no

run_in_background

field, or

run_in_background=false

). "Parallel" here means one assistant message containing the wave's

Agent

calls — that already runs them concurrently. (For large

M

, split into consecutive waves of ≤16 calls, one message per wave — see "Required spawn shape" below.) Background spawns are NOT how you parallelize this skill.

Background spawns defeat Phase 6a's primer cache: every worker pays full cache-creation on its first turn (

cache_read_input_tokens=0

), and the primer's ~15 K tokens are wasted M times over. Two real runs had exactly this symptom — every worker started with

first_cr=0

.

Before sending the spawn message, audit your draft: every

Agent

call must have no

run_in_background

key. If you wrote

run_in_background=true

, delete it.

Agent

Agent

M

Agent

M > 16

Agent

• Within a wave: all

  Agent

  calls in one message, foreground (no

  run_in_background

  ) — identical shape to a single-wave run.
• Across waves: wave k+1 is a separate message that can only be sent after wave k's

  Agent

  calls all return (a tool-use message ends the turn). Waves are therefore serialized with respect to each other — that is correct and loud; accept it. Do not try to overlap them.
• Never reach for

  run_in_background=true

  to fit more workers in one message. More waves, never background — background defeats the primer cache (see the STOP box) and is the cardinal error this skill guards against.
• Cache across waves: the primer prefix has a ~5-minute cache TTL that refreshes on every hit, so back-to-back waves keep hitting it (the 25-worker run confirmed

  cache_read≈14 K

  on its second wave). If a later wave will start more than ~5 minutes after the previous one (very large

  M

  or slow workers), re-spawn the Phase-6a primer in its own message first to re-warm the prefix before that wave.
• Balance the waves (e.g.

  M=25

  → 13+12, not 20+5) so no wave hugs the cap and the last wave isn't a tiny straggler.
• After every wave has returned, proceed to Phase 7 with the full set of M worker results.

N ∈ [1..M]

1. Read: ${output_dir}/worker-prompts/worker-N.txt

2. Pass the file contents verbatim as the

   Agent

   tool's

   prompt

   argument:

subagent_type

rust-review:rust-review-worker

model

${worker_model}

description

Rust review worker N

prompt

worker-N.txt

run_in_background

false

true

worker-N abort: spawn prompt malformed

• Passing

  run_in_background=true

  (see warning above).
• Cramming more than ~16

  Agent

  calls into one message when

  M

  is large — the harness silently keeps only the first ~20 and drops the rest. Use balanced waves of ≤16, never background spawns, to cover all M.
• Hand-typing the spawn prompt instead of reading

  worker-N.txt

  .
• Inserting Task-related instructions ("first call TaskList", "Assigned task id: <N>"). Workers have no Task tools.
• Editing the rendered prompt before passing it (trimming "redundant" fields, collapsing pass lists).

Reconcile by basename (finding ids are unique), so a path-format difference

between the worker

find

and this one (trailing slash, /var↔/private/var)

cannot manufacture false orphans. Any basename on disk but in no shard is an

orphan whose worker failed to record it.

The shards stay the per-worker audit trail (`validate_artifacts.py` checks them) and the dedup-judge's crash-recovery fallback, but they no longer gate what reaches the pipeline. For each orphan basename the reconcile prints, map its `<PREFIX>` to the owning worker via `plan.json` and note in `run-summary.md` that that worker's shard was incomplete — the finding is already in the index (so it is not lost), but the bookkeeping gap should be visible. Still cross-check the index line count against the sum of `wrote N` worker claims; log mismatches but don't abort.

After task updates and index creation, run `TaskList` and write `${output_dir}/run-summary.md` with:

- resolved parameters (`threat_model`, `severity_filter`, `finding_scope_root`, `context_roots`, capability flags `has_unsafe`/`has_ffi`/`has_concurrency`/`has_async`, Cargo manifest status)
- worker outcome table (`worker_n`, `cluster_id`, claimed finding count, shard line count, coverage-file path (`coverage/worker-{N}.md`), task status, retry/abort state)
- `findings-index.txt` line count and any mismatch against worker claims
- judge status once Phase 8 finishes, or the reason a judge was skipped/failed

If any Phase-5 cluster task is not `completed` — **or** any worker returned a `complete:` line carrying the `truncated at hard cap` token (it hit the tool-call cap before searching every pass; its coverage file will show one or more `cleared (NOT SEARCHED — truncated at hard cap)` rows) — include it prominently in `run-summary.md` and the final response. A hard-cap-truncated worker is marked `completed` for ledger purposes but is a **partial** result: do not let that `completed` status hide the incomplete coverage behind a successful report.

**Always run Phase 8 even on zero findings** — both judges short-circuit on an empty index: dedup-judge writes a minimal no-op `dedup-summary.md`, and fp-judge writes empty `REPORT.md`/`REPORT.sarif` so SARIF consumers get a stable artifact set.

findings-index.txt

dedup-summary.md

fp-summary.md

REPORT.md

REPORT.sarif

agents/rust-review-{dedup,fp}-judge.md

prompts/internal/judges/

STOP — these two judges run in SEQUENCE, not in parallel. Unlike the Phase-6b workers (which you spawn as M

Agent

calls in one message precisely because that runs them concurrently), the judges have a hard data dependency: fp-judge must see the

merged_into

/

also_known_as

annotations dedup-judge writes, and it only skips files already carrying

merged_into

. If you emit both

Agent

calls in one message they run concurrently — fp-judge reads findings before any merge annotations exist, judges every duplicate as a separate primary, and (because

dedup-summary.md

doesn't exist yet) trips its "dedup did not run" fallback, producing an inflated, duplicated

REPORT.md

/SARIF.

Spawn dedup-judge in its own assistant message, wait for its

dedup-judge complete:

(or

abort:

) return, then spawn fp-judge in a separate message. Before composing the fp-judge spawn, confirm dedup finished —

Bash: test -f ${output_dir}/dedup-summary.md

must succeed (or you saw the dedup

complete:

token). Never put both judge

Agent

calls in the same message.

1. First message —

   Agent(subagent_type="rust-review:rust-review-dedup-judge", description="Dedup judge", prompt=f"output_dir: {output_dir}")

   . Wait for its return and classify it (below) before continuing.
2. Then, in a separate message —

   Agent(subagent_type="rust-review:rust-review-fp-judge", description="FP + severity judge", prompt=f"output_dir: {output_dir}\nsarif_generator_path: {sarif_generator_path}")

   — resolve

   sarif_generator_path

   to

   ${RUST_REVIEW_PLUGIN_ROOT}/scripts/generate_sarif.py

   .

• … complete:

  → success.

• … abort:

  → non-retryable for that judge. Surface the abort line plus

  ls -l ${output_dir}/findings-index.txt

  , then still run Phase 8b (its SARIF +

  REPORT.md

  safety net guarantees the artifact set even when a judge aborts — see Phase 8b's "fp-judge returned, or the run aborted early" entry), and stop without spawning further judges. "Stop" means do not continue the judge pipeline — it does not mean skip Phase 8b.
• No

  complete:

  (help message / error / question) → retryable once.

  SendMessage(to=<agentId>, …)

  rather than a fresh spawn (the agent already paid the protocol-parse cost). Include the explicit finding paths from

  findings-index.txt

  . If the second try still fails, surface the transcript and continue to Phase 8b.

${output_dir}/REPORT.sarif

${output_dir}/REPORT.md

test -d "${output_dir}/findings" && python3 "${RUST_REVIEW_PLUGIN_ROOT}/scripts/generate_sarif.py" "${output_dir}"

findings/

results: []

fp_verdict

LIKELY_TP

severity_filter

unjudged: true

severity_validated: false

[UNVALIDATED SEVERITY — not judged]

medium

high

REPORT.sarif

WARNING: skipped N …

invocations[].properties.skipped_findings

warning

run-summary.md

completed

REPORT.md

REPORT.md

REPORT.md

Bash

Write

Write

Write

Write

Bash

REPORT.md

• If the fp-judge returned the report body in its transcript,

  Write

  that text verbatim to

  ${output_dir}/REPORT.md

  .
• Otherwise synthesize it from the on-disk findings: take the survivor primaries (

  fp_verdict ∈ {TRUE_POSITIVE, LIKELY_TP}

  , no

  merged_into

  ; if the judge never ran, treat a finding with no

  fp_verdict

  as a survivor) listed in

  findings-index.txt

  , apply

  severity_filter

  from

  context.md

  to judged survivors only — unjudged findings (no

  fp_verdict

  ) are included regardless of filter and rendered under an

  Unvalidated (severity not judged)

  section with a

  [UNVALIDATED SEVERITY — not judged]

  label, mirroring the SARIF behavior so a strict filter never silently drops them — and

  Write

  a

  REPORT.md

  mirroring the fp-judge template — YAML frontmatter (

  stage: final-report

  ,

  threat_model

  ,

  severity_filter

  ,

  total_primaries

  ,

  reported_findings

  ), a severity-distribution table, then one section per reported finding grouped by severity (embed the Description / Code / Data flow / Impact / Recommendation body for CRITICAL/HIGH; reference the finding file for MEDIUM/LOW).

${output_dir}/run-summary.md

REPORT.md

${output_dir}/findings/

${output_dir}/run-summary.md

agents/rust-review-worker.md

1. Worker — base fields (

   id

   ,

   bug_class

   ,

   title

   ,

   location

   ,

   function

   ,

   confidence

   ,

   worker

   ) + seven body sections.
2. Dedup-judge — adds

   merged_into

   on duplicates, or

   also_known_as

   +

   locations

   on primaries that absorbed.
3. FP+Severity judge — adds

   fp_verdict

   +

   fp_rationale

   on every primary; on survivors (

   TRUE_POSITIVE

   /

   LIKELY_TP

   ) also adds

   severity

   ,

   attack_vector

   ,

   exploitability

   ,

   severity_rationale

   .

• Every Phase-5 cluster task is

  completed

  (verify via

  TaskList

  ).

• ${output_dir}/run-summary.md

  exists and records resolved scope/context, Cargo manifest probe result, worker claims vs index count, task status, and judge/SARIF status.
• Every primary finding (no

  merged_into

  ) has

  fp_verdict

  +

  fp_rationale

  ; every survivor (

  TRUE_POSITIVE

  /

  LIKELY_TP

  ) also has

  severity

  ,

  attack_vector

  ,

  exploitability

  ,

  severity_rationale

  .

• REPORT.md

  exists, severity-filtered per

  severity_filter

  (Phase 8b safety net guarantees this even when the fp-judge fails to write it).

• REPORT.sarif

  exists (Phase 8b safety net guarantees this).