pr-review-helper
Collect baseline information for PR review with minimal back-and-forth. Prefer GitHub MCP for all reads; if MCP lacks data or is unavailable, fall back to gh CLI.
Required Inputs
- Repository owner/name
- PR number
If any are missing, ask the user once. Do not guess.
Workflow (Prefer GitHub MCP)
-
PR overview
- Use
mcp__github__pull_request_readwithmethod: getto capture title, author, base/head branches, and head SHA.
- Use
-
All comments and review suggestions
- Review comment threads:
mcp__github__pull_request_readwithmethod: get_review_comments.- Extract: file path, line, author, body.
- If a suggestion block exists, capture the suggested patch and map it to the diff hunk.
- Review summary:
mcp__github__pull_request_readwithmethod: get_reviews.- Capture approvals, change requests, and top-level review bodies.
- PR/issue comments:
mcp__github__pull_request_readwithmethod: get_comments.- Include non-review discussion.
- Review comment threads:
-
Diff context
- Use
mcp__github__pull_request_readwithmethod: get_difffor full diff. - If the diff is large, also request
method: get_filesto scope by file before drilling into relevant hunks.
- Use
-
CI status
- Use
mcp__github__pull_request_readwithmethod: get_statusfor the head SHA. - Identify failing checks. If failures appear to be GitHub Actions, proceed to logs.
- Use
-
GitHub Actions logs (when failures exist)
- If MCP does not provide sufficient log details, fall back to
ghCLI. - Suggested flow:
gh pr checks <PR>to list failing runs and run IDs.gh run view <run-id> --log-failedto extract the failure reason.- If logs are truncated or need full context:
gh run download <run-id>then inspect the downloaded logs.
- If MCP does not provide sufficient log details, fall back to
TiDB-specific CI heuristics
Apply these rules when the repository is pingcap/tidb or a TiDB fork:
- If the diff does not touch parser-related files, treat parser test failures as likely flaky noise and do not block on them unless the logs show a direct causal link to the change.
- Treat
fast_test_tiprow,idc-jenkins-ci-tidb/unit-test, andpull-build-next-genas equivalent unit-test surfaces. Summarize them as one signal instead of three independent blockers. - If any one of those equivalent jobs is the blocker and the failure looks flaky or infra-related, recommend replying
/retestimmediately instead of waiting for the other two to finish or fail. - While CI is pending or rerunning, do not keep the user blocked on the same PR. Suggest switching to another ready issue, review, or coding task and come back when fresh CI signal arrives.
Fallback Workflow (gh CLI Only)
Use this when MCP is unavailable or incomplete.
-
PR overview
gh pr view <PR> --json title,author,baseRefName,headRefName,headRefOid
-
Comments and review threads
gh pr view <PR> --json comments,reviews,reviewThreads- Parse
reviewThreadsfor file/line and suggestion blocks.
-
Diff
gh pr diff <PR>
-
CI status and logs
gh pr checks <PR>gh run view <run-id> --log-failedgh run download <run-id>if full logs are needed
Output Expectations
Provide a concise summary with:
- Review comments grouped by file/line, including suggestion patches if present
- Non-review discussion comments that may affect changes
- CI status: pass/fail, failing jobs, and key error messages
- For TiDB PRs, separate likely ignorable flaky failures from actionable failures
- Clear action items for the PR author
Do not post new comments, re-run CI, or update the PR unless the user explicitly asks.