GitHub Pull Request Template

For a solo developer or a small team that wants a little structure and no friction.

## What and why

<!-- What does this PR change, and why? -->

Closes #

## How to test

1.

For a product team with code review. Covers the questions reviewers ask most.

## Summary

<!-- What does this PR change, and why? Two or three sentences. -->

## Related issue

Closes #

## Type of change

- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation
- [ ] Refactor or chore

## How to test

1.
2.

## Screenshots

<!-- Before and after, for UI changes. -->

## Checklist

- [ ] I reviewed my own code
- [ ] Tests cover the change
- [ ] Docs are updated where needed

For public repositories where first-time contributors open pull requests.

Thanks for contributing!

## Description

<!-- What does this PR do? Link the issue it fixes, for example "Fixes #42". -->

## Checklist

- [ ] I read CONTRIBUTING.md
- [ ] This PR targets the main branch
- [ ] I added or updated tests
- [ ] `npm test` passes locally
- [ ] I updated the documentation if behavior changed

## Notes for reviewers

<!-- Anything you are unsure about, or want a second opinion on. -->

For teams that publish release notes or a changelog. The author writes the customer-facing line while the change is fresh.

## Summary

<!-- What changed and why, for reviewers. -->

## Release note

<!-- One line for customers, in plain words. What can they do now, or what is fixed?
Write "none" if customers will not notice this change. -->

## Breaking changes

<!-- What stops working, who is affected, how to migrate. Delete if none. -->

## How to test

1.

Use it as one of several templates (see "Multiple templates" below) so bug fixes get the details they need.

## Bug

<!-- What went wrong, for whom, and since when. Link the issue. -->
Fixes #

## Cause

<!-- Why it happened. -->

## Fix

<!-- What this PR changes to fix it. -->

## How to verify

1.

## Regression test

- [ ] Added a test that fails without this fix

Where do I put a pull request template on GitHub?

Name the file pull_request_template.md and put it in the repository root, in a docs/ folder, or in the hidden .github/ folder. The .github/ folder is the usual choice because it keeps the root clean.

Can a repository have more than one pull request template?

Yes. Create a PULL_REQUEST_TEMPLATE/ folder inside .github/, the root or docs/, and put one Markdown file per template in it. To use one, add the template query parameter to the compare URL, for example ?quick_pull=1&template=bug_fix.md.

Why is my pull request template not showing up?

Templates only work once they are merged into the repository's default branch. Also check the file name (pull_request_template.md) and the folder. If you use a PULL_REQUEST_TEMPLATE/ folder, GitHub does not pick one automatically: you choose it with the template query parameter.

Can I set one pull request template for every repository?

Yes. GitHub lets you create default community health files, including a pull request template, for an organization or a personal account. Repositories that have their own template keep using it.

Why add a release note section?

The author knows best what a change means for customers, and writing one line takes a minute while the work is fresh. Later, whoever writes the changelog or release notes starts from those lines instead of reading every diff.