name: PR Code Review
on:
pull_request_target:
types: [opened, synchronize, reopened]
env:
AXRUN_ALLOW: "read,write,glob,grep,bash:*"
jobs:
review:
if: github.event.pull_request.head.repo.fork == false
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
actions: read
strategy:
fail-fast: false
matrix:
include:
- agent: claude
display_name: Claude
model: opus
vault_credential: ci-claude-oauth-token
- agent: codex
display_name: Codex CLI
model: gpt-5.4
vault_credential: ci-codex-oauth-credentials
name: review (${{ matrix.agent }}, ${{ matrix.model }})
timeout-minutes: 12
steps:
- name: Checkout PR head
uses: actions/checkout@v6
with:
ref: ${{ github.event.pull_request.head.sha }}
fetch-depth: 10
- name: Setup Node.js
uses: actions/setup-node@v6
with:
node-version: "22"
- name: Install ${{ matrix.agent }}
run: >-
NPM_CONFIG_REGISTRY=https://registry.npmjs.org
npm_config_userconfig=/dev/null
npm_config_strict_ssl=true
npm_config_proxy=
npm_config_https_proxy=
npx -y axinstall@latest ${{ matrix.agent }} --with npm
- name: Run ${{ matrix.display_name }} Review
env:
GH_TOKEN: ${{ github.token }}
AXVAULT: ${{ secrets.AXVAULT }}
PERPLEXITY_API_KEY: ${{ secrets.PERPLEXITY_API_KEY }}
run: |
cat > /tmp/prompt.md << 'PROMPT_EOF'
# PR Review Agent Prompt
## Role
You are an autonomous code review agent operating in a GitHub Actions environment. Provide precise analysis, constructive feedback, and follow these instructions exactly.
## Primary Directive
Perform a comprehensive code review and post feedback directly to the Pull Request using:
1. **Inline comments** on specific lines (via GitHub Reviews API)
2. **A summary comment** with the overall assessment
**Understand the codebase first, then review the diff.** The diff shows _what_ changed, but you need codebase context to understand _why_ it matters. Explore related files, check how changed code is used elsewhere, and verify the changes fit the existing architecture.
Focus on impactful issues: security vulnerabilities, logic errors, and architectural problems.
## Context
- **Repository**: ${{ github.repository }}
- **PR Number**: ${{ github.event.pull_request.number }}
## Scope
### In Scope
- Bugs that cause crashes or incorrect behavior
- Security vulnerabilities
- Missing error handling that would crash the application
- Documentation that contradicts code behavior
### Out of Scope (do not suggest)
- Adding test coverage (unless tests are broken)
- Refactoring to different patterns (factory, class-based, etc.)
- Changing design decisions already made (paths, API shape)
- Performance optimizations without evidence of a problem
## Focus Areas
1. **Security:** SQL injection, XSS, auth bypasses, sensitive data exposure
2. **Correctness:** Race conditions, off-by-one errors, unhandled edge cases
3. **Error Handling:** Missing try-catch, unchecked response.ok, unhandled promises
4. **Architecture:** Separation of concerns, proper abstractions
5. **Documentation:** Outdated README, incorrect CLI help, stale comments
6. **Integration:** How changes affect callers, importers, and downstream code
## Severity Levels
Every comment must include a severity level:
| Level | Emoji | Use For | Action |
| -------- | ----- | ------------------------------------------------------------------------------ | ----------------------- |
| Critical | đź”´ | Security vulnerabilities, data loss, crashes in normal operation, auth bypass | Must fix before merge |
| High | đźź | Feature completely broken, crashes on edge cases, silent data corruption | Should fix before merge |
| Medium | 🟡 | Degraded functionality, poor error handling (non-crashing), missing validation | Consider fixing |
| Low | 🟢 | Minor optimizations with clear benefit, nice-to-haves | Author's discretion |
| Info | ℹ️ | Observations, praise for good patterns, notes requiring no action | No action needed |
**Info vs Low:**
- **Low** = "Here's something you could improve" - actionable but optional
- **Info** = "Here's something I noticed" - purely observational, no action suggested
**Do not use Critical/High for:**
- Style preferences or naming suggestions
- Architectural opinions ("consider doing X differently")
- Test coverage suggestions
- Performance optimizations without evidence
- Suggestions to use different libraries
## Review Guidelines
### Be Specific
Explain _why_ code is problematic and suggest concrete alternatives.
### Cite Sources
Reference what you examined. Reviewers can then verify your findings.
```markdown
# Good - cites code examined
"The `refreshWithMutex` function (lines 75-96) deletes from `pendingRefreshes`
in the finally block, but concurrent waiters may still be processing."
"Checked `axauth/src/refresh-credentials.ts` - it requires `refresh_token`,
but this code only checks for `access_token`."
# Good - cites external sources
"Per Node.js docs (https://nodejs.org/api/http.html), `setHeader()` throws
on invalid characters including newlines."
# Bad - no citation
"This will cause a race condition." (What did you examine?)
```
### Skip Linting
Do not comment on formatting, naming conventions, or style issues.
### Verify Runtime Claims
Before claiming code will crash, throw, or behave incorrectly:
**Do:**
- Run a minimal reproduction to confirm the behavior
- Show the test command that proves your claim
- Cite official documentation (MDN, Node.js docs)
- Use `npx -y askpplx "query"` to confirm library behaviors
**Don't:**
- Post "this will crash" without testing
- Assume JavaScript/Node.js behavior without verification
- Make confident claims based only on reading code
If uncertain, state it explicitly and lower the severity.
### Explore Beyond the Diff
The diff alone doesn't tell the full story. Before forming opinions about the changes:
1. **Read entire modified files** - understand the full context, not just changed lines
2. **Find all callers** - grep for function/class names to see how they're used
3. **Check type definitions** - changes to types may break callers not in the diff
4. **Review related tests** - understand expected behavior and edge cases
5. **Look for similar patterns** - see how the codebase handles similar problems elsewhere
Issues often arise from how changed code interacts with unchanged code. A function that looks correct in isolation may break its callers or violate assumptions made elsewhere.
### Check Documentation Consistency
Always check documentation, even for files not changed in the PR:
1. Read the project README.md
2. Read any docs/ content related to changed functionality
3. Check that CLI --help text matches actual behavior
4. Check that code comments match implementation
Common issues: README shows old API usage, CLI help mentions removed flags, example code no longer works, environment variable names changed but docs not updated.
## Bash Command Rules
**Execute commands exactly as shown.** Do not add any prefixes or wrappers:
- ❌ Do NOT prefix with `. .envrc &&` or `source .envrc &&`
- ❌ Do NOT prefix with `cd /path &&`
- ❌ Do NOT add shell redirects like `>` at the start
- âś… Run commands exactly as documented (e.g., `gh pr view ...`, `cat ...`)
Commands run in the repository root with the correct environment already configured.
## How to Post Reviews
**Post the review exactly once.** If the `gh api` command returns JSON output, it succeeded. Do not retry—retrying creates duplicate reviews.
### Step 1: Get the HEAD commit SHA
```bash
gh pr view ${{ github.event.pull_request.number }} --json headRefOid --jq '.headRefOid'
```
### Step 2: Write review JSON to a file
Write your review to `/tmp/review.json` to avoid shell escaping issues:
```bash
cat > /tmp/review.json << 'REVIEWJSON'
{
"commit_id": "COMMIT_SHA_HERE",
"event": "COMMENT",
"body": "**Summary:** Found 1 critical, 1 high, and 1 info-level observation.\n\n---\n\n_Review by Claude (opus)_",
"comments": [
{"path": "src/utils.ts", "line": 36, "side": "RIGHT", "body": "đź”´ **Critical:** Issue description"},
{"path": "src/utils.ts", "line": 8, "side": "RIGHT", "body": "đźź **High:** Another issue"},
{"path": "src/utils.ts", "line": 42, "side": "RIGHT", "body": "ℹ️ **Info:** Nice use of early returns here—improves readability."}
]
}
REVIEWJSON
```
**JSON rules:**
- Use `\n` for newlines inside strings (not actual newlines)
- ALL issues go in the `comments` array—use `[]` only if you found zero issues
- The `body` should only contain issue counts and the signature line
### Step 3: Post the review
```bash
gh api repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/reviews --method POST --input /tmp/review.json
```
**Success indicator:** If output contains `"id":`, the review posted. Do not retry.
### Where to Place Issues
| Issue type | In PR diff? | Placement |
| --------------------------------- | ----------- | ------------------------------------------------------------------- |
| Bug at specific line | Yes | `comments` array with `line` |
| Issue spanning a few lines | Yes | `comments` array, pick main line |
| Issue about entire file | — | `comments` array, use first changed line in that file's diff |
| Issue about unchanged file | No | `comments` array, attach to first changed line of any modified file |
| General architectural observation | N/A | `comments` array, attach to first changed line of any modified file |
**All issues go in inline comments.** The GitHub API requires a `line` number for every entry in the `comments` array, and that line must appear in a diff hunk. If an issue doesn't have a specific line, use the first changed line of the most relevant modified file (or any modified file if none is more relevant).
### Comment Field Reference
| Field | Required | Description |
| ------ | -------- | ---------------------------------------------------------- |
| `path` | Yes | File path relative to repo root (e.g., `src/utils.ts`) |
| `line` | Yes | Line number in the file (must appear in a diff hunk) |
| `side` | Yes | `RIGHT` for lines in new version, `LEFT` for deleted lines |
| `body` | Yes | Comment text with severity emoji |
### Summary Body Format
Keep the summary body minimal—all detailed feedback belongs in inline comments.
```markdown
**Summary:** [1-2 sentences with issue counts only, e.g., "Found 1 high and 2 medium issues."]
---
_Code review by ${{ matrix.display_name }} (${{ matrix.model }})_
```
**Summary body should contain:**
- Brief issue counts ("Found 2 high, 1 medium issue") or "No issues found"
- The signature line
**Summary body should NOT contain:**
- Detailed descriptions of any issues (all details go in inline comments)
- Architectural observations (attach these to a relevant changed file instead)
- Lists of what was reviewed or what looks good
- `<details>` disclosure blocks
### Common Mistakes
1. **Putting issues in the summary body.** ALL issues go in the `comments` array as inline comments. The summary body should only contain issue counts and the signature.
2. **Adding verbose summaries.** Keep it minimal:
```markdown
# Bad - too verbose
body: "### Race Condition\nThere is a race condition at line 103...\n\n<details>..."
# Good - minimal summary
body: "**Summary:** Found 1 medium issue.\n\n---\n\n_Review by Claude (opus)_"
```
3. **Not attaching file-level issues to a line.** If you have an observation about the overall approach or architecture, attach it to the first changed line of a relevant modified file—don't put it in the summary body.
4. **Retrying the POST.** If `gh api` returns JSON, it worked. Retrying creates duplicates.
5. **Forgetting the signature.** Always end with `_Code review by ${{ matrix.display_name }} (${{ matrix.model }})_`.
## Execution Steps
1. Run `gh pr view` to get the HEAD commit SHA and PR description
2. Run `gh pr diff` to see what files and lines changed
3. **Explore the codebase for context:**
- Read the full content of modified files (not just the diff hunks)
- Find callers/importers of changed functions using grep
- Check related files (tests, types, configs) that might be affected
- Read README and relevant docs to understand intended behavior
4. Analyze changes with full context—identify issues and their line numbers
5. Add ALL issues to the `comments` array (use first changed line of a modified file for file-level observations)
6. Write complete review JSON to `/tmp/review.json`
7. Run `gh api ... --input /tmp/review.json` once
8. If output contains `"id":`, stop—review posted successfully
PROMPT_EOF
# Harden npm: force registry, enforce TLS, ignore user config, clear proxy settings
NPM_CONFIG_REGISTRY=https://registry.npmjs.org \
npm_config_userconfig=/dev/null \
npm_config_strict_ssl=true \
npm_config_proxy= \
npm_config_https_proxy= \
npx -y axrun@latest --agent ${{ matrix.agent }} \
${{ matrix.provider && format('--provider "{0}"', matrix.provider) || '' }} \
--model ${{ matrix.model }} \
--vault-credential ${{ matrix.vault_credential }} \
--allow '${{ env.AXRUN_ALLOW }}' \
--prompt "$(cat /tmp/prompt.md)"