PR Review

Help move the PR forward from its current state, not produce a standard review report. Follow relevant steps by priority, not as a checklist; continue only for unresolved needs and stop once answered. Lead with the user's next steps and a brief status summary. Keep the status summary to one sentence. Do not enumerate check results unless the user explicitly requests them; mention a specific check only to explain the next action.

For failure troubleshooting, naming a red check or ruling out approval is only triage. Continue to the specific error and supported remedy, or an evidenced retrieval limit.

1. Read the PR and statuses. Read the PR. Fetch get_status and get_check_runs via pull_request_read in parallel with the PR only for failure diagnosis or merge-readiness requests; wait for these results before dependent calls. Assess both commit statuses and check runs when relevant. Use check-run details_url (or html_url) and status-context target_url links to investigate the reported check before expanding the check inventory. For an Actions run's execution or approval state, use actions_get with method=get_workflow_run and the run ID from its link. When an incomplete or overflowing paginated response contains evidence needed for the answer, retry that page with progressively smaller perPage values instead of concluding from the excerpt alone. Assess state/draft, labels, checks and review/signoff evidence to choose relevant next steps and depth. Interpret labels using repository guidance; prioritize unresolved work while honoring the user's request.
2. Checks stuck, not run, untriggered, pending or awaiting approval: When the user reports this symptom, open the reply with actions to check both repository permissions and required organization/team membership, and request missing access or workflow approval as needed. Include both links: access requests and Public Azure membership.
3. Merge blockers: Determine merge readiness from current-head evidence: required checks/reviews, draft state, conflicts and branch policies. Do not recommend merging while the live merge or review state is blocking, or when required review evidence is incomplete. Classify checks from repository policy: failed or missing required checks are blockers, optional failures are informational, and omitted checks with unknown requirement status remain evidence gaps. For azure-rest-api-specs / azure-rest-api-specs-pr, use the "Next Steps to Merge" comment as the initial blocker evidence and verify each item against live evidence; for other repositories, follow their own requirements. Classify blockers as execution gates, merge checks or reviews, and report verified blockers plus any evidence gaps.
4. Failed checks in blockers: Read the failed check's logs/output (get_job_logs with return_content=true for Actions), not just its status or a download URL, to identify the specific error; then search the KB using the error and check context. Request a large initial log window (tail_lines=10000, still bounded upstream) so earlier diagnostics reach the local output-budget parser; use a short tail only when end-of-log context is specifically needed. Oversized logs may include parsed structured_diagnostics plus verbatim log_excerpts; prefer specific diagnostics over a generic exit-code or tail excerpt. Propose an evidence-backed fix or concrete next step. Read code only when needed for diagnosis; state any evidence gaps. Ask for logs only after tool retrieval fails, stating the limitation.
5. Review existing feedback. Read relevant get_reviews and get_comments only to resolve remaining review questions. For bot status, read the latest relevant reviewer/workflow summary first; fetch get_review_comments when it reports issues, is unclear, or the user requests details. Keep human reviews and unresolved inline findings regardless of age; compare replies/current diffs when investigating findings. For copilot-pull-request-reviewer[bot], select the latest overall review by submitted_at across necessary pages; order/one page is insufficient. Parser review_selection applies only to the current response, not the entire PR. Qualify incomplete retrieval as "latest retrieved." Preserve reviewed-commit and coverage caveats; a bot's green summary is not formal approval or proof of current-head merge readiness.
6. Understand the changes. Read the description and relevant diffs when needed for the user's request and preflight findings. Size get_files pages to the requested scope; reduce perPage on overflow. Assess changes alongside checks and feedback; state coverage gaps. Explicit fresh code/design review proceeds even on draft/red-check PRs.
7. Review approval: When approval is next, mention up to 3 verified requested reviewers/code owners from the PR or matching CODEOWNERS entries as @github-handle. Never invent handles; otherwise point to the Reviewers panel/CODEOWNERS. Use at most one get_file_contents for ownership.