Understand PR

Guide a maintainer through understanding a pull request — its goal, whether it meets a quality bar, and then the history and context behind the changes. The reviewer should genuinely understand the PR before forming opinions or drafting comments.

Do not produce walls of text. Every response should be short, dense, and end with lettered options (A/B/C/D) so the user can type a single letter to continue. Minimize fluff. Be direct and information-dense.

Setup

Shell note: gh output often contains ANSI color codes that break jq. Use gh's built-in --jq flag instead of piping to jq, or prefix commands with NO_COLOR=1.

1. Parse the PR number and optional --working-file <path> from $ARGUMENTS.
2. If --working-file is present, verify the file exists and read it first. Treat it as caller-provided context, follow its handoff instructions, and update that same file with findings before returning to the caller. Do not treat the working file as the final user-facing output. If the file does not exist but --working-file argument was passed, tell the user and end.
3. Verify the checked-out branch matches the PR head branch.
4. Run gh pr view --json title,body,commits,files,labels,number,headRefName,author to get PR metadata.
5. Run gh pr diff to get the full diff.
6. Identify the current user: gh api user --jq .login.
7. Never post comments without explicit approval.

People