Use this on every non-trivial pull request. Let AI PR review burn down the mechanical items first; keep the judgment calls for humans.
Before you open the diff
- Intent is clear. Title + description say why, not just what. Linked issue or ticket if you use them.
- Scope fits one review. Prefer a stack of small PRs over a weekend mega-diff.
- CI is green (or failures are explained). Broken main is not “someone else’s problem.”
Correctness
- Happy path works for the stated change.
- Edge cases — empty input, retries, partial failure, timezone/locale if relevant.
- Error handling fails closed; users and logs get something actionable.
- Data migrations are reversible or explicitly one-way with a plan.
Security & privacy
- AuthZ — who can call this, and what can they see?
- Secrets stay out of the diff, logs, and client bundles.
- Injection / XSS / SSRF surfaces checked when touching user input or URLs.
- PII isn’t newly logged, exported, or cached without a reason.
Tests & operability
- Tests match the risk — unit where logic is dense; integration where contracts move.
- Observability — metrics/logs/traces updated if behavior changed.
- Rollout — feature flag, canary, or plain deploy; know how you’d undo it.
- Docs / runbooks if operators or support will feel this change.
Where AI should go first
On a tool like Mergestorm:
- Vortex — first-pass inline comments on every PR
- Cyclone — push a patch when the fix is obvious
- Tempest — deeper pass when the checklist screams risk (auth, money, migrations, big blasts)
Humans still own the approve button for product fit and “should we ship this at all?” Background: What is AI PR review? · What AI review should flag on a PR