pr-review

name	pr-review
description	Use when a PR is created and needs code review before merging. Triggers after autonomous-dev creates PRs, or when user says "review PR

PR Review

Automated code review for pull requests. Runs after implementation is complete. Checks code quality, tests, standards compliance, and leaves review comments on the PR.

When to Use

• After autonomous-dev creates a PR
• User says "review PR #123" or "review this PR"
• User wants automated quality gate before merging
• After any PR is pushed and ready for review

The Pipeline

PR created
  |
  +- 1. FETCH ------- get PR diff, description, linked issue
  +- 2. CHECK ------- run automated checks (tests, lint, types)
  +- 3. REVIEW ------ analyze code changes for quality issues
  +- 4. COMMENT ----- post review comments on the PR
  +- 5. VERDICT ----- approve, request changes, or escalate

No permission gates. Runs fully autonomously.

Step-by-Step Recipe

Step 1: FETCH -- Get PR Context

# Get PR details
gh pr view <PR-NUMBER> --json title,body,additions,deletions,files,baseRefName,headRefName

# Get the full diff
gh pr diff <PR-NUMBER>

# Get linked issue (from "Closes ENG-XXX" in body)
linear issue view ENG-XXX --json --no-pager

Step 2: CHECK -- Run Automated Checks

Checkout the PR branch and run:

# Checkout PR
gh pr checkout <PR-NUMBER>

# Run all checks
pdm run pytest -n auto                    # tests pass?
pdm run pre-commit run --all-files        # lint/format clean?
pdm run mypy src/                         # types correct?
pdm run pytest --cov=src --cov-report=term-missing  # coverage?

Record results:

• Tests: pass/fail (which tests failed?)
• Lint: clean/issues
• Types: clean/errors
• Coverage: percentage (did it decrease?)

Step 3: REVIEW -- Analyze Code Quality

Review the diff for:

Check	What to look for
Standards	Follows CLAUDE.md rules (no enums, no magic numbers, ISO2 codes, Pydantic V2)
TDD	Tests exist for new code, tests written before implementation
Security	No hardcoded secrets, no SQL injection, no XSS
Config-driven	No hardcoded thresholds, uses catalogs/config files
Error handling	Uses centralized exceptions from src/core/exceptions.py
Logging	Uses structlog, no print statements
Complexity	No over-engineering, YAGNI, simple solutions
Naming	Clear variable/function names, consistent with codebase

Step 4: COMMENT -- Post Review on PR

# Leave a review with comments
gh pr review <PR-NUMBER> --comment --body "$(cat <<'EOF'
## Code Review

### Automated Checks
- Tests: PASS (142 passed, 0 failed)
- Lint: CLEAN
- Types: CLEAN
- Coverage: 94.2% (no decrease)

### Code Quality
- [issue or praise]
- [issue or praise]

### Verdict
[APPROVE / REQUEST CHANGES / reason]
EOF
)"

For inline comments on specific lines:

gh api repos/{owner}/{repo}/pulls/{pr}/reviews \
  --method POST \
  -f body="Review summary" \
  -f event="COMMENT" \
  -f comments[][path]="src/file.py" \
  -f comments[][position]=42 \
  -f comments[][body]="Suggestion: ..."

Step 5: VERDICT

Result	Action
All checks pass + no issues	gh pr review <PR> --approve --body "LGTM"
Minor issues	Comment with suggestions, don't block
Major issues	gh pr review <PR> --request-changes --body "..."
Stuck / unsure	Flag to user for manual review

Integration with autonomous-dev

After autonomous-dev creates PRs, pr-review runs automatically on each:

autonomous-dev creates PR #42 for ENG-332
  -> pr-review runs on PR #42
  -> approves or requests changes
  -> if changes requested, autonomous-dev can fix and re-push

Quick Reference

Task	Command
View PR	gh pr view 123
Get diff	gh pr diff 123
Checkout PR	gh pr checkout 123
Approve	gh pr review 123 --approve
Request changes	gh pr review 123 --request-changes --body "..."
Comment	gh pr review 123 --comment --body "..."
List open PRs	gh pr list

Common Mistakes

• Reviewing without running the actual test suite first
• Blocking on style nitpicks instead of real issues
• Not checking coverage delta (new code should maintain or increase coverage)
• Forgetting to check CLAUDE.md standards (config-driven, no enums, etc.)