Configure code review policy

Start with comment-only reviews and no additional instructions. Each configured reviewer uses its native /review behavior, while the platform keeps the review read-only and records the policy version used for the run.

Choose review behavior

Open Code reviews and select Policy. The organization has one policy that applies to every repository. Keep Leave comments selected while evaluating review quality. Leave comments and approve when acceptable allows the orchestrator to recommend approval only after every hard safeguard passes.

Turning code reviews off pauses new reviewer-triggered runs without forgetting the selected outcome.

After someone requests 143 Code Reviewer once, new commits pushed to the pull request durably trigger a new assessment until 143 approves the PR. Automatic commit reassessments wait for a 60-second quiet window, so a rapid sequence of pushes collapses onto the newest head instead of spending reviewer capacity on commits that have already been replaced. If the active assessment notices the new head before the webhook handoff completes, it also queues the latest-head assessment as a fallback; the old attempt is shown as superseded rather than as a failed verdict, and the fresh assessment can still approve. Human review submissions, edits, and dismissals; inline review comment changes; resolved or reopened review threads; PR title or description edits; readiness changes; completed checks; and commit-status updates continue through normal PR synchronization without starting another review session. Title or description edits do not by themselves invalidate otherwise usable coding-agent evidence or block approval; description evaluation is best effort against the text captured by that assessment, while live checks and other deterministic approval gates are still refreshed before publication.

An explicit new reviewer request is different: while the latest 143 result is not an approval, requesting 143 again starts a distinct assessment even when the commit SHA has not changed. Use this when you specifically want description-only edits to receive a fresh coding-agent assessment; it is no longer required merely to avoid a stale-context blocker. GitHub webhook redeliveries reuse the assessment created for the original delivery even if policy or commit state changes later; if the first attempt never reached the worker queue, redelivery retries it safely. A new request received while reviewer agents are active waits durably for that work to finish before starting. The existing rolling PR comment is updated in place and identifies the latest assessed commit and time, while the Code reviews page retains each assessment as audit history.

When a review starts, 143 asynchronously posts a best-effort PR conversation comment with a link to the running session. When the session finishes, that same comment is updated with the result. During a reassessment, the rolling comment keeps the previous completed verdict visible, labels the commit it assessed, and links to the new running session until the replacement result is ready; stable blockers found for the active commit appear alongside that prior verdict. Later review passes reuse the same comment, so the PR keeps one current visible 143 summary instead of accumulating one per commit. Formal GitHub reviews remain marker-only except for approval state and inline findings. To keep review noise low, 143 posts inline findings only for P0 and P1 issues. The rolling summary groups policy thresholds, review findings, and decisions that need human judgment; platform review failures appear separately from code risk, and a single blocker is identified against the assessed commit. P2 and P3 observations remain advisory: they do not affect approval or create line comments, but their details are available in a collapsed section and in the linked 143 review evidence.

Stable size, path, fork, and author-policy failures appear in that rolling summary before reviewer agents finish; check, branch, and head-change state waits for the terminal decision because it can change during a run. By default, 143 continues the substantive review so the result still includes code findings. Administrators can enable Stop after stable policy blockers under Policy → Safeguards → Quality gates to skip reviewer and orchestrator work on the first blocked attempt. If a developer explicitly requests another review at the same commit, 143 treats that as a request for the full substantive review instead of stopping a second time. Analytics reports early stops, avoided reviewer runs, and same-head rerequests.

Once 143 submits an approval, that approval is final for the PR: later changes and reviewer rerequests do not start another 143 assessment, so automation never reverses or contradicts the approval.

Challenge a review decision

Organization admins and members can open a completed review's Evidence panel and select Ask for reconsideration for a non-approval or Report an unsafe approval for an approval. Explain what the review missed and, when available, select the policy reasons you are contesting. The original decision and evidence remain immutable while the panel shows the dispute's intake, reassessment, escalation, and adjudication timeline.

On GitHub, every human mention of the configured reviewer after a completed decision, plus replies in 143's inline finding threads, is classified from the full comment by the review triage model. There are no disagreement keywords or punctuation rules to remember. A bare request to review again returns to the normal reviewer workflow and uses the rolling review comment for status; objections, questions, and chatter follow their corresponding dispute routes. In Phase 1A, a trusted pull request author can trigger a reassessment of the latest pull request revision when another run could help; other maintainers and outside contributors are still recorded and answered, but cannot spend organization compute on a dispute reassessment automatically. Semantically unchanged objections within the policy's Reassessment cooldown are deduplicated with a clear response. Admins can tune that cooldown under the policy's advanced approval criteria.

Unsafe-approval reports do not reverse an existing GitHub approval or automatically rerun the reviewer. They enter the policy-owner list for human judgment. Admins use the Disputes tab to uphold, reject, or request more context; only an upheld dispute is evidence that policy should change. An admin can also promote an untrusted captured report from the review's Evidence timeline when its provenance has been checked.

