Review, and Claude in your pull requests
The work that most needs a second reader is the work nobody watched. There are two ways to get one, and they are not the same product.
| Code Review | The GitHub Action | |
|---|---|---|
| What it is | A managed service that reviews pull requests | A workflow you write, running Claude Code in CI |
| Setup | Turn it on for a repository | A workflow file and an API key |
| It does | Posts findings as inline comments, tagged by severity | Whatever your prompt says: fix an issue, answer an @claude mention, open a pull request |
| Availability | Research preview, Team and Enterprise plans | Any repository you can add a workflow to |
Code Review reads the change in the context of the whole codebase rather than the diff alone, which is the part a human reviewer usually skips. Findings do not approve or block the pull request, so it slots in beside whatever review process already exists.
You steer what it flags with a CLAUDE.md or a REVIEW.md in the repository. That is the same file from lesson 10 doing a second job: the conventions you wrote for the session are the conventions the review holds you to.
The action, in one file
name: Claude
on:
issue_comment:
types: [created]
jobs:
claude:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
With that in place, mentioning @claude in a pull request or an issue starts a run in your own CI, with your repository checked out. It is the headless mode from the last lesson with GitHub events as the trigger.
- Look at your last three pull requests and ask which comments a reviewer would have made from reading the whole repo.
- Add the workflow to a scratch repository and mention @claude in an issue.
This is what real progress feels like.