Setting Up Claude Code in Your CI Pipeline in 15 Minutes

Claude Code doesn't need someone at the keyboard. In print mode it runs a single prompt, writes the result and exits, which makes it easy to add to a CI pipeline. The important part is giving it a narrow job and limited permissions.

Minutes 0-5: Choose one read-only job

Good first jobs:

• Summarize what a pull request changes and point out risky areas.
• Explain why a test run failed.
• Check a diff against your team's conventions.

Leave automatic fixes and pushes for later, once you've seen how reliable the output is on your codebase.

Minutes 5-10: Add the workflow

A minimal GitHub Actions job:

name: claude-pr-summary
on: pull_request
jobs:
  summarize:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - run: npm install -g @anthropic-ai/claude-code
      - name: Summarize the diff
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          claude -p "Summarize the changes between origin/main and HEAD. List risky areas and missing tests." \
            --allowedTools "Read,Grep,Glob,Bash(git diff:*),Bash(git log:*)" > summary.md

Store the API key as a repository secret, never in the workflow file. If you'd rather have Claude comment directly on pull requests, Anthropic publishes an official GitHub Action, and running /install-github-app in Claude Code walks you through the setup.

Minutes 10-15: Set limits

• Allow only the tools the job needs. The list above lets Claude read files and run git diff and git log. Nothing else is permitted.
• Cap the number of turns with --max-turns, so a run that goes wrong stops quickly.
• Write your conventions in CLAUDE.md at the repository root. Claude Code reads it automatically.
• Keep deploy credentials away from the job that runs Claude.

Common problems

• The checkout action fetches shallow history by default. Set fetch-depth: 0 when the prompt compares branches.
• Pull requests from forks don't receive repository secrets. Leave that protection in place.
• If another step needs to parse the output, use --output-format json.

Deciding whether to keep it

Run the job for a few weeks and ask reviewers whether they read the summaries and whether they found anything useful. If they do, add a second job, such as explaining failed builds. If nobody reads them, turn it off. You've spent very little finding out.