//
Search across all documentation pages
A pull request is the unit of work most teams already organize around: a branch, a diff, a review, and a merge.
Claude Code does not introduce a new workflow next to that one.
Instead it plugs into the pull request lifecycle you already run, at three specific points: opening a PR, reviewing a PR, and pushing follow-up commits that address review feedback.
Understanding exactly where those three touchpoints sit is what makes the rest of this section's articles make sense.
gh CLI, or a CI job.gh CLI, headless mode, automated review, follow-up commit.gh CLI, headless mode, automated CI review, GitHub Actions.A typical pull request goes through a small number of recognizable stages: a branch is created, changes are committed, a PR is opened against a base branch, reviewers leave comments, the author pushes follow-up commits, and eventually the PR merges.
Claude Code can sit inside three of those stages.
Opening a PR. After Claude Code makes changes in a working session, it can commit those changes and open a pull request directly, using the gh CLI's pr create command from inside the same session.
Reviewing a PR. Claude Code can also be run against an existing PR to leave review comments, either interactively at a developer's request or automatically as part of a CI job triggered whenever a PR opens or updates.
Responding to review comments. Once a human (or an automated review) leaves comments on a PR, Claude Code can read those comments, make the corresponding code changes, and push a follow-up commit to the same branch.
The simplest way to picture this: everywhere a person would normally type a git or gh command by hand, Claude Code can run that same command on their behalf, from inside a session it already has open.
The three touchpoints differ in who initiates them and where Claude Code runs.
Opening a PR and responding to review comments are both usually initiated by a person working with Claude Code interactively at a terminal. The developer asks Claude Code to commit and open a PR, or to go address the comments on a specific PR, and the session runs the necessary gh commands as part of answering that request.
Automated review is different: it is typically triggered by GitHub itself, through a GitHub Actions workflow that fires whenever a pull request is opened or updated. In that context there is no person watching the session in real time, so it runs in headless mode - Claude Code invoked non-interactively rather than through its normal terminal REPL.
# Interactive: a developer asks Claude Code to open a PR from the current session.
# Claude Code runs the underlying gh command itself as part of fulfilling the request.
gh pr create --title "Add rate limiting to the search endpoint" --body "Fixes #482"That same gh pr create command is exactly what a GitHub Actions job could run too - the difference is not the command, it's whether a human is present to type the request or whether the request came from a CI trigger and a scripted prompt instead.
This is the key mental shift: opening, reviewing, and responding to PRs are not three separate integrations. They are the same underlying capability - a Claude Code session that can run gh and git commands - invoked from two different contexts: an interactive terminal session, and a headless CI job.
Once a team has Claude Code opening PRs interactively, the natural next step is often automating the review side: a GitHub Actions job that runs Claude Code headlessly on every PR and leaves comments without anyone needing to ask for it.
That automated review does not replace a team's existing review process. It runs alongside required human reviewers and any branch protection rules already configured on the repository - it adds a signal, it does not remove a gate.
The three touchpoints also compose across a single PR's life. A session might open the PR, then hours or days later, once a human or the automated review leaves comments, a separate session (interactive or headless) picks the PR back up to push a follow-up commit addressing that feedback. Nothing requires the same session to handle every stage.
| Touchpoint | Typically Initiated By | Typical Mode |
|---|---|---|
| Opening a PR | A developer, mid-session | Interactive |
| Reviewing a PR | A CI trigger, or a developer request | Headless (CI) or interactive |
| Responding to comments | A developer, after reviewers weigh in | Interactive, sometimes headless |
A team adopting all three touchpoints ends up with Claude Code present at nearly every step of a PR's life except the actual merge decision, which stays a human call, enforced the same way it always was through GitHub's branch protection and required-approval settings.
gh CLI commands a developer would type by hand; there is no separate opening tool versus reviewing tool.It needs whatever the gh CLI itself needs - a repository the authenticated account can push to and open PRs against, same as if a person ran the commands by hand.
Claude Code can run the commands to open, review, or comment on a PR, but merging still goes through whatever approval and branch protection rules the repository already enforces.
The underlying capability is the same; the difference is only the trigger and the mode - a developer asking for a review runs interactively, while a CI job runs it headlessly whenever a PR event fires.
No. Opening a PR and responding to review comments both work fine from an interactive session using the gh CLI - GitHub Actions only becomes necessary once you want the review step to run automatically without a person present.
Through the gh CLI, GitHub's own official command-line tool, which Claude Code runs the same way a developer would run it by hand from a terminal.
That's a configuration concern, not an inherent property - a CI job can be scoped to leave a single consolidated comment per PR update rather than one comment per line, depending on how the review prompt and workflow are written.
The typical flow is to make the requested code change and push a follow-up commit; that's what actually addresses the feedback rather than just replying to it.
No - any model in the current lineup can run these gh and git commands; model choice affects the quality of the review or code changes, not whether the GitHub integration itself works.
Nothing changes about that rule - Claude Code's review comment or follow-up commit still needs the required human approval before the PR can merge, exactly as it would if a person had made those same changes.
Not in outcome - it's the same gh pr create command producing the same kind of pull request; the difference is only that Claude Code typed the command as part of finishing a task you asked for.
Yes - a developer might open the PR interactively, then a CI-triggered headless review runs automatically once it's pushed, and later the developer (or another session) pushes a follow-up commit addressing that review's comments.
gh CLI and walk through opening and reviewing your first PR.Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5. Model names, pricing, and product features move quickly - verify current specifics at platform.claude.com/docs before relying on them.