Pull Request Descriptions
2 exercises — write reviewer-friendly PR descriptions covering what changed, why, how to test, and related issues.
0 / 2 completed
PR description template
- What changed: Summary of the implementation — not a file list
- Why: Business reason, ticket reference, or ADR link
- How to test: Numbered steps with exact inputs and expected outcomes
- Related: Closes #issue, refs ADR, links to design doc
- Avoid: "Works on my machine" · listing changed files · vague summaries
1 / 2
A developer opens a pull request for a new two-factor authentication feature. Which PR description is most useful for reviewers?
Option B is the professional standard. It answers the four key reviewer questions: What changed (TOTP via speakeasy), Why (SOC 2, security reason with ADR reference), How to test (step-by-step manual test), and Related issues. Option A is too brief — reviewers don't know scope or impact. Option C lists files (irrelevant — reviewers see the diff) and lacks motivation. Option D contains the anti-pattern "works on my machine" and assigns instead of describing.