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).