/synthex:review-code/synthex:review-code

#What it does, end-to-end

/synthex:review-code/synthex:review-code is the standalone command for reviewing a diff. It runs the same reviewer pipeline that /synthex:next-priority/synthex:next-priority uses internally during the build phase — but here it's user-facing, so you can invoke it on demand against any diff.

Each invocation:

1. Routes to a standing pool, if one is running. With standing_pools.enabled: true and a running pool whose roster covers the configured reviewers, the review is submitted to that pool and the pool's report is the review. Prompt-file reviewers don't run on that path. See Standing pools. Otherwise it continues below.
2. Resolves the diff under review. Default: the staged changes, or the unstaged changes when nothing is staged. Pass target to review specific files, a directory, or a git range such as main..HEAD.
3. Gathers context. The project instruction file (AGENTS.md, CLAUDE.md, or your harness's equivalent), the convention sources (.eslintrc, .prettierrc), and the languages and frameworks in the diff. Reviewers check relevant specs under code_review.spec_paths themselves.
4. Fans out to reviewers. The mandatory pair — Code Reviewer and Security Reviewer — runs in parallel, along with any extra reviewers configured under code_review.reviewers or code_review.specialists. When the diff touches UI files (.tsx, .jsx, .css, .scss, .vue, .svelte), the Design System Agent joins automatically — no config needed. With code_review.verification: prose, each reviewer double-checks its top critical and high findings before reporting them (see Verification pass). On Claude Code with code_review.engine: workflow and a Workflow tool available, this step runs through the review engine instead, and code_review.refute_pass: on adds an adversarial refute pass on critical and high findings.
5. Optionally fans out to multi-model. When both multi_model_review.enabled and multi_model_review.per_command.review_code.enabled are true (and the diff isn't trivial), or you pass --multi-model, the Multi-Model Review Orchestrator also runs external CLI reviewers from other model families. All findings feed into the same consolidator. --no-multi-model forces native-only for one run. See Multi-model review.
6. Consolidates findings. The Findings Consolidator dedupes, preserves attribution, ranks by severity. Output is one tractable list, not three-to-five overlapping reports.
7. Iterates the review loop. If findings at or above min_severity_to_address (default high) remain, the orchestrator (Tech Lead, when invoked from /synthex:next-priority/synthex:next-priority, or you, when run standalone) addresses them and reviewers re-run. Bounded by max_cycles (default 2).
8. Emits a verdict. PASS / WARN / FAIL with the consolidated findings list. The overall verdict follows the strictest reviewer: FAIL if any CRITICAL or HIGH finding remains after the cycle cap, WARN if only MEDIUM findings remain, PASS otherwise. WARN doesn't trigger the fix loop.

#Reviewer roster

Default mandatory pair:

code_review:
  reviewers:
    - code-reviewer
    - security-reviewer

Add specialists for performance-critical or regulated codebases:

code_review:
  reviewers:
    - code-reviewer
    - security-reviewer
    - performance-engineer
  specialists:
    - agent: compliance-reviewer
      focus: "Regulatory compliance, audit-trail requirements"

The convention: everything under reviewers runs in parallel on every review. specialists is an optional list of additional reviewers, each with a focus prompt. The Design System Agent needs no entry: it is added automatically whenever the diff touches UI files.

#Prompt-file reviewers

A reviewers entry can also point at a markdown prompt file in your project — for example, an existing CI review prompt — instead of naming a Synthex agent:

code_review:
  reviewers:
    - code-reviewer
    - security-reviewer
    - prompt: .github/scripts/pr-guardian/prompt.md
      id: pr-guardian # optional
      enabled: true # optional; false skips it

The prompt runs alongside the agent reviewers, and its findings flow through the same Findings Consolidator — deduped, severity-ranked, attributed to pr-guardian, and counted toward the PASS / WARN / FAIL verdict. On the multi-model path, prompt-file reviewers are launched alongside the orchestrator and merged into its report. A review routed to a standing pool does not run them. Synthex appends its own findings format to the prompt, so a prompt written for CI doesn't need rewriting — and the reviewer is told to ignore any instruction to post comments or otherwise act. That is a convention, not a sandbox: review prompt files as you would any code that runs in your repo. A bad path skips that one reviewer with a warning, never the whole review. See Prompt-file reviewers for the full key reference.

The id is optional. Without one, the reviewer is named after the file's frontmatter name; failing that, a generic filename (prompt.md, review.md, index.md) takes its directory's name, so .github/scripts/pr-guardian/prompt.md reports as pr-guardian. Any other file is named after its filename, without the extension.

#An empty roster fails

If every reviewer is disabled, skipped, or unusable — for example, a list made only of prompt-file entries whose paths don't exist — the review reports FAIL rather than an empty PASS. A review that checked nothing never reads as clean.

#What "PASS" actually means

A PASS verdict is not a guarantee the code is correct. It is a guarantee that:

• Both mandatory reviewers ran on the diff.
• All findings at or above the configured severity threshold were addressed.
• The diff matches the project conventions in convention_sources (within the reviewer's ability to detect).
• No spec violations were found in the configured spec_paths.

It does not guarantee runtime correctness, performance, or completeness — those are covered by tests, audits, and observation, not review. The reviewers are advisory; the final accountability for what merges is the orchestrating agent's (and yours, for [H] gates).

#When to invoke it directly

You normally don't — /synthex:next-priority/synthex:next-priority wraps it during the build phase. Reach for /synthex:review-code/synthex:review-code standalone when:

• Running review on a non-Synthex-orchestrated change (manual edit, hotfix, contributor PR).
• Reviewing a diff that's larger than code_review.max_diff_lines (default 300) — Synthex warns and asks before continuing; large diffs get lower-confidence findings.
• Re-running review after addressing prior findings without re-engaging the full Tech Lead workflow.

#Parameters

#Common scenarios

#"Diff is too large to review"

When a diff exceeds max_diff_lines, Synthex warns, suggests splitting it, and asks whether to continue. You have two options:

• Split the diff into smaller PRs, then review each. This is the higher-quality path.
• Confirm and proceed, accepting that findings will be less precise.

Synthex asks rather than refusing, because real projects sometimes need to review a large change.

#"All findings are below the threshold"

The verdict is WARN (MEDIUM findings) or PASS (only LOW findings), but the consolidated findings list is non-empty. These are recorded in the output for your review; they don't trigger the fix loop or block merge, but they're worth scanning. Some teams set a quarterly cleanup cadence to address accumulated medium findings as a batch.

#"Reviewers disagree on severity"

The Findings Consolidator preserves both verdicts with attribution. You decide. Disagreement is high-signal — usually it means the issue has a nuance one reviewer caught and the other didn't.

#Native looping

Pass --loop to re-run review until the diff stabilizes — useful when iterating on findings without leaving the command. The framework contract (state file, resume semantics, auto-compaction) lives at Native looping; this section covers only the command-specific emission rule.

Inner vs. outer. The pre-existing review_loops.max_cycles (default 2) is the inner review-cycle bound — reviewers re-run after findings get addressed within a single /synthex:review-code invocation. --loop is the outer wrapper that re-runs the whole invocation. They compose without interfering: the inner cycle finishes per invocation; the outer loop's emission check fires only at end-of-invocation.

Emission rule. The loop terminates when:

• The cycle ended with zero FAIL findings, and
• All WARN findings are either resolved or explicitly accepted by the author, and
• No recommended-change items remain, and
• A follow-up iteration would not surface new findings on the current diff.

Example. Iterate review-and-fix on a branch until clean:

/synthex:review-code --loop \
  --completion-promise "REVIEW_CLEAN" \
  --max-iterations 10 \
  target=main..feature/payments-v2