GitHub PR Governance with Claude Code: Five Automation Patterns That Actually Work

GitHub PR Governance with Claude Code: Five Automation Patterns That Actually Work

TL;DR: Run Claude Code as an AI reviewer on every GitHub PR via Claude Code Action. This guide walks through 5 automation patterns (full review, critical paths, external contributors, OWASP security, custom checklists) with complete YAML and cost estimates.

Table of Contents

• Where PR Governance Usually Breaks Down
• What Claude Code Action Is
• Installation: Five Minutes to Running
• Pattern 1: Automatic Review on Every PR
• Pattern 2: Path-Specific Reviews for Critical Code
• Pattern 3: Stricter Reviews for External Contributors
• Pattern 4: Security Review Aligned with OWASP Top 10
• Pattern 5: Custom Team Review Checklist
• The Human-AI Boundary in Code Review
• API Cost Estimates
• FAQ
• Related Resources

Where PR Governance Usually Breaks Down

Most teams run into two consistent problems with code review.

The first is waiting. Senior engineers are busy. A PR sits in the queue for 24 to 48 hours before it gets reviewed. Delivery velocity is bottlenecked by review availability, not by writing speed.

The second is inconsistency. Different reviewers apply different standards. One person catches naming convention issues. Another focuses on security. A third is meticulous about test coverage. No individual reviewer covers every dimension on every PR — especially under time pressure.

The Stack Overflow 2025 Developer Survey found that 84% of developers already use AI tools daily, with 41% of new code AI-generated. But most teams have only deployed AI on the writing side, not on the review side. Connecting Claude Code to GitHub Actions means a PR can receive a structured, objective first-pass review within minutes of being opened — no queue, no variability.

This guide covers five ready-to-use patterns, each with a complete workflow YAML.

What Claude Code Action Is

claude-code-action is Anthropic's official GitHub Action for integrating Claude Code into PR and issue workflows.

Core capabilities:

• Automated code review: analyzes PR diffs and posts inline annotations on specific lines
• Interactive Q&A: @claude in a PR comment to ask questions about the code
• Code implementation: Claude can write fixes, refactoring, or new features directly
• Progress tracking: checkbox-based progress indicators that update in real time

The action runs entirely on your GitHub runner. API calls go to whatever endpoint you configure — Anthropic direct, Amazon Bedrock, Google Vertex AI, or a third-party gateway.

Installation: Five Minutes to Running

The fastest path is through the Claude Code terminal command:

# In your project root, open Claude Code and run:
/install-github-app

This walks you through GitHub App installation and Secrets setup.

Note: requires repository admin permissions. For gateway setups (e.g., CodeGateway instead of Anthropic direct), use manual configuration.

Manual setup for gateway users:

1. Go to Settings → Secrets and variables → Actions and add: - ANTHROPIC_API_KEY: your API key - (optional) ANTHROPIC_BASE_URL: https://api.codegateway.dev/v1
2. Create a workflow file under .github/workflows/
3. Required permissions for every review workflow:

   permissions:
     contents: read
     pull-requests: write
     id-token: write

Pattern 1: Automatic Review on Every PR

When to use: trigger a review on every PR opened or updated in the repository. Works well for trunk-based development or teams that want consistent standards applied across all contributions.

name: Claude Auto Review
on:
  pull_request:
    types: [opened, synchronize, ready_for_review]

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
      id-token: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 1

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          track_progress: true
          prompt: |
            REPO: ${{ github.repository }}
            PR NUMBER: ${{ github.event.pull_request.number }}

            Review this pull request with focus on:
            - Code quality and best practices
            - Potential bugs and edge cases
            - Security implications
            - Test coverage gaps

            Use inline comments for specific code issues.
            Use `gh pr comment` for an overall summary.

          claude_args: |
            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

track_progress: true creates a progress comment in the PR that updates with checkboxes as Claude works through the review. It's a small thing that makes the automation feel more visible and predictable to the team.

Trigger events: opened (new PR), synchronize (new commits pushed), ready_for_review (converted from draft).

