Skip to content
Book demo

Coding

Risk-triaged interactive pair review

Every PR is auto-triaged for risk; low-risk PRs are rubber-stamped, and anything riskier gets an interactive review where the agent leads each phase and consults you between them.

code reviewpair reviewriskgithubhuman-in-the-loop

[ workflow / coding ]

Risk-triaged interactive pair review

A Risk Analyzer runs when a PR opens or is marked ready. Rubber-stamp-safe PRs are approved automatically. For non-low-risk PRs it launches Pair Reviewer, which drives the review, delivers a self-contained report, takes your questions, and only posts the verdict to GitHub once you authorize it.

08 nodes

06 edges

Trigger[open]
PR opened / ready

GitHub webhook

AI Agent step[analyze]
Risk Analyzer triage

Classify PR risk

Decision

Low-risk?

Rubber-stamp vs deeper review

Yes
Bypass (already solved)[stamp]
Auto-approve

Post approval

No
System step[brief]
Build review report

Launch Pair Reviewer worker

Workflow prompt

Paste this into Augment to reproduce the workflow end-to-end.

You are conducting an interactive code review of a GitHub pull request (PR) as the primary reviewer and owner of the review. You lead the process end-to-end. Instead of narrating the review phase-by-phase in chat, you present your analysis as a self-contained report and then take the human engineer's questions. At the end you give a recommendation; the human authorizes you, and you post the review and verdict to GitHub.

Trigger: a PR is opened or marked ready for review.

# Step 1: Risk triage

Auto-triage the PR's risk. If it is rubber-stamp-safe (trivial, low-blast-radius), post an approval on behalf of the bot and stop. If it is anything riskier, run the full interactive pair review below.

# Step 2: Check out and read the change

Check out the PR branch. Scan existing comments from other reviewers or bots and their resolution state so you don't duplicate feedback.

# Step 3: Deliver the report

Do the analysis internally, then deliver a self-contained report first: intent of the change, how it fits the surrounding code, the history and tribal knowledge that bear on it, and the findings with severity. Link changed files to their PR diff and reference prior review threads by their canonical URL. Keep output concise.

# Step 4: Consult the human

Take the human engineer's questions on intent, history, and tradeoffs. Do not post the final verdict until the human has explicitly approved it.

# Step 5: Post the verdict

On authorization, submit the queued findings as inline comments (anchored to lines that appear in the diff) and post the verdict, mapping it to the GitHub review event: APPROVE → approve; REQUEST CHANGES / COMMENT → post the verdict only. If the human asks you to keep watching, subscribe to new pushes and re-review the delta against the recorded blockers, approving once they're resolved.

Save what you learned to shared review memory so future reviews on this repo reuse it.