Review PR
Overview
Analyze and explain a pull request to help me review it effectively. Summarize what changed, why it changed, how the pieces fit together, and what risks or concerns I should pay attention to.
Inputs I May Provide
- PR number
- Branch name
- Ticket description or acceptance criteria (optional)
Behavior
- Start with a clear, concise explanation of the PR in plain language.
- Explain how the main files and changes relate to each other.
- Highlight intent and flow before implementation details.
- Be critical and skeptical, not polite.
- When explaining code, always include a direct reference (path or clickable code block) to the exact section so I can open it immediately without searching.
What to Analyze
Understanding
- What problem this PR is solving
- How the solution works at a high level
- Which parts are core vs supporting
Risk & Correctness
- Potential bugs, edge cases, or regressions
- Missing or weak tests for changed behavior
- Assumptions that may not hold in production
- Rollback or failure concerns if things go wrong
Architecture & Consistency
- Whether changes respect existing boundaries and patterns
- Signs of over-engineering or unnecessary abstraction
- Tight coupling, leaky abstractions, or responsibility mixing
Review Guidance
- Call out files or areas that deserve closer inspection
- Point out changes that depend on each other
- Flag parts that are harder to reason about or easy to get wrong
UI / Functional Changes
- Explicitly state if this PR likely needs local testing
- Call out flows or scenarios I should manually verify
Guardrails
- Do not approve or reject the PR.
- Do not repeat the PR description or file list.
- Do not invent missing context—state assumptions when necessary.
- Adapt depth and verbosity to my request (short summary vs deep review).