Pattern 2: Path-Specific Reviews for Critical Code

When to use: skip full-repo review overhead and only trigger Claude when specific high-risk files change — authentication, payment logic, API definitions, security configuration.

name: Review Critical Paths
on:
  pull_request:
    types: [opened, synchronize]
    paths:
      - "src/auth/**"
      - "src/api/**"
      - "src/payment/**"
      - "config/security.yml"

jobs:
  critical-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
      id-token: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 1

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            REPO: ${{ github.repository }}
            PR NUMBER: ${{ github.event.pull_request.number }}

            This PR modifies critical authentication, API, or payment files.

            Focus your review on:
            - Authentication and authorization flows
            - Input validation and data sanitization
            - Potential injection vulnerabilities
            - API contract changes that may break consumers
            - Payment logic correctness and idempotency

          claude_args: |
            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*)"

The paths: filter keeps Claude focused on changes that matter most. Routine PRs that only touch tests or documentation don't trigger the review, which keeps signal-to-noise high.

Pattern 3: Stricter Reviews for External Contributors

When to use: open source projects or repositories that accept outside contributions. Apply a more thorough review pass for first-time contributors to maintain quality without requiring senior engineers to review every incoming PR manually.

name: External Contributor Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  external-review:
    if: github.event.pull_request.author_association == 'FIRST_TIME_CONTRIBUTOR'
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
      id-token: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 1

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            REPO: ${{ github.repository }}
            PR NUMBER: ${{ github.event.pull_request.number }}
            CONTRIBUTOR: ${{ github.event.pull_request.user.login }}

            This is a first-time contribution from @${{ github.event.pull_request.user.login }}.

            Provide a comprehensive review covering:
            - Code quality and adherence to project conventions
            - Tests: are new behaviors covered?
            - Public APIs documented?
            - Any breaking changes?
            - License and attribution (no copy-pasted code without attribution)

            Be constructive and welcoming. Explain the reasoning behind suggestions
            so the contributor learns from the feedback, not just what to change.

          claude_args: |
            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

The tone instruction in the prompt matters. Claude will follow it — external contributor reviews come out noticeably more explanatory than the default review style.

Pattern 4: Security Review Aligned with OWASP Top 10

When to use: security-sensitive projects, compliance requirements, or teams that want every PR to pass a structured security scan before merge.

name: Security-Focused Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  security-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
      id-token: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 1

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            REPO: ${{ github.repository }}
            PR NUMBER: ${{ github.event.pull_request.number }}

            Perform a security-focused review aligned with OWASP Top 10:

            1. Injection (SQL, NoSQL, command injection)
            2. Broken Authentication (session tokens, credential handling)
            3. Sensitive Data Exposure (PII unencrypted, secrets in source)
            4. Security Misconfiguration (default credentials, verbose errors)
            5. XSS (reflected, stored, DOM-based)
            6. Insecure Deserialization
            7. Known Vulnerable Dependencies (flag new imports)
            8. Insufficient Logging (missing audit trails for sensitive ops)

            Format each finding with severity:
            - [CRITICAL]: Block merge
            - [HIGH]: Fix before merge, strong recommendation
            - [MEDIUM]: Fix in a follow-up PR
            - [INFO]: Noted, no action required

          claude_args: |
            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*)"

Explicit severity labels make the output immediately actionable. Engineers know which findings block merge and which can wait, without having to make judgment calls about Claude's intent.

Pattern 5: Custom Team Review Checklist

When to use: teams with established conventions that should be verified on every PR — architecture rules, environment variable documentation, migration requirements, API schema consistency.

name: Team Review Checklist
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  checklist-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
      id-token: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 1

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            REPO: ${{ github.repository }}
            PR NUMBER: ${{ github.event.pull_request.number }}

            Review against our team checklist. Mark each item:
            ✅ Pass | ❌ Fail (with specific file and line) | ⚠️ Needs attention

            CHECKLIST:
            [ ] Functions under 50 lines; complex logic extracted
            [ ] No direct DB queries outside the repository layer
            [ ] New endpoints include rate limiting
            [ ] Error messages don't expose stack traces in production
            [ ] New environment variables documented in .env.example
            [ ] Database migrations include a reversible down migration
            [ ] API responses follow existing schema conventions
            [ ] No hardcoded secrets or API keys

            Post the full checklist as a PR comment with pass/fail for each item.
            Add inline comments on specific lines that fail.

          claude_args: |
            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

