Why this matters
Smaller, focused PRs speed reviews and reduce defects.
If the PR is large (many files/lines), split it into logical chunks or provide a clear justification and review guide listing file groups and what to focus on.
Smaller, focused PRs speed reviews and reduce defects.
Side-by-side examples engineers can pattern-match during review.
132 files changed, no guidance.Big change rationale + review guide:
- mechanical renames (safe)
- core logic (focus)
- docs updatesHuge PR, no descriptionReview guide section with file clustersFrom the same buckets as this rule.
If the PR claims to fix a specific issue (e.g., 'Fixes #123' / 'Fix PAY-123'), validate it against the real production error. - If an observability MCP is available (Sentry/Datadog/Bugsnag): fetch the event/stack trace and confirm the change addresses the root cause. - Require a regression test (or a clearly documented reason why a test cannot be added). Call out fixes that only hide symptoms (catch-and-ignore, broader retries, defaulting values) without removing the underlying failure mode.