Template · updated October 2026

A pull request template for AI-assisted changes, and where reviewers should look

A description template that asks for intent, evidence, risk, which parts an assistant wrote and where the reviewer should look first. Copy it into your repository, then read the section below on how to use each answer when you review.

The template

Save it as .github/pull_request_template.md. GitHub also reads it from the repository root or docs/, and fills new pull request descriptions with it once it is on the default branch (GitHub Docs).

## What and why
<!-- One or two sentences: the problem, and why this change solves it. -->

## What changed
<!-- The files or modules that matter. Say what you deliberately did not change. -->

## Evidence
<!-- How you know it works: tests added or run, a screenshot, a log, steps to reproduce. -->

## Risk
<!-- What could break, who would notice, and how to roll it back. -->

## AI use
<!-- Which tool, and which parts it wrote or changed. "None" is a fine answer. -->
<!-- What you checked by hand, line by line, before asking for review. -->

## Where to look
<!-- The two or three places a reviewer should read closely, with file:line. -->
<!-- Anything you are unsure about, said plainly. -->

Why an AI use section

Open-source projects that publish AI contribution policies ask for exactly this. Ghostty's AI policy asks contributors to name the tool and the extent of AI assistance. Kubernetes accepts one sentence in the PR description (pull request guide). LLVM's tool policy asks contributors to review everything a tool generated before asking for review, and recommends writing the description yourself. The section above does all three: tool, extent, and what you checked by hand. Check your own project's rule before adding a commit trailer for it: LLVM suggests an Assisted-by: trailer, Kubernetes forbids one.

How to use it when you review

• Where to look. Start where the author pointed, then read the parts they did not mention: an author who used an assistant may not know which lines it changed beyond the ones they asked for.
• AI use. If a part was generated, read it the way you would read code from a confident newcomer: check the names it calls exist, the edge cases it claims to handle, and the comments that explain constraints.
• Evidence. Tests the change added should fail without the change. A test that only restates the implementation passes either way.
• Risk. The rollback line tells you how much of the change is reversible. Data migrations, deletions and external calls are not.

For the security pass, see the security checklist for AI-written pull requests.

Review guides · Code review glossary