The structured output makes this pattern suitable for merge gating — you can parse the checklist comment programmatically to block merges on critical failures.

The Human-AI Boundary in Code Review

Adding Claude to the PR flow doesn't remove humans — it redirects human attention to what machines can't reliably do.

The core principle: Claude's review comments require human confirmation. It's the first reviewer, not the only reviewer.

API Cost Estimates

Using Sonnet 4.6 as the baseline (input $3/1M tokens, output $15/1M tokens):

At ten medium PRs per day, the monthly cost is roughly $24–$33. That's usually less than one hour of senior engineer time.

One note: very large PRs (over 2000 lines) are worth splitting before reviewing, whether human or AI. Large PRs are a review quality problem regardless of who's doing the reviewing.

FAQ

How accurate is Claude's review? How bad is the false positive rate?

There will be false positives early on, especially for business logic rules that Claude has no context for. The fix is precision in prompts — tell Claude your project conventions, which patterns are intentional exceptions, and what to ignore. Most teams see false positive rates converge to an acceptable level within two to three weeks of prompt iteration.

Can Claude automatically fix the issues it finds?

It can. Enable Bash(git commit:*) in claude_args and Claude can commit fixes directly to the PR branch. The safer pattern is having Claude identify the issue and suggest specific code, then let a human apply the fix. This keeps humans in the loop on what changes are going into the codebase.

Can I limit Claude to reviewing only certain file types?

Yes, using the paths: filter:

paths:
  - "**/*.py"
  - "**/*.ts"

Does this work with API gateways instead of Anthropic direct?

Yes. Add ANTHROPIC_BASE_URL as a Secret and pass it as an environment variable in the workflow:

env:
  ANTHROPIC_BASE_URL: ${{ secrets.ANTHROPIC_BASE_URL }}

claude-code-action uses this to override the default endpoint.

Will multiple commits to the same PR trigger multiple reviews?

Yes — synchronize fires on every push. To cancel in-progress reviews when new commits arrive:

concurrency:
  group: review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

Does this work in private repositories?

Yes. The action runs on your GitHub runner. API calls use your key. PR access uses the built-in GITHUB_TOKEN with scoped permissions.

Related Resources

• Claude Code Quick Setup Guide — Claude Code CLI access setup
• Claude Code Auto Mode Guide — How Auto Mode decides when to act
• Codex CLI vs Claude Code — Which AI coding tool fits your workflow
• Claude API Rate Limits Explained — Handling limits in high-volume CI/CD

Sources

• anthropics/claude-code-action GitHub repository (github.com/anthropics/claude-code-action)
• Stack Overflow Developer Survey 2025
• Anthropic Claude Code documentation (2026)

Anthropic's official playbook for context

Anthropic's blog *How Claude Code Works in Large Codebases* documents practices that complement the 5 patterns above:

• Path-scoped review skills (extends Pattern 2: critical-path coverage) — Anthropic recommends binding skills to specific subdirectories. Scope the OWASP security-review skill to auth/ and payments/ only — richer checks where stakes are high, skips noise elsewhere.
• Separate explorer and editor agents (extends Pattern 5: custom checklist) — Use a read-only subagent to map the subsystem touched by a PR first, then let the main agent review against that map. In Claude Code Action this is two steps: claude-code map → claude-code review --context map.md.
• Stop hooks for continuous improvement — At session end, run a stop hook that reflects on what surfaced during review and proposes updates to the repo's CLAUDE.md. Your review standard evolves with every PR instead of freezing at the initial config.

For more enterprise-grade lessons, see Anthropic's official post: How Claude Code Works in Large Codebases.