| name | engineering-change-descriptions |
| description | Use when writing, rewriting, or reviewing PR/CL descriptions, commit messages, or code-change summaries that explain what changed and why. TRIGGER on "write PR description", "improve this commit message", "summarize this diff", "CL description", "change description", or "make this PR/CL description easier to review". DO NOT TRIGGER for code review, PR splitting, code restructuring, user-facing changelogs, or reviewer replies unless the requested output is a change description.
|
Engineering Change Descriptions
A change description is permanent engineering history. It should let reviewers understand the change now and help future maintainers find and understand it later.
Adapted from Google Engineering Practices Documentation, especially "Writing good CL descriptions." Source: https://google.github.io/eng-practices/review/developer/cl-descriptions.html. License: CC-BY 3.0.
What a Good Description Answers
- What changed?
- Why did it change?
- What context, constraints, or tradeoffs are not obvious from the code?
- How was it tested?
- What risks, migrations, rollbacks, or follow-ups should reviewers know?
Even small changes deserve context when the reason is not obvious.
First Line
The first line should:
- Stand alone in version control history.
- Be short, specific, and focused on what the change does.
- Use an imperative form when writing a commit or CL title.
- Avoid vague labels like "fix bug", "cleanup", "phase 1", "misc", or "add helpers".
- Be followed by a blank line when there is a body.
Body
Include only useful context:
- Problem being solved.
- Why this approach was chosen.
- User-visible or developer-visible behavior changes.
- Important implementation notes.
- Known limitations or follow-up work.
- Bug IDs, issue links, benchmark results, design docs, migration docs, or rollout plans.
- Enough context for links that might later become inaccessible.
- Test commands and results, when appropriate.
Before submitting, reread the description after review changes and make sure it still matches the final diff.
Templates
Standard PR
[Imperative one-line summary]
## Why
[Problem, user need, production issue, maintainability reason, or design context.]
## What Changed
- ...
- ...
## Testing
- ...
## Risk / Rollback
- Risk:
- Rollback:
Small Change
[Imperative one-line summary]
[One paragraph explaining why this change exists and any non-obvious context.]
Testing: [command or manual check]
Refactor
[Describe the structural change and what it replaces]
This prepares for [future change] by [specific reason], without intentionally changing behavior.
Testing: [existing or new tests that protect behavior]
Generated or Mechanical Change
[Describe the mechanical rewrite]
Generated by [tool/version/command] to [reason]. Manual edits: [none/list].
Verification: [format/test/build command]
Rewrite Checklist
When improving an existing description:
- Extract the actual behavior from the diff.
- Replace vague first lines with a concrete action.
- Add the missing why.
- Preserve useful issue links and test evidence.
- Remove process noise that does not help reviewers or future maintainers.
Common Mistakes
- Describing only the implementation without the reason.
- Writing a title that future searchers cannot distinguish from similar changes.
- Depending entirely on external links for crucial context.
- Leaving the description stale after review significantly changes the diff.
- Hiding risk, limitations, or rollout requirements because they feel inconvenient.
