Template
Code review automation template
This template starts when a pull request opens, reads the change with its context, writes review comments against your checklist and holds them for a named reviewer, who decides what is posted.
Last reviewed 7 October 2026
Status
Designed
No template covers code review. The Marketplace listing GitHub MCP is a sample with nothing seeded behind it, and the code prompts are starting points only. The steps are the shape you would build in Studio.
No template covers this job yet. The steps below are the shape we would build and the shape you can build in Studio yourself.
The job
What this template does
Code review is owned by the engineers who maintain the repository, with a team lead setting the standard. The usual failure is queueing. A pull request waits a day, and the comments, when they come, are about naming and formatting that a tool could have raised. The harder questions get less attention.
This flow gives the reviewer a first pass written against your own checklist, with your build results alongside. It does not approve or merge anything. The human reviewer keeps the decision, and your Git host’s branch protection stays the control that stops a merge.
Workflow
The workflow, step by step
Steps marked as approval gates pause the run until a named person approves. Nothing after a gate runs before that decision, and the decision is recorded.
- 01
Start on a pull request event
The Git host sends a webhook when a pull request opens or is updated. The workflow reads the title, description, author, changed files, the diff and any linked issue. It ignores drafts and bot updates you list. The next step receives the change and its metadata. - 02
Gather context
The workflow fetches the full text of the changed files, the files they import, the code owners file and the contributing guide. A diff alone hides what a function is called by. The next step receives the change together with the surrounding code. - 03
Read the build results
The workflow waits for your continuous integration run and reads its outcome: tests, linters and type checks. It does not run its own tests. Failures are attached to the change so the agent does not comment on what a tool already reported. - 04
Write the review
An agent reads the change with its context and your checklist, such as error handling, security-sensitive calls, missing tests and unclear naming. It writes comments tied to a file and line, with a severity, and lists what it could not assess. The reviewer receives the full set as a draft. - 05
Reviewer triage
The run pauses for the named reviewer. They keep, edit or discard each comment, and only the kept ones are posted to the pull request under the reviewer’s name or a label you choose. They then approve or request changes in the Git host themselves. The workflow cannot merge.Approval gate: a named person approves before the next step runs. - 06
Record what was kept
The workflow stores each agent comment with the reviewer’s decision to keep, edit or discard it. Over a few weeks that shows which parts of the checklist produce useful comments and which produce noise, so you can change the checklist rather than argue about it.
Controls
What it can do, cannot do, needs approval for, and records
Can
- Start from a pull request event and read the change with its context
- Read your build results rather than repeat them
- Write comments tied to files and lines, with a severity
- Post the comments a reviewer kept
Cannot
- Approve, request changes on or merge a pull request
- Post a comment the reviewer did not keep
- Push commits to the branch
- Replace branch protection in your Git host
Requires approval
- Posting any agent comment, by the named reviewer
- Any change to the review checklist, by the team lead
- Giving the workflow write access beyond comments, by the repository owner
Records
- The pull request, the commit reviewed and the context fetched
- Build results at the time
- Every comment drafted, with kept, edited or discarded
- The reviewer and the time
Honest labels
What the library holds for this job
| Asset | Type | Covers | Role in this flow |
|---|---|---|---|
| GitHub MCP | Marketplace sample listing | Sample listing, no template behind it | A sample listing for pull requests, issues, file reads and code search. Nothing is seeded behind it, so this page treats repository access as something you set up. |
| Code Refactoring Suggestion | Prompt | Used inside the flow | A starting prompt for suggesting a cleaner shape for a changed function. |
| Generate Unit Test Cases | Prompt | Used inside the flow | A starting prompt for suggesting missing tests for a change. |
| Github | Integration | Used inside the flow | Sends the pull request event and receives the comments you approve. |
Connections
Integrations this flow uses
- GitHub: Sends the pull request event and receives the approved comments.
- GitLab: The same role for merge requests.
- Jenkins: A source of build results if that is your continuous integration system.
- Slack: Tells the reviewer that a draft review is waiting.
The full list of tools Studio connects to is on the integrations page.
Before you start
What you supply, and what this page does not cover
- You supply the checklist, the repositories in scope, the reviewers and the Git host token. Give the token the narrowest permission that allows reading code and posting comments.
- Code is sent to the model you choose. Decide with your security lead which repositories may go to which model before you switch the workflow on.
- An agent review finds some defects and misses others. It does not replace a human reviewer, and this page quotes no figure for how many it catches.
- This is different from Nexus, which puts policy, approval and audit around coding agents that write code. This template reviews code a person or an agent has already written.
Common questions
- Can it merge pull requests?
- No, and we would not build it to. The workflow drafts comments and a person decides what is posted. Approving and merging stay with your reviewers in the Git host, where branch protection is the control that actually stops a bad merge. The workflow is advisory and sits beside it.
- How is this different from Nexus?
- Nexus puts policy, approval and audit around coding agents, so it governs an agent that writes code. This template reviews a pull request after the code is written, whoever or whatever wrote it. They can be used together, and neither depends on the other.
- Does it replace our linters and tests?
- No. It reads their results and avoids repeating them, so its comments are about the things tools do not catch, such as design, missing cases and unclear intent. Your continuous integration run remains the gate for correctness checks that a tool can decide.
- Does our code leave our systems?
- The diff and context go to whichever model you connect. If that model is hosted by a provider, the code goes to the provider under your terms with them. Decide the model per repository with your security lead. This page makes no claim about where any particular model runs.