GitHub PR template generator
Pick the sections your team needs, preview the markdown, and copy a ready-to-commit PULL_REQUEST_TEMPLATE.md. Free, runs entirely in your browser.
.github/PULL_REQUEST_TEMPLATE.md (or docs/ or the repo root). GitHub pre-fills it on every new PR. For multiple templates, use .github/PULL_REQUEST_TEMPLATE/ with one file per template.## Summary <!-- One or two sentences: what does this PR do? --> ## Why <!-- What problem does this solve? Link the issue/ticket. --> Closes # ## What changed - - ## How it was tested <!-- Unit tests, manual steps, screenshots, load tests --> - [ ] Unit tests added/updated - [ ] Tested locally ## Checklist - [ ] PR is under ~400 changed lines (or split is justified) - [ ] Error paths handled, not just the happy path - [ ] No secrets, keys, or tokens in the diff - [ ] New/changed behavior covered by tests - [ ] Docs updated where behavior changed <!-- Template generated with https://diffwise.app/tools/pr-template-generator -->
Where does a pull request template go?
GitHub looks for PULL_REQUEST_TEMPLATE.md in three places: the .github/ directory (most common), the repository root, or docs/. The file's contents pre-fill the description box on every new pull request. For multiple templates (feature, bugfix, release), create a .github/PULL_REQUEST_TEMPLATE/ directory with one markdown file each, then select them via the template query parameter when opening a PR.
What should a PR template include?
The four questions a reviewer needs answered before opening the diff:
- What does this change do (summary)?
- Why does it exist (context, linked issue)?
- How was it verified (tests, manual steps, screenshots)?
- What could break (breaking changes, risk)?
Keep the template short. A template with twelve sections gets deleted or filled with "N/A" within a week. Five focused sections beat twelve ignored ones, and a short reviewer checklist (5-8 high-value items) outperforms a long one. If you want a deeper, stack-specific checklist, generate one with the code review checklist generator and link it from your contributing guide instead of inlining it.
Templates set expectations. Automation enforces them.
A template reminds authors to describe testing; it cannot check that error paths are handled or that the new endpoint validates input. That layer belongs to automation: Diffwise reviews every PR with 40+ specialist agents minutes after it opens and re-classifies findings as Fixed, Still Open, or New on each push, so the template covers intent while the agents cover the diff. See How to Automate Code Review on GitHub.
Frequently asked questions
Where do I put PULL_REQUEST_TEMPLATE.md?
In .github/, the repo root, or docs/. The .github/ directory is the convention most teams use. The template applies to all new pull requests automatically.
Can a repo have multiple PR templates?
Yes. Create .github/PULL_REQUEST_TEMPLATE/ with one markdown file per template (feature.md, bugfix.md), then open PRs with ?template=bugfix.md in the compare URL. GitHub has no template picker UI for PRs, unlike issues.
Should the template include a checklist?
A short one, 5-8 items max, focused on what authors forget: tests, breaking changes, secrets. Long checklists get checked without being read. Put the full review checklist in your contributing guide.
Do PR templates work for forks?
Yes. The template comes from the base repository (the one receiving the PR), so external contributors see it too.
Is this generator free?
Yes. Free, no signup, fully client-side.