Optimise Code Reviews with GitHub and OpenCode
The Problem: Code Reviews Are a Hidden Tax on Engineering Velocity
The average PR sits open for 24 hours before a first review. On a busy team, that number climbs to 48. Multiply that across a 10-engineer squad opening 3 PRs each per week and you're looking at hundreds of blocked engineer-hours every month - hours spent context-switching back to stale branches, re-reading diffs you'd already forgotten, and writing the same "add error handling here" comment for the 40th time.
Reviewer fatigue is real. Reviewers learn to skim. Nits get missed. Bugs slip through not because engineers are careless, but because human attention is finite and review queues are not.
The standard fixes don't hold up. Adding more reviewers dilutes ownership. Mandatory review checklists create checkbox theatre. Async review culture just moves the bottleneck to a different timezone.
The actual problem is that code review is treated as a synchronous, human-only gate - when most of the first-pass work (catching style issues, spotting missing error handling, flagging obvious bugs, labelling issues) is mechanical enough to automate.
The Solution: Turn GitHub Comments into Executable Tasks with OpenCode
OpenCode runs inside your GitHub Actions runner. Mention /opencode or /oc in any issue or PR comment, and OpenCode executes the task in your repo's own infrastructure - no third-party access to your code, no new dashboard to learn, no context switch out of GitHub.
One install command wires everything up:
opencode github installIf you prefer manual control, add .github/workflows/opencode.yml directly:
name: opencode
on:
issue_comment:
types: [created]
pull_request_review_comment:
types: [created]
jobs:
opencode:
if: |
contains(github.event.comment.body, '/oc') ||
contains(github.event.comment.body, '/opencode')
runs-on: ubuntu-latest
permissions:
id-token: write
steps:
- name: Checkout repository
uses: actions/checkout@v6
with:
fetch-depth: 1
persist-credentials: false
- name: Run OpenCode
uses: anomalyco/opencode/github@latest
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
with:
model: anthropic/claude-sonnet-4-20250514Set ANTHROPIC_API_KEY in your repo under Settings → Secrets and variables → Actions. That's the only required secret for the core workflow.
Use Case 1: Automated PR Review on Open
Stop waiting for a human to fire the first shot on every PR. This workflow triggers the moment a PR is opened, updated, or marked ready for review - OpenCode posts a structured review before any human has touched it.
name: opencode-review
on:
pull_request:
types: [opened, synchronize, reopened, ready_for_review]
jobs:
review:
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
pull-requests: read
issues: read
steps:
- uses: actions/checkout@v6
with:
persist-credentials: false
- uses: anomalyco/opencode/github@latest
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
model: anthropic/claude-sonnet-4-20250514
use_github_token: true
prompt: |
Review this pull request:
- Check for code quality issues
- Look for potential bugs
- Suggest improvementsBy the time a human reviewer opens the PR, the obvious issues are already flagged. They're now validating a cleaner diff, not doing a cold first pass. Review time drops significantly - teams using automated first-pass review report cutting average review cycles from 3 rounds to 1.5.
Use Case 2: Inline Fixes from Line-Level Comments
This is the most precise interaction mode. In the PR's Files tab, click the + icon on any line and drop a /oc comment. OpenCode automatically receives the file path, line numbers, and surrounding diff context - no copy-pasting, no rephrasing.
/oc add error handling hereOpenCode reads the exact line you flagged, understands the surrounding code, and implements the fix. The result is a new commit on the branch, not a suggestion in a comment thread that someone has to action later.
This works because the pull_request_review_comment trigger passes full diff context to the runner. OpenCode isn't guessing at what "here" means - it has the precise file and line range.
Use Case 3: Issue-to-PR in One Comment
A bug is reported. You reproduce it. Instead of context-switching to your local environment, creating a branch, implementing a fix, pushing, and opening a PR yourself - you write one comment:
/opencode fix thisOpenCode reads the issue, creates a branch, implements the fix, and opens a PR with a description. The mechanical overhead of a bug fix workflow - which accounts for a surprising fraction of engineering time on small issues - disappears.
For higher-volume repos, add issue triage automation with an account-age filter to reduce noise from spam accounts:
name: Issue Triage
on:
issues:
types: [opened]
jobs:
triage:
runs-on: ubuntu-latest
permissions:
id-token: write
contents: write
pull-requests: write
issues: write
steps:
- name: Check account age
id: check
uses: actions/github-script@v7
with:
script: |
const user = await github.rest.users.getByUsername({
username: context.payload.issue.user.login
});
const created = new Date(user.data.created_at);
const days = (Date.now() - created) / (1000 * 60 * 60 * 24);
return days >= 30;
result-encoding: string
- uses: actions/checkout@v6
if: steps.check.outputs.result == 'true'
with:
persist-credentials: false
- uses: anomalyco/opencode/github@latest
if: steps.check.outputs.result == 'true'
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
with:
model: anthropic/claude-sonnet-4-20250514
prompt: |
Review this issue. If there's a clear fix or relevant docs:
- Provide documentation links
- Add error handling guidance for code examples
Otherwise, do not comment.The 30-day account age gate is a practical detail, not a throwaway. Open-source repos see a measurable percentage of new issues from accounts created that same day. Filtering them keeps the triage workflow from burning API quota on spam.
Bonus: Scheduled Codebase Audits
OpenCode also runs on schedule. This workflow fires every Monday at 9am UTC, scans for TODO comments, and opens tracking issues automatically - no human prompt required:
name: Scheduled OpenCode Task
on:
schedule:
- cron: "0 9 * * 1" # Every Monday at 9am UTC
jobs:
opencode:
runs-on: ubuntu-latest
permissions:
id-token: write
contents: write
pull-requests: write
issues: write
steps:
- uses: actions/checkout@v6
with:
persist-credentials: false
- uses: anomalyco/opencode/github@latest
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
with:
model: anthropic/claude-sonnet-4-20250514
prompt: |
Review the codebase for any TODO comments and create a summary.
If you find issues worth addressing, open an issue to track them.TODOs that live in codebases for months do so because surfacing them requires a human to go looking. A scheduled audit removes that dependency entirely.
The Benefit
Each use case above removes a discrete bottleneck. Stack them together and the effect compounds.
Automated PR review on open means humans are no longer the first reviewer - they're the final approver. Inline /oc comments mean "fix this" is a literal instruction, not a request that goes into someone's backlog. The issue-to-PR flow means small bugs get closed the same day they're reported, not triaged into a sprint two weeks out.
The underlying shift is architectural. OpenCode isn't a chatbot you switch to when you're stuck. It's a participant in your GitHub workflow - triggered by the same events your CI pipeline already responds to, running in your own runners, acting on your actual codebase. Every /oc comment is a force multiplier: one line of text that produces a branch, a fix, a review, or a tracked issue.
The teams that get the most out of this aren't the ones who use it occasionally for hard problems. They're the ones who make it the default first pass - so that by the time a human reviewer opens a PR, the mechanical work is already done.