Reviewer pipeline

The reviewer pipeline is how Synthex turns "many reviewers, many findings" into one ranked list of things to fix. It's the same shape across plan review and code review — fan out, consolidate, address, repeat.

#How does a review run?

A single review cycle has five stages:

1. Context bundle. The orchestrator assembles the artifact under review (diff, plan, PRD) plus its surrounding context (project conventions, specs, prior decisions) into a bundle each reviewer can consume. For multi-model review, a script writes the bundle file without a model call; only files too large to inline get a short summarization call.
2. Fan-out. All configured reviewers run in parallel. Each one is independent. None sees another's findings until the consolidator combines them, which prevents groupthink and surfaces disagreement honestly.
3. Findings consolidation. The Findings Consolidator agent takes raw reviewer outputs and produces a single deduplicated, severity-ranked list. It does not add new findings, does not change severities, does not edit reviewer wording beyond what consolidation requires. It exists to save the orchestrator's context window — three to five overlapping reviewer reports become one tractable list.
4. Address. Whoever owns the artifact addresses every finding at or above the severity threshold: the caller for code (the Tech Lead inside /synthex:next-priority/synthex:next-priority, or you when /synthex:review-code/synthex:review-code runs standalone — the command itself never applies fixes), the Product Manager for plans, and the refine command itself for PRDs.
5. Re-review. Fresh reviewer instances (never resumed from the last cycle) re-run on the updated artifact, with a one-line summary of each still-open finding. If unresolved findings remain at the threshold, the cycle continues — bounded by max_cycles.

If the loop exits with findings still open above the threshold, those findings are recorded in the completion summary. The user chooses whether to merge, iterate further, or split the remainder into a follow-up task.

#Reviewers by command

Different commands run different reviewer rosters. The defaults:

Each command has a reviewers: block in .synthex/config.yaml that lets you add specialists, disable defaults, or change the focus prompts. See Configuration for the exact keys. A reviewer entry can also be a markdown prompt file from your repo, such as an existing CI review prompt; see Prompt-file reviewers.

#Checking findings before they count

Two opt-in checks cut false positives among critical and high findings:

• Verification pass (code_review.verification: prose). The code, security, and performance reviewers each check their top five critical and high findings against the code, using a language-server tool or grep, and mark each one confirmed or plausible. See Verification pass.
• Refute pass (code_review.refute_pass: on, review engine only). Three independent refuters challenge each critical and high finding; one that two of them reject is dropped. See Workflow engines.

#Why parallel and independent

Two questions every project asks early:

Couldn't one capable reviewer do the work of three?

Yes, and the result will be coherent — but it will reflect that one reviewer's biases. Two reviewers who never see each other's drafts produce two genuine perspectives. When they agree, the finding has higher confidence. When they disagree, the disagreement itself is signal: the issue is more nuanced than either alone could capture.

Couldn't reviewers run sequentially, with each one seeing the prior?

That collapses into the first scenario over time. The second reviewer optimizes for completing the first reviewer's narrative. Independence is what gives you two genuine angles, and that costs you a little redundancy in exchange for catching different errors.

#Findings consolidator: the mechanical layer

The Findings Consolidator is intentionally narrow. It runs Haiku because the work is purely structural. With code_review.engine: workflow, /synthex:review-code/synthex:review-code does this step in code instead, with no model call (see Workflow engines). Otherwise:

• Parse each reviewer's structured output.
• Group findings that describe the same underlying issue (same file, same line range, same vulnerability class).
• Preserve the original wording and severity from each reviewer.
• Sort by severity, then by file/line.
• Emit one consolidated list with reviewer attribution.

By making consolidation mechanical, the orchestrator gets a clean input it can act on without re-reading three reports. By keeping it narrow, the consolidator can't accidentally rewrite or soften a reviewer's verdict.

#The multi-model option

For high-stakes reviews, Synthex supports a multi-model review pipeline. The same diff is sent to the native reviewer (Claude) and to one or more external CLI adapters running other LLM families. The Multi-Model Review Orchestrator fans them all out in parallel, collects their verdicts, and feeds them through the same consolidator.

The shape is sometimes called proposer-aggregator: each model proposes findings independently; the aggregator (consolidator + orchestrator) merges and decides.

Why bother:

• Different model families fail differently. Claude's blind spots are not GPT's are not Gemini's. Catching errors any single family would miss is the entire point.
• Disagreement across families is high-signal. When one family flags a finding the others miss, it deserves attention even if its severity vote is borderline.
• It's optional and per-command. You can run multi-model on /synthex:review-code/synthex:review-code for production code paths and skip it for documentation changes.

The mechanism is configured in the multi_model_review block. Each command decides whether to take the multi-model branch from that config, the --multi-model / --no-multi-model flags, and, for /synthex:review-code/synthex:review-code, a complexity gate that skips trivial diffs. See Multi-model review.

Turning external review off is restrictive-wins. If multi_model_review.enabled (or any enabled key under it) is false in your user config, the shared project config, or your project-local config, it stays off, even if another layer says true. A repo can't send your code to an external CLI after you've opted out. The external model names under multi_model_review.per_reviewer come from your user config first, because which models are installed depends on your machine. See Configuration.

#How the loop bounds itself

The default is max_cycles: 2 (most commands) or 3 (plans, since plan defects ripple). The cycle counter is per-review, not per-task — sending a task back through review starts a fresh counter.

When the loop hits its cap with unresolved findings:

• The findings are recorded with reviewer attribution and severity.
• The completion summary includes them as Open Findings.
• The user sees them in the merge prompt and decides what to do.

You can raise or lower the cap per command in config:

implementation_plan:
  review_loops:
    max_cycles: 3

code_review:
  review_loops:
    max_cycles: 2

There's no global way to disable the loop — that would mean shipping unreviewed changes, which the project is opinionated about not doing.

#What the pipeline doesn't do

• It doesn't merge. Reviewers and the consolidator are advisory. The orchestrator decides what to fix and the gate decides whether to merge.
• It doesn't run quietly. Every cycle's findings are surfaced to you. The point is transparency, not friction.
• It doesn't replace human judgment. [H] criteria still require explicit user approval. Reviewers can recommend; only you can sign off.

#Next

• Quality gates — the merge contract reviewers feed into
• The lifecycle — where reviews sit in the five-phase loop
• Configuration — tune reviewer rosters, severity, and cycle caps