---
name: pr-summary
description: Generate a pull-request summary from a diff or list of files. Produces a short title, a 2-3 bullet "what changed", and a test-plan checklist. Trigger keywords — summarize PR, write a PR description, draft pull request, describe this diff, what does this change do, generate pr summary.
when_to_use: When the user is preparing to open or update a pull request and asks for a summary, description, or release-note-style writeup of a diff. Especially useful when the diff spans multiple files and the author wants the framing extracted before they edit it.
vendor: qodo
version: 1.0.0
---

# PR summary

Generate a pull-request description that a reviewer can act on in under a minute.

## Output template

```markdown
## Title

<one short imperative line, ≤70 chars, no trailing punctuation>

## Summary

- <what changed, one bullet>
- <why it changed, one bullet>
- <any caller-facing impact, one bullet — skip if none>

## Test plan

- [ ] <how the change was verified locally>
- [ ] <regression scope the reviewer should re-check>
- [ ] <any manual steps for staging / production>
```

## Style rules

- **Title is imperative present**: "Add X", "Fix Y", "Remove Z". Not "Added", "Fixes".
- **Summary explains the why, not the what**. The diff already shows the what. The reviewer needs the motivation: bug context, design decision, ticket goal.
- **Test plan is the reviewer's checklist**, not a confession of what you did. Frame each item as something someone else could run.
- **No marketing language**. No "improved", "enhanced", "simplified" without specifics. Either cite a metric or describe the concrete change.
- **No co-author trailers** unless explicitly requested. The user controls attribution.

## When the diff is large

If you're summarising more than ~500 lines or 10+ files, group the summary by sub-system rather than flat-listing every change. Each subsection gets one bullet:

```markdown
### `src/auth/`
- <one bullet>

### `tests/`
- <one bullet>
```

## When the diff is trivial

A one-line summary is appropriate. Don't pad to fit the template — concise descriptions beat templated boilerplate. Output the title plus one bullet.

## See also

When the author also wants line-by-line review notes, suggest `qodo/code-review` instead. PR summary is the framing; code review is the gate.