Reviewing a Pull Request
This playbook guides reviewers through conducting effective code reviews for SDK pull requests. It covers PR description validation, CI verification, code quality assessment, and feedback conventions using the LOGAF scale. By following these steps, reviews will focus on risk reduction, maintain consistent quality standards, and provide actionable feedback.
Related resources:
- Review and CI Standards — review requirements and feedback conventions
- Code Quality Standards — test requirements and quality criteria
- Sentry code review checklist — detailed review criteria
- Sentry Skills — code-review skill for automated checks
Does it explain what and why? Is there a linked issue? If either is missing, request it before reviewing code.
A reviewer SHOULD NOT begin a full review unless all of the following conditions are met:
- All CI checks, builds, and tests have completed successfully.
- All requested AI code review agents have completed their reviews.
- All comments from previous review cycles (AI or human) have been addressed, resolved, or explicitly marked as not applicable.
If any of the above conditions are unmet, the reviewer MAY leave comments to help the author unblock CI failures or address outstanding feedback.
Use the code review checklist. You MUST focus on:
- Runtime errors and potential crashes
- Performance concerns (N+1 queries, unbounded operations)
- Unintended side effects or behavior changes
- Backwards compatibility
- Security vulnerabilities
- Test coverage appropriate for the change type (Test requirements by change type)
- Test quality — do assertions verify real behavior? (Test quality)
You SHOULD use the sentry-skills:code-review skill to systematically check for issues.
(Required reviewers): public API changes, new dependencies, schema changes, security-sensitive code, new frameworks. If any apply and no @sdk-seniors reviewer is assigned, flag it.
You MUST use LOGAF prefixes on all feedback (Review feedback conventions):
h:(high) — must fix before merge. Bugs, security issues, breakage, data loss.m:(medium) — should fix. Design concerns, missing tests, unclear code.l:(low) — optional nit. Style preferences, minor suggestions.
You MUST NOT block for style preferences. The goal is risk reduction, not perfection.
- Review feedback conventions — LOGAF scale and blocking criteria
- Required reviewers — @sdk-seniors review triggers
- Required CI checks baseline — minimum CI requirements
- Test requirements by change type — test coverage expectations
- Test quality — meaningful assertion requirements
- PR description quality — description content requirements
| Version | Date | Summary |
|---|---|---|
1.0.0 | 2026-02-21 | Initial playbook — standardized code review process with LOGAF feedback conventions |
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").