---
title: "Automated Code Review in CI: Setup Guide"
description: "How to run automated code review as a GitHub Actions job using your own model, repo-native review skills and team-defined reviewers."
url: https://starsling.dev/automated-code-review
canonicalUrl: https://starsling.dev/automated-code-review
dateModified: 2026-09-25
---
# How to run automated code review in GitHub Actions
- [How StarSling works](https://starsling.dev/)
Automated code review can run as a job in the workflow you already have. The review reads the pull request, calls the model through your provider key, and loads its review logic from your repository, so the thing reading your code is a thing your team wrote and merged.
**Topics covered:** This guide covers what it means to run code review as a CI job, the workflow change that starts one, how to pick a model, and how to keep review logic versioned with the code it reads.
## Table of contents
- [Canonical answer](#canonical-answer)
- [What automated code review in CI means](#what-it-means)
- [The two architectures](#two-architectures)
- [Setting it up in GitHub Actions](#github-actions-setup)
- [Choosing a model](#choosing-a-model)
- [Versioning your review logic in the repo](#review-logic-in-git)
- [What it costs](#what-it-costs)
- [Getting access](#getting-access)
- [When StarSling may not be the right fit](#review-fit)
- [Paste this into your agent](#agent-prompt)
- [Key caveats](#key-caveats)
## Canonical answer
To run automated code review in GitHub Actions, add a review job to the workflow that already runs on your pull requests and point it at a runner built for review work. The job calls the model through your own provider key and loads skills, scripts, instructions and reviewer definitions from your repository's trusted base branch, so review logic is versioned in Git with the code it reads, and each reviewer leaves a structured comment on the pull request.
## What automated code review in CI means
Automated code review means a program reads a pull request and leaves review comments on it before a human opens it. Running it in CI means that program is a job in your own workflow file, started by the same events that start your tests.
On StarSling the review job runs on a StarSling runner, calls the model through your provider key, and loads its review logic from your repository's trusted base branch, so the reviewer that reads a pull request is the version your team merged.
Hosted review services can be configured from the repository too, with rules files, instructions and contextual configuration. The line this page draws is about ownership of the review system itself: the model, the skills and scripts the reviewers run, and the reviewer definitions are yours, committed with the code and versioned in Git.
- [Review Runners](https://starsling.dev/products/review-runners)
- [Runner labels and per-minute rates](https://docs.starsling.dev/configuration/label-reference#review-labels)
## The two architectures
Both shapes leave review comments on a pull request. They differ in who owns each part of the system that writes them.
| What you are choosing | A hosted review service | Review as a CI job |
| --- | --- | --- |
| Where the review runs | On the vendor's infrastructure, on the vendor's schedule. | As a GitHub Actions job on a StarSling runner, started by your own workflow. |
| Who picks the model | The vendor picks the model and the version it calls. | You pick the model and the provider, and the reviewer calls it through your key. |
| Where the review logic lives | In the product, shaped by its settings and the rules files it reads from your repository. | In your repository, beside the code it reads. |
| What the reviewer can run | The analysis the product ships, across the configuration surface it exposes. | Your skills, scripts and tools, as steps of the job. |
| How reviewers are defined | The reviewer the product provides, configured for the repository. | As many reviewers as you define, each with its own responsibilities, skills and instructions. |
| How an update ships | When the vendor releases it. | When you merge it, through the pull request that changes it. |
| How it is billed | A subscription to the vendor, usually per seat or per repository. | Runner minutes on your StarSling account, plus model tokens on your provider account. |
## Setting it up in GitHub Actions
A review is an ordinary job: it checks out the repository and runs a review action, and `runs-on` points at `starsling-review` so it lands on a Review Runner in the same account as the rest of your CI. The label runs any job; it is built for the ones that review code. Its rate is published in the [StarSling label reference](https://docs.starsling.dev/configuration/label-reference#review-labels).
### A job you already have
```yaml
jobs:
test:
runs-on: starsling-ubuntu-24.04
```
### The review job you add
```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 }}"
```
- `starsling-review` comes in a single size and takes no selector.
- Skills and instructions load from the trusted base branch, so a pull request cannot rewrite its own reviewer.
- Each reviewer leaves one structured comment: a verdict, findings by severity, exact `path:line` references and a concrete fix.
- A new push cancels a pass still running on the previous commit, so the next completed review covers the latest code.
- [Get early access](https://starsling.dev/products/review-runners)
## Choosing a model
The reviewer calls your model through your provider key, which makes the model a choice you make and a choice you can change by editing a file in your repository.
- Review is read-heavy work: the model reads a diff and the code around it, then writes a short structured comment against exact lines. Open models are strong at that shape of task, which is what makes them viable here.
- The key is yours, so the tokens are billed on the provider account you already hold, at the rate you already have.
- Different reviewers can call different models, so a security reviewer and a test reviewer are not forced onto one choice.
- Switching model is a diff. It goes through review and lands in a commit, so what the reviewer runs is always traceable to a merge.
## Versioning your review logic in the repo
The review system is code, and it lives in the repository it reads. Skills, scripts, instructions and reviewer definitions are committed with the product code and travel through the same pull requests, the same reviewers and the same history.
This is more than a rules file. A skill packages the context and the scripts your team already uses to review one part of the codebase, and a reviewer is a named role with its own responsibilities, its own skills and its own instructions.
- A security reviewer can run the security scripts your team already runs by hand.
- An API reviewer can hold your API conventions and read a diff against them.
- A test reviewer can read the suite a change touches and say what a new case would need to cover.
- An architecture reviewer can hold the boundaries the codebase is meant to keep.
Merge an update and the next review uses it. Skills and instructions load from the trusted base branch, so the review logic that reads a pull request is the version on the branch your team protects.
- [Review Runners](https://starsling.dev/products/review-runners)
- [GitHub Actions CI best practices](https://starsling.dev/best-practices/github-actions)
## What it costs
Two lines, on two accounts you already control.
| What you pay for | Where it is billed | How it is priced |
| --- | --- | --- |
| Runner minutes for the review job | Your StarSling account, beside 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, and concurrency is unlimited. |
| Model tokens for the review itself | Your own 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. |
## 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)
## When StarSling may not be the right fit
Review as a CI job suits a team that wants to own the review system. Other teams are better served elsewhere:
- You want a fully managed review bot and would rather have no CI configuration to keep.
- You would rather one vendor bill covered the model too, instead of holding your own provider account.
- Your pull requests run somewhere other than GitHub Actions.
- Generic review rules are all you are after, and your team has no skills or scripts it wants a reviewer to run.
## Paste this into your agent
This prompt runs the design against your own repository: where a review job belongs, which reviewers your team's existing scripts and conventions already imply, and the smallest workflow change that starts one.
Set up automated code review for this repository as a GitHub Actions job. First, inspect .github/workflows/*.yml and .github/workflows/*.yaml and report what already runs on a pull request, which workflow a review job belongs in, and which events trigger it. Then inventory the review knowledge this team already has committed: linter and security scripts, architecture or API conventions written down in the repo, test helpers, and any review checklist in CONTRIBUTING or docs. Group them into reviewers with distinct responsibilities, for example security, API surface, tests and architecture, and say for each one which scripts and instructions it would load and which paths it should read. Say which model you would call for each reviewer and why, and where the provider key would come from. Then write the smallest workflow change that adds a review job to the existing workflow, keeping every current job and check as it is. Do not weaken permissions, do not give the review job write access it has no use for, and keep every required check independent of the review job. Open one small pull request with the workflow change and the reviewer definitions, and say in the description what each reviewer is responsible for.
## Key caveats
- Reviews run as GitHub Actions jobs, so this is for teams whose pull requests already run on GitHub Actions.
- The reviewer calls your model through your own provider key, so the model tokens arrive on your provider's bill.
- Review Runners is in early access, and access starts from the Review Runners page.
## FAQ
### What is automated code review?
A program reads a pull request and leaves review comments on it before a human opens it. It can check the things a reviewer checks every time: security-sensitive changes, API conventions, test coverage for the code that moved, and whether a change respects the boundaries the codebase keeps.
### How do I set up automated code review in GitHub Actions?
Add a review job to the workflow that already runs on your pull requests, and point its `runs-on` at `starsling-review`. The job calls your model through your provider key and loads skills, scripts, instructions and reviewer definitions from your repository's trusted base branch.
### Can code review run in CI?
Yes. A review is a job like any other: it is started by the same pull request events as your tests, it runs on a runner, and its output is a structured comment on the pull request. Running it in CI is what lets the review logic live in the repository and ship through pull requests.
### Which model should an automated code reviewer use?
Whichever model you pick, because the reviewer calls it through your own provider key. Review is read-heavy work against a diff and the code around it, which open models handle well, and different reviewers can call different models.
### Where does the review logic live?
In your repository, versioned in Git with the code it reads. Skills, scripts, instructions and reviewer definitions are committed alongside the product code, and they load from the trusted base branch, so a pull request cannot rewrite the reviewer that is about to read it.
### What does automated code review cost on StarSling?
Two lines. Runner minutes for the review job on your StarSling account, where `starsling-review` is $0.004 a minute, billed from job start to finish and rounded up to the nearest minute, with queue time never billed and concurrency unlimited. Model tokens are billed by your own provider at your provider's rate.
### Can I define more than one reviewer?
Yes. Define as many as the codebase warrants, for example security, API surface, tests, database changes or frontend architecture, and give each its own responsibilities, skills and instructions. Each one leaves its own structured comment on the pull request.
### Does automated code review replace human review?
It changes what a human opens. The reviewers run before anyone looks, so the pull request a person reads already carries the findings a checklist would have produced, with exact `path:line` references and a concrete fix for each.
## Related resources
- [Review Runners](https://starsling.dev/products/review-runners)
- [StarSling runners](https://starsling.dev/products/runners)
- [GitHub Actions pricing](https://starsling.dev/github-actions-pricing)
- [Fast GitHub Actions](https://starsling.dev/fast-github-actions)
- [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)
- [StarSling vs GitHub Actions](https://starsling.dev/compare/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 code review where your CI already runs](https://starsling.dev/products/review-runners)
- [See StarSling runners](https://starsling.dev/products/runners)
- [Install the free /ci-speedup skill to fix slow GitHub Actions](https://starsling.dev/skills/ci-speedup). Install with `npx skills add starslingdev/skills`.