wehub-resource-sync
49b9bb6724
3.7 KiB
Review the pull request: $ARGUMENTS
Follow these steps carefully. Use the gh CLI for all GitHub interactions.
Step 1: Resolve the PR
Parse $ARGUMENTS to determine the PR. It can be:
- A full URL like
https://github.com/owner/repo/pull/123 - A
owner/repo#123reference - A bare number like
123(use the current repo) - A description — search for it with
gh pr list --search "<description>" --limit 5and pick the best match
Once resolved, fetch the PR metadata:
gh pr view <PR> --json number,title,body,author,state,baseRefName,headRefName,url,labels,milestone,additions,deletions,changedFiles,createdAt,updatedAt,mergedAt,reviewDecision,reviews,assignees
Step 2: Gather the diff
Get the full diff of the PR:
gh pr diff <PR>
If the diff is very large (>3000 lines), focus on the most important files first and summarize the rest.
Step 3: Collect PR discussion context
Fetch all comments and review threads:
gh api repos/{owner}/{repo}/pulls/{number}/comments --paginate
gh api repos/{owner}/{repo}/issues/{number}/comments --paginate
gh api repos/{owner}/{repo}/pulls/{number}/reviews --paginate
Pay attention to:
- Reviewer feedback and requested changes
- Author responses and explanations
- Any unresolved conversations
- Approval or rejection status
Step 4: Find and read linked issues
Look for issue references in:
- The PR body (patterns like
#123,fixes #123,closes #123,resolves #123) - The PR branch name (patterns like
issue-123,fix/123) - Commit messages
For each linked issue, fetch its content:
gh issue view <number> --json title,body,comments,labels,state
Read through issue comments to understand the original problem, user reports, and any discussed solutions.
Step 5: Analyze and validate
With all context gathered, analyze the PR critically:
- Intent alignment: Does the code change actually solve the problem described in the PR and/or linked issues?
- Completeness: Are there aspects of the issue or requested feature that the PR doesn't address?
- Scope: Does the PR include changes unrelated to the stated goal? Are there unnecessary modifications?
- Correctness: Based on the diff, are there obvious bugs, edge cases, or logic errors?
- Testing: Does the PR include tests? Are they meaningful and do they cover the important cases?
- Breaking changes: Could this PR break existing functionality or APIs?
- Unresolved feedback: Are there reviewer comments that haven't been addressed?
Step 6: Produce the review summary
Present the summary in this format:
PR Review: <title> ()
Author: | Status: | Review decision:
Base: <base> ← <head> | Changed files: | + / -
Problem
<1-3 sentences describing what problem this PR is trying to solve, based on the PR description and linked issues>
Solution
<1-3 sentences describing the approach taken in the code>
Key changes
<Bulleted list of the most important changes, grouped by theme. Include file paths.>
Linked issues
<List of linked issues with their title, state, and a one-line summary of the discussion>
Discussion highlights
Concerns
<List any issues found during validation: bugs, missing tests, scope creep, unaddressed feedback, etc. If none, say "No concerns found.">
Verdict
<One of: APPROVE / REQUEST CHANGES / NEEDS DISCUSSION, with a brief justification>
Suggested action
<Clear recommendation for the reviewer: what to approve, what to push back on, what to ask about>