Individual checklists depend on who happens to be reviewing. A PR template doesn't. Add an AI-specific section to your repo's pull request template so every AI-assisted change states its acceptance criteria, test evidence, and blast radius before a human ever opens the diff.
Why a Checklist in Your Head Isn't Enough
Most teams already know what a good AI-assisted PR should contain: clear intent, test coverage, and an honest account of what changed. The problem is that this knowledge lives in individual reviewers' heads, and it shows up inconsistently. One reviewer asks for the reasoning behind a diff. Another approves on green CI alone. Neither is wrong, but the team ends up with uneven standards that scale badly as more of the codebase is AI-assisted.
A shared PR template fixes the inconsistency at the source. It doesn't require reviewers to remember a framework — the author has to fill in the sections before the PR is even opened for review. The standard becomes a property of the repository, not a property of whoever happens to be free that day.
The Copy-Paste Template
Drop this into .github/PULL_REQUEST_TEMPLATE.md (or your platform's equivalent). Keep the AI section visible only when relevant — most teams add a checkbox at the top so human-only PRs can skip it.
## Summary
What does this change do, in one or two sentences?
## AI-assisted change?
- [ ] Yes — complete the section below
- [ ] No — skip to Testing
### Acceptance criteria
What must be true for this to be considered done? (link to issue/spec if one exists)
### Non-goals
What did this PR intentionally NOT change?
### Edge cases considered
List at least two boundary or failure scenarios you checked.
### Blast radius
Which files/systems outside the obvious scope could this affect?
## Testing
- [ ] New/updated tests cover the change above
- [ ] Ran the app locally and exercised the affected flow
- [ ] Checked for regressions in adjacent features
## Rollback
How would this be reverted or disabled if it's wrong in production?
Every section maps to a question a reviewer would otherwise have to ask manually. Filling it in is the author's job, not the reviewer's — that's what makes the template save time instead of adding process overhead.
Rolling It Out Without Friction
- Pilot on one repo. Pick the repository with the most AI-assisted PRs, not the riskiest one.
- Ask, don't mandate, for two weeks. Let early adopters show the template catching real issues before enforcing it.
- Add a lightweight CI check. Fail the check only if the AI-assisted box is ticked and the required sections are empty — never block human-only PRs.
- Revisit quarterly. Drop sections nobody fills in honestly; they're friction without signal.
Teams that mandate a long template on day one usually get it filled in with copy-pasted filler text. Teams that let the template prove its value first get real answers.
Scaling the Template to Risk Level
Not every AI-assisted PR needs the full template. A one-line copy fix and a change to the payments flow do not carry the same risk, and forcing both through identical process just teaches people to skim.
- Low risk (copy, styling, internal tooling): summary and testing sections only.
- Medium risk (new features, non-critical services): full template as written above.
- High risk (auth, billing, data deletion, public APIs): full template, plus a named second reviewer and a rollback plan reviewed before merge, not after.
Letting the author decide their own risk tier without any check. In practice, pair it with a short rule: anything touching the directories or services your team already treats as sensitive is automatically medium risk or higher, no exceptions.
Handling the Predictable Pushback
"This will slow us down" is the most common objection, and it's worth taking seriously rather than dismissing. In practice, the template rarely adds time to the review — it moves time that was already being spent in review comments into the PR description, where it's faster to write and easier to reuse.
If a team genuinely slows down after adopting this, the template is usually too long for the repo's actual risk profile. Cut sections before abandoning the idea entirely.
Conclusion
A checklist that lives in one reviewer's head does not scale past that reviewer. A template that lives in the repository scales with the team. The goal isn't more process — it's making the same standard show up automatically, on every PR, without anyone having to remember to apply it.
This template operationalizes The AI Code Ownership Checklist and The AI Acceptance Criteria Prompt as a repo-level artifact. Pair it with AI Code Review for the review workflow itself, and 25 AI Code Review Comments That Actually Improve Diffs for what to actually write in the review.