Generate a pull request template
Pick the sections you want — summary, motivation, screenshots, testing, checklist — and drop the Markdown straight into .github/.
## Summary <!-- 1-2 sentences describing the change --> ## Motivation <!-- Why is this change needed? Link to design docs or discussions. --> ## Related issue Closes # ## Type of change - [ ] Bug fix - [ ] New feature - [ ] Breaking change - [ ] Documentation - [ ] Refactor / chore ## Screenshots <!-- Drop in before/after screenshots for UI changes --> ## How to test 1. 2. 3. ## Checklist - [ ] Tests added / updated - [ ] Docs updated - [ ] No new lint warnings - [ ] Reviewed my own diff
How to add a PR template
GitHub pre-fills the PR description with this file whenever someone opens a new PR.
- 01
Pick sections
Toggle the sections your team actually fills out.
Parsing runs through marked with GFM extensions enabled — tables, task lists, strikethrough, and fenced code blocks all match GitHub’s rendering.
pickGFMmarkedCommonMarklivesections · markdown7 · GFM## Summary
loaded · GFMGFM · ready - 02
Drop in repo
Save as .github/PULL_REQUEST_TEMPLATE.md (or PULL_REQUEST_TEMPLATE.md in the repo root).
Soft-break behaviour is configurable: by default a single newline becomes a space (CommonMark), toggle on for chat-style
<br>insertion.savesoft-breaksoptionsconfiglivepath · options.github · livePULL_REQUEST_TEMPLATE.md
options applied · livelive - 03
Open a PR
GitHub pre-fills the description box. Authors fill in the blanks.
The preview is scoped under a
.mdeclass so its CSS doesn’t bleed into the rest of the page. Output HTML is whitespace-controlled for clean diffs.prpreviewscoped CSSrenderstablefill · rendered✓ · readyCloses #123
rendered · liverendered - 04
Iterate
Trim sections that go untouched; add new ones via the toggles.
Export covers both raw Markdown and rendered HTML; downloads stream as
text/markdownortext/htmlviaBlob+ object URL.iterateclipboard.md.htmlblob✓ · exportedtuned · done✓ Copied
shipped · ready to shipsuccess
Author Markdown that renders everywhere
GFM is the safe default
GitHub-Flavored Markdown is the de-facto baseline (tables, task lists, strikethrough). CommonMark is stricter but ubiquitous as a fallback.
Soft-break behaviour varies
A single newline is a space in CommonMark, a <br> in GFM. Toggle soft breaks when source matters.
Escape inside code fences
Backticks inside fenced blocks need a longer fence — three becomes four. Use ~~~ if your content has many backticks.
Anchors are slugified
GitHub lowercases, strips punctuation, and joins with hyphens. Duplicate headings get -1, -2 suffixes.
Tables need a header row
The dash row sets alignment (:---, :-:, ---:). Use Table Aligner for diff-friendly columns.
Front matter is YAML
Triple-dash blocks at the top of files are parsed by static-site generators. Use the Front-Matter Validator to catch syntax errors.
When to add a PR template
Any repo with contributors.
OSS projects
Set clear expectations for contributors. Render path uses marked with GFM extensions enabled (tables, task lists, strikethrough, autolinks), so what you preview matches what GitHub publishes bit-for-bit. Soft-break behaviour is configurable for chat-style vs prose Markdown.
GFM-compliantInternal repos
Reduce reviewer ping-pong with a structured description. Pairs cleanly with the Markdown Cheatsheet for syntax you can't quite remember — callout blocks, footnotes, definition lists. Output stays diff-friendly so style-only changes don't drown out real edits in PRs.
GitHub-perfectFrontend repos
Force before/after screenshots in every UI PR. Cross-platform safe: anchors, code fences, and tables behave identically on GitHub, GitLab, Bitbucket, and Gitea. Heading-anchor slugs follow GitHub's lowercase-and-hyphenate rules so deep links survive a docs migration.
diff-friendlyLinked issues
Auto-close issues by including a Closes # line. No server roundtrip — perfect for proprietary content you can't paste into a public tool. The full marked + GFM bundle ships with the page, so it works offline once loaded.
render-stableTest plans
Make manual test steps explicit and reviewable. Front matter (YAML / TOML / JSON) passes through unchanged so static-site pipelines (Jekyll, Hugo, Astro, Eleventy) read it correctly. Pair with the Front-Matter Validator to catch syntax errors before deploy.
cross-platformCompliance
Standardise diligence checklist across the org. Output is reproducible: identical input always produces identical Markdown, so doc-generation scripts can rely on it for snapshot tests and embedded into release workflows.
SEO-friendlyFrequently asked questions
Something missing?
Tell us what you need. We ship the top requests every two weeks.