1
# PR Description Template
2
3
```markdown
4
## Summary
5
6
<1-3 sentences: what changed and why. Link the issue/ticket if one exists.>
7
8
## Changes
9
10
- <bullet list of the concrete changes, grouped logically if the diff spans
11
  multiple areas>
12
13
## Why
14
15
<the motivation/context a reviewer needs that isn't obvious from the diff alone —
16
 e.g. "we chose X over Y because...">
17
18
## Testing
19
20
- [ ] <how this was verified — unit tests added/passing, manual steps taken,
21
      screenshots for UI changes>
22
23
## Breaking changes
24
25
<"None" if none, otherwise describe the break and the migration path>
26
27
## Screenshots (if UI-facing)
28
29
<before/after, or omit this section entirely if not applicable>
30
```
31
32
## Guidance
33
34
- **Summary** should stand alone — someone skimming a PR list should understand the
35
  change from the summary without opening the diff.
36
- **Changes** is a bullet list, not prose, so a reviewer can scan it.
37
- **Testing** should describe what was actually done (ran the suite, manually clicked
38
  through X, added a regression test) — "tested locally" alone isn't enough detail to
39
  be useful to a reviewer.
40
- Omit sections that don't apply (e.g. no screenshots section for a backend-only
41
  change) rather than leaving them as empty placeholders.
42
- Keep the PR title itself in the same `type(scope): summary` format as commits when
43
  the PR is a single logical change (most PRs); for PRs squash-merged from many small
44
  commits, the title becomes the eventual squash commit message, so hold it to the
45
  same bar.
46