---
name: github-pull-request-review
description: Review a GitHub pull request for correctness, risk and test gaps. Use when the user asks to review, check or summarise a pull request, or wants to know what a change does before it merges.
---

# Review a GitHub pull request

Read first, then report. Use the GitHub MCP server's pull request, file and workflow tools. Do not comment, approve, request changes or merge unless the user asks for that action in this conversation.

## Steps

1. Get the repository and pull request number from the user's message or link. If either is missing, ask once.
2. Read the pull request with `pull_request_read` (method `get`) for the title, description, author, base and head branches and state.
3. Read the changed files and the diff with `pull_request_read` (methods `get_files` and `get_diff`). For a large diff, go file by file.
4. For each changed file that matters, read the code around the change with `get_file_contents` at the head ref. Judge the change in context, not from the hunk alone.
5. Before calling a changed function unsafe or breaking, find its callers with `search_code`.
6. Check CI with `pull_request_read` (method `get_status`) and `actions_list` for failed workflow runs on the head branch.

## What to report

- A verdict first, in one sentence: ready, ready with small fixes, or blocked.
- Findings by severity. For each: file path, line range, and why it matters.
- Changed behaviour with no test covering it.
- Open questions for the author.

Report only what the diff changes. Say plainly what you could not check, such as CI logs you could not read or files too large to review.

## Writing back

Drafting a review comment is fine. Posting it, approving the pull request or requesting changes needs the user's explicit yes in this conversation.