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.
[ 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
GitHub webhook
Classify PR risk
Decision
Low-risk?
Rubber-stamp vs deeper review
Post approval
Launch Pair Reviewer worker
Post approval
Decision
Low-risk?
Rubber-stamp vs deeper review
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.