Pull Request Description Template

A pull request template sets a baseline quality standard for every code change in a repository. Rather than relying on each developer to remember what information reviewers need, the template prompts for it automatically. The result is PRs that reviewers can understand and evaluate without hunting the author down for context, which makes code review faster and more effective. This template has four sections that cover the essential information for code review. The Summary section asks for a brief description of what the PR does and why — not what files changed (reviewers can see that in the diff) but the intent behind the change. The Type of Change checkboxes help reviewers calibrate their review expectations: a breaking change warrants much more careful review than a documentation update. The Changes Made bulleted list gives reviewers a roadmap for navigating the diff in a logical order. The Test Plan checklist shows what testing was done and gives reviewers specific scenarios to verify. The reviewer checklist at the bottom is a self-review prompt: by requiring authors to check that code follows the style guide, that they've done a self-review, and that documentation is updated, the template catches issues that reviewers would otherwise have to flag. Some teams track checklist compliance and use it as a quality metric over time. PR descriptions and AI-assisted review: as AI code review tools become more common, well-structured PR descriptions give AI reviewers the context to make better suggestions. A summary of intent helps AI tools distinguish intentional design decisions from apparent bugs. The type-of-change checklist signals whether to apply breaking-change scrutiny. Why checklists work: the aviation industry pioneered checklists for complex, multi-step processes where human memory is unreliable. Software development has similar characteristics — there are many things to remember when preparing a PR, and under time pressure developers skip steps. A checklist externalizes the memory requirement and makes omissions visible. Template placement: save as .github/pull_request_template.md in the default branch. GitHub pre-fills this content into the PR description box for every new PR. You can also create multiple templates by placing files in .github/PULL_REQUEST_TEMPLATE/ and referencing them with ?template=filename.md in the PR URL. Customising for your team: add project-specific checklist items that match your team's definition of "done" — database migration checks, API compatibility review, performance benchmarks for critical paths, security review for authentication/authorization changes. The template should reflect the actual things your team cares about, not a generic list.

## Summary

Brief description of what this PR does and why.

## Type of Change

- [ ] Bug fix (non-breaking)
- [ ] New feature (non-breaking)
- [ ] Breaking change
- [ ] Documentation update
- [ ] Refactoring (no functional change)

## Changes Made

- List the key changes
- Include any architectural decisions

## Test Plan

- [ ] Unit tests added/updated
- [ ] Integration tests pass
- [ ] Manually tested in dev environment

## Checklist

- [ ] Code follows project style guide
- [ ] Self-review completed
- [ ] Documentation updated if needed
- [ ] No new warnings introduced