.github/PULL_REQUEST_TEMPLATE.md

Generate a pull request template

Pick the sections you want — summary, motivation, screenshots, testing, checklist — and drop the Markdown straight into .github/.

PR Template Generator
Markdown
508 B
36 lines
Sections
7 of 7
enabled
Checkboxes
9
in template
Target
.github/
PR template path
input · sections
output · PULL_REQUEST_TEMPLATE.md
## 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
Quick Start

How to add a PR template

GitHub pre-fills the PR description with this file whenever someone opens a new PR.

  1. 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.

    pickGFMmarkedCommonMarklive
    sections · markdown7 · GFM
    ## Summary
    loaded · GFMGFM · ready
  2. 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-breaksoptionsconfiglive
    path · options.github · live
    PULL_REQUEST_TEMPLATE.md
    options applied · livelive
  3. 03

    Open a PR

    GitHub pre-fills the description box. Authors fill in the blanks.

    The preview is scoped under a .mde class so its CSS doesn’t bleed into the rest of the page. Output HTML is whitespace-controlled for clean diffs.

    prpreviewscoped CSSrenderstable
    fill · rendered✓ · ready
    Closes #123
    rendered · liverendered
  4. 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/markdown or text/html via Blob + object URL.

    iterateclipboard.md.htmlblob
    ✓ · exportedtuned · done
    ✓ Copied
    shipped · ready to shipsuccess
Pro tips

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.

Use Cases

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-compliant

Internal 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-perfect

Frontend 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-friendly

Linked 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-stable

Test 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-platform

Compliance

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-friendly
FAQ

Frequently asked questions

.github/PULL_REQUEST_TEMPLATE.md, or PULL_REQUEST_TEMPLATE.md in the repo root. GitHub auto-detects either.
Put files in .github/PULL_REQUEST_TEMPLATE/ and pass ?template=foo.md in the new-PR URL.
Yes — same file picked up at .gitlab/merge_request_templates/Default.md or .bitbucket-templates.
Yes — leave 'Closes #' in the issue link section so the author fills the number.
No. Template is built locally.
Suggest a tool

Something missing?

Tell us what you need. We ship the top requests every two weeks.

Sent straight to the maintainers · no account needed
47 in queue·8 shipped this month
Request queued. Thanks!