GitHub pull request template generator with a checklist and an AI section

Where a GitHub PR template goes

GitHub reads a pull request template from three places: the repository's root (pull_request_template.md), its docs folder (docs/pull_request_template.md) or its hidden .github folder (.github/pull_request_template.md). The file name is not case sensitive, and it can end in .md or .txt. For files that can live in more than one of those places, GitHub looks in .github first, then the root, then docs.

The file has to be on the repository's default branch. GitHub's docs are plain about it: templates created on other branches are not available to collaborators. So open a pull request that adds the file, merge it, and the next pull request anyone opens starts with your template in its description.

A pull request template example

The shortest template worth having asks three things: what changed and why, which issue it closes, and how it was tested. This is the generator's Minimal preset:

## Summary

<!-- What changed, and why. Two or three sentences a reviewer can read first. -->

## Linked issue

<!-- Add the issue number. GitHub closes the issue when this merges into the default branch. -->

Closes #

## How it was tested

<!-- Commands you ran, cases covered, and what you checked by hand. -->

The lines inside <!-- --> are HTML comments. The author sees them while writing, and GitHub hides them once the description is rendered, so a prompt nobody deleted doesn't clutter the pull request. Closes # is a closing keyword: with the issue number after it, GitHub closes that issue when the pull request merges into the default branch.

What to ask for, and what to leave out

• Summary and testing answer a reviewer's first two questions: what is this, and how do you know it works. Keep them at the top.
• A checklist uses GitHub's task-list syntax (- [ ]), which renders as boxes the author can tick. Keep it to items a person can honestly answer in a few seconds; a check your CI already runs doesn't need a box. Our code review good practices guide covers what belongs in a review standard.
• Type of change, screenshots, risk and rollback earn their place on some teams and are noise on others. Every section you add is one more thing to fill in on a one-line fix, so start small and add a section when a review shows it was missing.

A template is a starting text, not a form: GitHub puts it in the description box, and the author can change or delete any of it. If a section must not be skipped, check for it in CI.

Why the template asks about AI assistance

When a coding agent writes most of a change, the reviewer's first questions are different: which agent and model, and what the author read, ran or changed by hand. The AI assistance section puts those answers in the description, where the reviewer already looks. Our write-up of 866 agent-written pull requests shows what such pull requests look like in our own repositories.

A coding agent can also open the pull request itself, from the command line. The GitHub CLI's gh pr create takes the description from --body, and has a --template option that starts the body from a template file. Tell the agent which one to use in the repository's instructions file (CLAUDE.md or AGENTS.md), or its pull requests may arrive without your sections.

A section in a template relies on each author to fill it in. Zest records the agent, model and cost of each coding session and links the session to the pull request it led to, so a team sees the same answer for every pull request without asking.

More than one template, and one for the whole organization

For several templates (a release, a hotfix, a docs change), create a PULL_REQUEST_TEMPLATE subdirectory in the root, docs or .github folder and put one file per template in it. A template is then chosen by URL: add ?quick_pull=1&template=release.md to a compare URL and GitHub opens the pull request with that file as its body.

To share one template across repositories, GitHub's docs say you can create a default pull request template for an organization or a personal account. Defaults live in a repository named .github, which has to be public, and apply to any repository of that account that doesn't have its own file of that type.