Specialists

For local working-tree review, the Critique CLI classifies the change into evidence obligations and maps them to the canonical correctness, tests, security, architecture, and performance specialist lanes. The published CLI bundles 38 substantive review methodologies. Each methodology contributes an investigation method, required evidence, and a disconfirmation path; selected guidance is injected into the reviewer runtime and is not reported as a completed check until the reviewer actually performs it. See CLI reference and Independent verification protocol.

Local native review adjudication is evidence-aware: specialist agreement is recorded as corroboration but never treated as proof. Findings are deduplicated by affected code plus normalized claim. A current Critique-executed check can promote a finding to verified; an independent reproduction is required for proven. Weak one-lane inspection observations are registered as assumptions.

The sections below describe the complementary multi-pass hosted review pipeline used for connected pull requests. Its product verdict and policy model remain distinct from the CLI's independent review result and native completion.v1 proof.

The hosted review pipeline uses one evidence stage, four specialist lanes that run in parallel, and one synthesis stage that produces the hosted verdict. The CLI uses the same evidence-oriented shape locally, with isolated per-lane workspaces and a fresh lead reviewer that adjudicates lane output against the repository.

Evidence → Security | Tests | Architecture | Performance → Synthesis

Scout-style evidence gathering and lead synthesis are structural stages — they are not toggled off in policy. You can disable individual specialists via Policy fields.

Evidence gathering

Before specialists run, Critique assembles an evidence pack from the pull request:

• Changed files and patches
• Nearby source and test files when needed
• Repository guidance documents the team maintains
• Risk hints (for example auth, billing, API, automation paths)
• Linked issues referenced in the PR title or body

This pack is shared context so each specialist does not re-fetch the world independently.

Security

Looks for regressions in trust boundaries: authentication and authorization changes, injection surfaces, unsafe dynamic execution, secret handling, and high-risk areas changed without corresponding test movement.

Typical outputs are findings with severity WARNING or FAIL when the change increases exploit or data-exposure risk.

Tests

Checks whether behavior changes are backed by tests: missing coverage on touched logic, weak or misleading tests, and sensitive paths edited without test updates.

Often surfaces FAIL when critical paths change with no test signal and policy strictness treats that as blocking.

Architecture

Focuses on structure and boundaries: client/server mistakes, deep coupling, brittle imports, config contract drift, and module layout smells that will hurt the next change.

Findings are usually WARNING unless a change clearly breaks runtime boundaries (for example server-only modules pulled into client bundles).

Performance

Looks for obvious performance regressions: un-awaited async work, expensive client fetch patterns, serial awaits in hot paths, and similar issues visible from the diff.

Many performance findings are informational or warnings unless policy elevates them.

Synthesis

The lead stage:

• Deduplicates overlapping findings from multiple specialists
• Normalizes severity and locations for GitHub annotations
• Derives the verdict (PASS, WARN, FAIL) from finding severities and your strictness setting

The verdict logic is deterministic given findings and policy — the model polishes summary text but does not arbitrarily change blocking rules.

Finding shape

Each finding includes at minimum:

• Title and summary — human-readable explanation
• Severity — INFO, WARNING, or FAIL
• Confidence — how sure Critique is
• Location — file and line when mappable to the diff

Path escalations

Even if you disable a specialist globally, path escalations can force specialists back on when changed paths match sensitive patterns (auth, billing, etc.). See Policy fields.

Model selection

Default models per role are chosen for quality and cost balance on the hosted product. Installations and repositories may override lead and specialist models within plan limits.

Critique does not publish internal prompt text or heuristic pattern lists on this site — those are implementation details that change frequently.