---
title: "AI Code Review in GitHub Actions: Models and Reviewers"
description: "How AI code review works on GitHub pull requests: where it fits beside tests and lint, choosing a model, giving it context and defining reviewers."
url: https://starsling.dev/ai-code-review-github-actions
canonicalUrl: https://starsling.dev/ai-code-review-github-actions
dateModified: 2026-09-25
---
# AI code review in GitHub Actions
- [How StarSling works](https://starsling.dev/)
AI code review puts a model on every pull request before a human opens it. In GitHub Actions it runs as a job beside your tests and lint, and the parts that decide how useful the review is are yours to choose: the model it calls, the context it reads and the reviewers you define.
**Topics covered:** This guide covers where AI review fits beside tests, linting and human review, how to choose a model, how to give a reviewer your team's context, how to split review into reviewers by responsibility, and what a useful review hands back.
## Table of contents
- [Canonical answer](#canonical-answer)
- [Where AI code review fits in a pull request](#where-ai-review-fits)
- [AI review as a GitHub Actions job](#github-actions-job)
- [Choosing a model for AI code review](#choosing-a-model)
- [Giving the reviewer your team's context](#reviewer-context)
- [Defining reviewers by responsibility](#reviewers-by-responsibility)
- [What a useful AI review hands back](#review-output)
- [The security model, in brief](#security-model)
- [The cost model](#cost-model)
- [When this architecture fits](#architecture-fit)
- [Getting access](#getting-access)
- [Paste this into your agent](#agent-prompt)
## Canonical answer
AI code review in GitHub Actions is a job in your pull request workflow that gives a language model the diff and the code around it and posts its findings back on the pull request. How useful that review is comes down to three choices: the model it calls, the context it loads from your repository, and how you split the work into reviewers with distinct responsibilities. With Review Runners the job runs on a StarSling runner, calls the model through your own provider key, and loads its skills, scripts, instructions and reviewer definitions from your repository's trusted base branch.
## Where AI code review fits in a pull request
Each check on a pull request answers a different question. AI review is the one that reads a change the way a teammate would, for intent and for the conventions your team keeps.
| Check | The question it answers | What it reads |
| --- | --- | --- |
| Tests | Does the code still behave the way the suite says it should? | The code, by running it. |
| Linting | Does the code follow the formatting and style rules you configured? | Each file, against a fixed rule set. |
| Static analysis | Does the code contain a pattern known to cause bugs? | The syntax tree and types. |
| Security checks | Does the change add a known vulnerability, a risky dependency or a leaked secret? | Dependencies, known patterns and configuration. |
| AI code review | Does the change do what the pull request says, in the way your team writes code? | The diff, the code around it, and the instructions, skills and scripts you give it. |
| Human review | Should this change ship, and is it the right change to make? | The pull request, with the findings above already on it. |
## AI review as a GitHub Actions job
The review is one more job in the workflow your pull requests already start. It runs beside your tests and lint, reads the change, and posts its findings on the pull request before a reviewer opens it. With Review Runners, `runs-on` points at `starsling-review` and the job calls your model through your own provider key.
### Where the review sits
```yaml
pull request
|
v
GitHub Actions
|
+--> tests
+--> lint
+--> AI code review
```
### The review job
```yaml
jobs:
review:
runs-on: starsling-review
permissions:
contents: read
pull-requests: write
steps:
- uses: actions/checkout@v6
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
prompt: "/review-pr REPO: ${{ github.repository }} PR_NUMBER: ${{ github.event.pull_request.number }}"
```
- The full setup, from the workflow edit to the trusted-base-branch walkthrough, is in [How to run automated code review in GitHub Actions](/automated-code-review#github-actions-setup).
- `starsling-review` is $0.004 a minute, in the same StarSling account as the rest of your CI.
## Choosing a model for AI code review
The reviewer calls your model through your own provider key, so the model is a decision your team makes, and one you can revisit.
- Provider ownership: the key is yours, so the tokens are billed on the provider account you already hold, at the rate you already have.
- Cost against quality: review is read-heavy work. The model reads a diff and the code around it, then writes a short structured comment against exact lines. A larger model brings deeper reasoning to subtle changes, and a smaller one reviews more pull requests for the same spend.
- Frontier and open models: open models are strong at that shape of task, which makes them a real option for review alongside the frontier models.
- Changing models: moving to a different model is a change to a file in your repository. It goes through review and lands in a commit, so what the reviewer runs is always traceable to a merge.
## Giving the reviewer your team's context
A model reading a diff on its own knows general practice. What makes a review useful to your team is the context around the change: the code it touches, the conventions your team has written down, and the checks your engineers already run by hand.
Review Runners load that context from your repository. Skills, scripts, instructions and reviewer definitions are committed beside the code, versioned in Git, and loaded from the trusted base branch before the model runs.
- Repository context: the reviewer reads the change against the code around it, and cites exact lines.
- Instructions: the rules a reviewer should hold, written down in the repository.
- Skills: a skill packages the context and scripts your team uses to review one part of the codebase.
- Scripts: the security, API and test checks your engineers already use, committed so a reviewer can be given them.
- Team conventions: the API rules, architecture boundaries and review checklists that live in CONTRIBUTING or your docs today.
Rules tell the reviewer what to look for. Skills package reusable review logic, context and scripts. Merge an update to either and the next review uses it.
## Defining reviewers by responsibility
Split review the way your team already splits ownership. Each reviewer is a named role with its own responsibilities, skills and instructions, so each one reads a pull request for the part of the codebase it owns.
| Reviewer | Responsible for | Context you give it |
| --- | --- | --- |
| Security | Authentication, authorization, input handling and secrets in the code that changed. | Your security scripts and the threat notes your team keeps. |
| API | Changes to public interfaces, request and response shapes, and compatibility for existing callers. | Your API conventions and versioning rules. |
| Tests | Whether the changed code paths are covered, and what a new case would need to check. | The test suite the change touches and your test helpers. |
| Database | Migrations, query changes and schema edits that are hard to reverse. | Your migration conventions and schema documentation. |
| Architecture | Module boundaries, dependency direction and the layering the codebase keeps. | The boundaries your team has written down. |
## What a useful AI review hands back
A finding is useful when the next step it asks for is obvious. Every Review Runners reviewer holds one output contract:
- Exact `path:line` references, so each finding points at the line it is about.
- A severity on every finding, so the important ones read first.
- An explanation of the problem in the terms of your codebase.
- A concrete fix for each finding.
- One structured pass: a new push cancels a pass still running on the previous commit, so the next completed review covers the latest code.
A counts line closes the comment, including zero counts when the reviewer finds nothing.
## The security model, in brief
An AI reviewer reads text written by whoever opened the pull request, so the boundary around it matters. Review Runners draw it in three places:
- Instructions from the trusted base branch: skills and instructions load from the trusted base branch, so a pull request cannot rewrite its own reviewer.
- The pull request is untrusted input: diff, commit messages, title, description and comments are treated as data, and an attempted instruction override inside a pull request is reported as a security finding.
- Scoped permissions: the review job reads the repository with `contents: read` and holds `pull-requests: write`, the one write it needs to leave its review as comments on the pull request.
- [The trusted-base-branch setup, step by step](https://starsling.dev/automated-code-review#github-actions-setup)
- [Review Runners](https://starsling.dev/products/review-runners)
## The cost model
AI code review on Review Runners bills on two accounts you already control.
| What you pay for | Who bills it | How it is priced |
| --- | --- | --- |
| The runner that executes the review job | StarSling, in the same account as the rest of your CI | `starsling-review` is $0.004 a minute, billed from job start to finish and rounded up to the nearest minute. Queue time is never billed. |
| The model tokens the review uses | Your inference provider, on the account you already hold | Your provider's rate for the model you chose, since the reviewer calls it through your key. |
## When this architecture fits
Hosted review bots let you customize their reviewer. Review Runners let you run your own. Running AI review as a GitHub Actions job suits a team that:
- Already runs its pull requests through GitHub Actions and wants review to be one more job in that workflow.
- Already pays an inference provider, or wants to choose the model and change it on its own schedule.
- Has review knowledge worth encoding: security scripts, API conventions, test helpers and architecture rules.
- Wants review logic versioned in Git and changed through the same pull requests as the code it reads.
A fully hosted review service suits a team that prefers the vendor to own the model, the reviewer and its release schedule, under one subscription.
## Getting access
Review Runners are in early access. Tell us which repositories you want reviewed and which model you run, and we will set your org up.
- [Get early access](https://starsling.dev/products/review-runners)
## Paste this into your agent
This prompt designs AI code review for your own repository: what your existing checks already cover, which reviewers your team's conventions imply, which model to call, and what every finding should carry.
Design AI code review for this repository. First, inspect .github/workflows/*.yml and .github/workflows/*.yaml and list what already checks a pull request: tests, linters, static analysis and security scanners, and what each one covers. Then find the review knowledge the team has written down that no tool enforces yet: API conventions, architecture boundaries, migration rules, test helpers, security scripts, and any review checklist in CONTRIBUTING or docs. Propose reviewers with distinct responsibilities, for example security, API, tests, database and architecture, and for each one list the instructions, skills and scripts it should load and the paths it should read. Recommend a model for the review, explain the cost and quality tradeoff behind the choice, and say where the provider key would come from. Specify what every finding must carry: an exact path:line reference, a severity, an explanation and a concrete fix. Keep every existing job and required check as it is, and do not give any job write access it has no use for. Open one small pull request that adds the reviewer instructions, and say in the description what each reviewer is responsible for.
## FAQ
### What is AI code review?
AI code review is a language model reading a pull request and leaving review comments on it before a human opens it. It reads the diff and the code around it for intent and team conventions: whether the change does what it says, whether the new code path is tested, and whether it respects the boundaries the codebase keeps.
### How does AI code review work on GitHub?
On GitHub, AI code review runs as a GitHub Actions job started by the same pull request events as your tests. The job gives the model the diff and the code around it, and posts the findings on the pull request. With Review Runners, the job runs on `starsling-review` and calls your model through your own provider key.
### Which model should I use for AI code review?
Review is read-heavy work: the model reads a diff and the code around it and writes a short structured comment. A larger model brings deeper reasoning to subtle changes, a smaller one reviews more pull requests for the same spend, and open models are strong at this shape of task. Because the reviewer calls the model through your own key, the choice is yours and you can change it with a commit.
### Can AI code review use my own model and API key?
Yes. On Review Runners the reviewer calls your model through your own provider key, so the tokens are billed on the provider account you already hold, and StarSling bills for the runner minutes of the review job.
### What context does an AI code reviewer need?
The code around the change, plus what your team knows about reviewing it: written instructions, skills that package the context and scripts for one part of the codebase, the checks engineers already run by hand, and team conventions such as API rules and architecture boundaries. On Review Runners these are committed to the repository and load from the trusted base branch.
### What should an AI pull request review contain?
Findings you can act on: an exact `path:line` reference, a severity, an explanation of the problem and a concrete fix for each one, in one structured pass per commit.
### Can I split AI code review into several reviewers?
Yes. Define reviewers by responsibility, for example security, API, tests, database and architecture, and give each its own responsibilities, skills and instructions, so each one reads the pull request for the part of the codebase it owns.
### How does AI code review work alongside human review?
It runs first. The reviewers finish before a person opens the pull request, so the human reviewer starts from findings with exact line references and a concrete fix for each, and spends their time on whether the change should ship.
## Related resources
- [Review Runners](https://starsling.dev/products/review-runners)
- [How to run automated code review in GitHub Actions](https://starsling.dev/automated-code-review)
- [StarSling runners](https://starsling.dev/products/runners)
- [GitHub Actions CI best practices](https://starsling.dev/best-practices/github-actions)
- [Pin action SHAs](https://starsling.dev/best-practices/github-actions/pin-action-shas)
- [Fast GitHub Actions](https://starsling.dev/fast-github-actions)
- [Install the /ci-secure skill to close critical attack vectors in GitHub Actions](https://starsling.dev/skills/ci-secure)
- [Install the free /ci-score skill to improve your GitHub Actions setup](https://starsling.dev/skills/ci-score)
## Get started
- [Run your own AI reviewers in GitHub Actions](https://starsling.dev/products/review-runners)
- [See the GitHub Actions setup](https://starsling.dev/automated-code-review#github-actions-setup)
- [Install the free /ci-speedup skill to fix slow GitHub Actions](https://starsling.dev/skills/ci-speedup). Install with `npx skills add starslingdev/skills`.