Pull request review
When a PR is opened, updated, or requested by comment, the GitHub Action checks out the code and runs the review flow.
Smithers Review
We built a GitHub-native review system that authenticates with OIDC, runs one agent per changed file, writes a story-form HTML review, and publishes an unlisted link for humans to inspect.
A CodeRabbit-style review bot for Smithers, but with a stronger artifact: a single HTML walkthrough that explains the change in reading order.
When a PR is opened, updated, or requested by comment, the GitHub Action checks out the code and runs the review flow.
Smithers splits the diff by file and gives each reviewable file to an agent. Findings are collected without failing the build.
A narrator turns the whole diff into chapters with embedded diffs, diagrams, summaries, and links back to the PR.
The reviewer is a pipeline. GitHub triggers it, Smithers orchestrates it, agents inspect the change, and the service publishes the result.
The system is split into a small GitHub Action, a local CLI runner, and a Cloudflare Worker service.
apps/review/action gates events, installs dependencies, checks out the PR, and launches the review CLI.
apps/review/src/workflow resolves the target, previews files, runs agents, and renders the HTML walkthrough.
apps/review/src/server mints sessions, proxies metered inference, stores walkthroughs, and exposes metrics.
apps/review/src/github turns findings into a PR review body and inline comments with suggestions.
bun apps/review/src/cli/main.tsEach lane owns one responsibility. This keeps credentials short-lived and keeps untrusted PR code away from long-lived secrets.
The user does not paste a platform secret into their repo. GitHub proves which repository is running, and the service returns a short-lived session.
No pull_request_target. The workflow runs on pull_request because the agents inspect PR code. Running with elevated target-repo credentials would be the wrong trust boundary.
pull_request opens -> GitHub Action asks GitHub for OIDC token -> review service verifies token signature and claims -> service checks repo registration and quota -> service returns a 2-hour session token -> CLI uses that token for inference and publishing
The artifact is intentionally plain: one static HTML file with prose, embedded diffs, diagrams, and every reviewed file in context.
Sample deployed walkthrough: https://review.jjhub.tech/w/wxkid6oa8vme
Users add one workflow. The service side decides whether the repo runs automatically or waits for the magic comment.
name: smithers review
on:
pull_request:
types: [opened, synchronize, reopened, ready_for_review]
issue_comment:
types: [created]
permissions:
id-token: write
contents: read
pull-requests: write
jobs:
review:
runs-on: ubuntu-latest
timeout-minutes: 30
steps:
- uses: smithersai/smithers/apps/review/action@main