For organizations with sustained dispute volume, 143 ranks that queue using explainable signals such as an independent human contradiction, an unchanged reassessment, repeat objections against the same reason, and whether the filer is the pull request author. These signals only order attention; an administrator still decides every dispute. The Analytics tab shows decision and objection distributions, reassessment flip rate and spend, and actual-versus-limit observations for deterministic policy gates.

Monitor and recover reviews

The Reviews tab reports the current stage of each active attempt: syncing with GitHub, reviewing, synthesizing, or publishing. If GitHub rate-limits an operation, the attempt moves to Waiting for GitHub and shows when automatic processing will resume. You do not need to start another review while that countdown is active.

The default Current reviews view and its headline metrics omit attempts superseded by a newer commit or replacement run. Use Superseded history to inspect those neutral audit records, or All attempts to include every historical attempt. Superseded attempts remain available for evidence and debugging, but they do not inflate ordinary review totals or outcome percentages.

When automatic recovery is exhausted, the failed attempt keeps a concise error and recommended action in its row and evidence panel. Organization admins and members can select Retry review for failures marked retryable. A retry creates a new session against the pull request's current head and current policy; it never rewrites the failed session or its evidence. The original attempt links to the replacement for audit history.

A retry is rejected if the pull request has moved to another commit, is no longer open, already has a 143 approval, already has a newer replacement, or the current code review policy is disabled.

Evaluate approval behavior

Use the Analytics tab to evaluate pull requests first sent to 143 in a repository or the organization over the last 7, 30, or 90 days, or across all recorded history. Each pull request contributes once even when it required several review attempts. The report shows eventual 143 approvals, approval rate, approval by distinct-head review round, median rounds to approval, usage by pull request author, median additions and deletions by author, finding rates, and the most common structured reasons approval was withheld.

Later rounds remain attached to the pull request's original first-request time cohort, including approvals completed after the selected window. Failed, stale, cancelled, and same-head retry attempts do not add review rounds. Older reviews may not have captured additions, deletions, or structured reason data, so treat small historical samples as directional rather than representative.

Use the report to tune policy deliberately:

• A high first-round approval rate suggests the current policy and author workflow usually converge without another commit.
• Frequent second- or later-round approvals show where authors commonly need iteration before 143 can approve.
• Frequent blocking findings point to code-quality concerns, while description, check, quorum, or sensitive-path reasons point to specific deterministic safeguards.
• PR-author totals show whose pull requests receive automated reviews; they do not claim who clicked or mentioned the reviewer.

Separate guidance from safeguards

Additional review instructions are optional team guidance for priorities, domain risks, and comment style. They are appended after each agent's native /review command. Leave them empty to use built-in reviewer behavior.

Automated approval policy guides how the orchestrator classifies findings and identifies non-code decisions that need human judgment. The backend makes the final decision from explicit evidence: P0 and P1 code findings block approval, while P2 and P3 findings are advisory. Architecture, ownership, operational risk, sensitive changes, or another policy requirement can still require a human, but 143 states that reason in the result instead of relying on a hidden model veto. By default, approval evaluates the code without requiring GitHub checks to pass. If you enable a passing-check requirement under Safeguards, the prompt cannot override it; path restrictions, size limits, quorum, disagreement handling, fork restrictions, and other enabled safeguards also remain authoritative.

143 evaluates the current pull request independently of existing human review activity. Human comments, review decisions, and open or resolved review threads—including unresolved change requests—do not become findings or block 143's approval. Repository branch protection and merge rules still apply independently on GitHub.

Use a prompt example when it matches your intent. Previewing and applying an example replaces only its corresponding prompt; it never changes enablement, outcome, reviewers, paths, thresholds, or safety gates.

Under Safeguards → Reviewers & agents, choose a reasoning level beside each reviewer model. Reviewers can use different levels in the same run. The default is High, and the available choices follow the agent selected in that row. Configure the orchestrator's reasoning separately beside its model.

Apply one policy everywhere

Policy changes apply to new reviews in every repository. There are no repository overrides or inheritance rules to reconcile.

• Configure approval behavior, prompts, safeguards, and reviewer agents once.
• Review sessions capture the policy version they used, so historical review evidence remains auditable after the policy changes.
• GitHub reviewer setup is still selected per repository because the reviewer team must be granted access to each repository separately. In Policy → GitHub reviewer connections, choose Add repository to connect an available GitHub App repository and set up its reviewer in one flow. A repository that connects successfully but fails reviewer setup remains connected and offers a retry.

Policy history remains insert-only. Reviews already in progress continue using the policy version captured when they started.

Recover from validation or save failures

Autosave status appears beside prompt editors. If a save fails, the local prompt remains visible so you can correct or retry it. Invalid advanced settings open the relevant controls and display the backend field error without including prompt contents in logs or analytics.