Configure code review policy

Start with comment-only reviews and no additional instructions. Each selected 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. Once 143 approves, later code changes continue through normal PR synchronization without starting another automatic reviewer session. 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 also synchronize without triggering a review. 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.

Supply visual evidence

143 captures screenshots and other raster images rendered in the pull request description, PR conversation comments, submitted review bodies, and inline review comments. Images from any of those surfaces can satisfy a PR evidence requirement when the orchestrator finds them relevant to the current change. Discussion images are included only when GitHub identifies the author as a human user, including outside contributors; bot, app, organization, deleted, and unknown actors are excluded.

Every reviewer and the orchestrator receive the same immutable image snapshot for the assessed commit. Image pixels, filenames, alt text, captions, and nearby discussion are always untrusted pull-request content: 143 uses them as factual evidence but never as instructions or as independent reasons to block approval. Under Policy → Safeguards → Structured PR-description checks, set a requirement's Evidence type to Visual evidence when text alone must not satisfy it. 143 uses this explicit setting rather than guessing from the requirement title or instructions. An image-backed passing assessment cites the captured evidence ID. A preview link or repository-native visual artifact can also satisfy a visual requirement when the assessment states that basis; description text or diff text alone cannot.

Existing screenshots remain valid across later commits when they still accurately represent the affected UI or workflow. 143 evaluates currentness from whether the diff materially changes the rendered state shown by the image, not from the image timestamp or the fact that the pull-request head changed. The default UI-evidence rubric treats small changes that do not materially alter rendered output, non-visible changes, test-only changes, refactors, and unrelated changes as not applicable. Updated screenshots are required only when the existing evidence no longer represents the changed experience.

Open the review's Evidence panel to see captured thumbnails, source surface and author, status, failure details, and which images the orchestrator cited. 143 retains per-image provenance for the first 32 images across the description and human discussion; the panel reports only an aggregate omitted count for any later images. Inaccessible, unsupported, or oversized retained images remain visible as provenance but cannot satisfy a requirement. A review uses the snapshot taken when that assessment began; request 143 again if description or comment edits on the same commit should be evaluated in a new assessment.

An explicit new reviewer request is different: every genuinely new request starts a distinct assessment, including after a prior approval or when the commit SHA has not changed. Use this when you want description-only edits to receive a fresh coding-agent assessment or deliberately want another review after automatic monitoring has stopped. 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 explicit-username author-policy failures appear in that rolling summary before reviewer agents finish; GitHub team membership, 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.

Under Policy → Safeguards → Paths, authors & checks, configure an optional auto-approval whitelist with individual GitHub usernames and qualified GitHub teams such as acme/platform-reviewers. The user and team lists are combined: an author may match either one. If both lists are empty, author identity does not restrict approval. Team entries use the GitHub team's slug, and 143 checks that the PR author is an active member through the repository's GitHub App installation immediately before approving. If membership cannot be verified, 143 does not approve the PR automatically.

Pushing code does not start another assessment after 143 submits an approval. A later explicit reviewer request can run a new assessment, but 143 does not dismiss the earlier GitHub approval automatically.

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 user-attributed 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. This includes comments submitted through a third-party GitHub App acting on the user's behalf, such as Graphite; bot-attributed comments and comments from 143's own app are excluded. 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. Human-posted images from those surfaces remain eligible only as visual evidence under the trust rules above. 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.

Choose reviewers and fallbacks

Under Safeguards → Reviewers & agents, set Number of reviewers to one, two, or three. Then arrange Ranked reviewer models in order of preference with the up and down controls. Use Add model to keep up to ten choices in the list; adding a model does not increase the number of reviewers that run.

143 starts enough available models from the top of the list to fill the requested reviewer count. If a model is unavailable or an attempt fails to produce a usable review, the next choice replaces it. For example, two reviewers with four ranked models start the first two available choices and keep the other two as fallbacks. A completed review with blocking findings still counts as a review and does not trigger a replacement.

Choose a reasoning level beside each model. The default is High, and the available choices follow the agent selected in that row. Moving a model preserves its reasoning level. Configure the orchestrator's reasoning separately beside its model.

All reviewer attempts share the configured timeout. Unused fallbacks remain idle, and failed attempts remain in the review evidence. Reviewer quorum in Approval criteria remains a separate approval safeguard and cannot exceed the requested reviewer count. Lowering that count lowers quorum when needed. Existing policies keep their previous reviewer count until you change it.

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.

Inspect and restore policy changes

Organization admins can open Policy and select the Last activity footer to inspect saved policy history. The history panel summarizes each change in policy language, identifies who made it and when, and expands to show exact before-and-after values. Text guidance uses a line diff, list settings show added and removed entries, and other settings show the previous and new values. Use the version selectors to compare any two loaded versions; load older history when the version you need is not yet listed.

The latest entry stays in the history so its change can be compared with the preceding version. Request, session, IP, user-agent, and tool metadata is available under Details when that information was captured.

To return to an earlier configuration, expand that historical entry and select Restore as new version. Restore never rewrites or deletes history: it copies the earlier configuration into a new latest version. If someone changes the policy after the confirmation opens, the restore stops and asks you to review the newer policy before trying again.

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.