HighPR-scope

Document rollout, flags, and rollback

If the change is risky or user-facing, describe the feature flag, rollout plan (stages/segments), monitoring signals, and a clear rollback procedure.

Why this matters

Safe rollout reduces incident blast radius and MTTR.

Side-by-side examples engineers can pattern-match during review.

Avoid

Ship all at once, no rollback plan.

Prefer

Flag: checkout.lazy_widget
Rollout: 5% → 25% → 100%
Monitor: error rate, CLS
Rollback: disable flag; revert commit X if needed.

Bad

No flags, no plan

Good

Flag + staged rollout + rollback

From the same buckets as this rule.

High
Avoid mixed concerns in one PR
Do not combine mechanical changes (formatting, renames) with behavioral changes. If unavoidable, separate commits and call out which commits are mechanical.
pr-hygienereadability-refactor+1
High
Behavioral changes must add or update tests
If files under src/ change behavior, the PR must include tests/ updates or a PR description line no-tests: <reason> explaining why tests are unaffected.
testing-qualitypr-hygiene
High
Bugfix PRs must match the real production failure (root cause, not band-aid)
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.
pr-hygieneerror-handling+2