pr writes the body of a pull request: the description a reviewer reads before the branch is merged into main. Its goal is a body that's fast to review. It fills one template with three parts:
Summary: the smallest picture that shows the change, such as a file tree, a call tree, a short diff or a diagram.
Evidence: a before and after that proves the change works, such as a failing test run and then a passing one, or two screenshots.
Merge Danger: whether merging is a one-way or a two-way door, and the blast radius.
A two-way door is a change you can walk back cheaply, like a new page you can revert. A one-way door can't be walked back, like a SQL migration that drops a column and its data. The blast radius is how much the change could affect if it goes wrong.
When to use it
Whenever work goes up as a pull request. In the main flow that's after a Ticket is built test-first with tdd and reviewed with code-review. The pull request is where CI runs and where the change waits to be merged.
pr is model-invoked: the agent reaches for it by itself whenever it writes a pull request. You rarely type it.
When not to use it
To check the code itself, use code-review. It reviews the diff against the coding standards and the Spec. pr only describes a change; it doesn't judge it.
To pass unfinished work to a fresh session, use handoff. A handoff document is for the next agent, not for a reviewer.
A finished change on its own branch, already reviewed.
Evidence that it works: test output, console output, or a screenshot when the change is visual.
The project's GLOSSARY.md, so the body uses the project's own words. The body skips preambles and keeps prose brief.
What it creates
The text of the pull request body, with the Summary, Evidence and Merge Danger parts. It creates no files, branches or Issues. The pull request it describes is what later gets merged, and its body tells the reviewer how risky that merge is.
Going deeper
6 min read · Going deeper not read
Why it exists
Matt shipped pr in version 1.3 of his Skills. His changelog, last updated on 2026-10-05, opens with the reason:
Writing code got cheap. Reading it did not.
He goes on: "PRs are still the main bottleneck for work that gets to main." His answer is pr, a model-invoked Skill that "makes human review as fast and as simple as possible."
The Evidence part answers a habit of agents. In Matt's words, without a request for hard evidence "it is easy for an agent to say "that probably works, I read the code"." Asked for a before and after, the agent "often runs an extra test or takes an extra screenshot."
pr's first cut, in Matt's pull request #1092, sat in engineering/. A later pass moved it to in-progress/, "model-invoked, beta", and that is how it merged on 2026-09-17. Version 1.3 moved it back into the Engineering bucket, beside implement-spec and retro.
How it works underneath
A format reference, not an action. Pull request #1092 shows how pr got this way. The first cut was "a 9-step process", ending with opening the pull request through gh pr create. The last pass cut every git step, because none of them described the body's shape, and the closing step "turned a format reference into an action skill". Matt's page for pr says the same today: "It is a format reference, not a workflow." It never pushes a branch or opens the pull request.
From snapshot/skills/ask-matt/SKILL.md, line 32: “When the work goes up as a pull request, /pr shapes the body: the smallest visual that shows the change, before/after evidence that it works, and a one-way or two-way door call. It's model-invoked, so the agent reaches for it whenever it writes a PR.”
From snapshot/skills/ask-matt/SKILL.md, line 30: “the code gets built by driving (one red-green slice at a time) and closes out with , a two-axis review (Standards + Spec) of the diff.”
The Summary comes from show-me. The menu of views, from pseudocode to a shaped diff, is Dex Horthy's show-me Skill, "reproduced almost word for word and aimed at a diff instead of a live conversation", as pr's CREDITS.md says. Dex's post (2026-08-12) gives show-me's aim: "make your agent converse visually instead of in walls of prose." He also notes the same views help "explore large diffs post-hoc to understand what to dig into during review."
From Dex Horthy's show-me post, where pr's Summary views come from: a file tree marked with each file's changes. From humanlayer.com, 30 October 2026.
One-way and two-way doors. Jeff Bezos split decisions this way in his letter to Amazon's shareholders covering 2015. Some are "consequential and irreversible or nearly irreversible – one-way doors", made "methodically, carefully, slowly". Most are two-way doors: "You can reopen the door and go back through." His warning was about treating most decisions as the slow kind. Matt uses the same two doors for a narrower job, though his pages don't name Bezos: deciding how much care a merge gets. "Merge Danger tells you where to spend review time. A two-way door with a small blast radius: skim it. A one-way door: read it slowly." His page for pr adds that the door call turns "is this safe to merge?" from a gut feeling into "a stated claim the reviewer can disagree with."
two-way doors
one-way doors
Bezos
You can reopen the door and go back through.
methodically, carefully, slowly
Matt
A two-way door with a small blast radius: skim it.
A one-way door: read it slowly.
Merge Danger tells you where to spend review time.
A real example
Matt's changelog says the v1.3 release pull request, #1120 (opened 2026-09-24), "was written with this skill". Its body follows the template.
Summary: one line, "Graduates three skills for the 1.3.0 minor and retires one.", then a file tree drawn as a diff: three folders added under engineering/, the same three removed from in-progress/, and the deleted Skill's folder removed.
Evidence: a before and after. Before, plugin.json ships 25 skills. After, 27 skills, and claude plugin validate . --strict passes.
Merge Danger: a split call, "two-way for the graduations, one-way-ish for the removal and the glossary rename". The reason follows: once 1.3.0 is released, plugin users lose the removed Skill on update, and "It can be restored, but not before people notice it's gone." The blast radius is one word, "plugin".
Where it goes wrong
It loads on every pull request. On 2026-10-12 a user reported, in issue #1262, that a plain "create pr" loads pr "every time", so every body comes out in the Summary / Evidence / Merge Danger template. The issue was closed by a triage reply marked "generated by AI during triage", so not Matt's own words. It called this "working as designed" and pointed to a Claude Code deny rule, Skill(mattpocock-skills:pr), for anyone who wants it user-invoked only. After it was closed, the reporter added that it "ignores the repo's own PR template or CONTRIBUTING.md". Matt's page for pr confirms it "does not look for .github/pull_request_template.md", and suggests settling it in the repo's agent docs. Matt's own view, in his changelog (updated 2026-10-05), was that it is "one of the most reliable model-invoked skills I have seen."
The agent grades its own door. Matt's page warns: "be most suspicious when it says "two-way, small blast radius"." As one user put it on Matt's page, "rolling back a commit won't unsend a batch of emails". His fix is to give the agent the Ticket or Spec, not only the diff, and to write down which changes your repo always treats as one-way.
The body can describe the wrong pull request. Issue #1331 (2026-10-26, still open) tells of a branch cut from a feature branch instead of the target branch. "The PR body — written with this skill — accurately described the 8 docs files." The real diff was 70 files, and the human "reviewed the body (not the Commits tab), merged". The reporter's point: Evidence covers "does the change work"; "nothing covers does the body describe what the diff actually is." Their patch targets an older copy, skills/in-progress/pr/SKILL.md, which pointed to CONTEXT.md. But v1.3 (#1120, 2026-09-24) had already moved pr to engineering/ and renamed CONTEXT.md to GLOSSARY.md, a month before the report. Today's SKILL.md still has no scope check: its template goes straight from Summary to Evidence to Merge Danger.
The body goes stale. pr writes the body once. Matt's page: "a PR that changes under review leaves that body stale." Ask the agent to rewrite it after a large change.
Try it
In your practice project (set it up first with keeping-track's Try it step if you haven't): on a new branch, add a database migration in api/ that adds a nullable waitlist_position column for bookings, with a test. Ask the agent to open the pull request; pr should load on its own. Before reading the body, write down your own door call. Then run git diff main...HEAD --stat, a check the reporter of issue #1331 suggested, not something pr does. Compare its file list and your door call with the body. Matt's page suggests writing down the changes your repo always treats as one-way, "schema migrations, anything that ships outward or deletes". Ask yourself whether this migration belongs on that list.
From snapshot/skills/pr/SKILL.md, line 168: “You can walk back through two-way doors, but not one-way doors. A PR that is cheap to roll back is lower risk.”
From snapshot/web/github.com/mattpocock-skills-pull-1092.md, line 37: “cut the git-mechanics preamble, the reading-order section, and the closing gh pr create step entirely, since none of that describes the body's shape and the last one turned a format reference into an action skill.”
From snapshot/skills/pr/CREDITS.md, line 3: “The Summary section's menu of visuals (pseudocode, call trees, component trees, file trees, Mermaid, diffs) and its placement guidance come from Dex Horthy's show-me skill, reproduced almost word for word and aimed at a diff instead of a live conversation.”
From snapshot/web/github.com/mattpocock-skills-pull-1120.md, lines 86–92: “## Merge Danger Door: two-way for the graduations, one-way-ish for the removal and the glossary rename Once 1.3.0 is released, plugin users lose resolving-merge-conflicts on update. It can be restored, but not before people notice it's gone. Blast Radius: plugin”
From snapshot/web/aihero.dev/skills-pr.md, line 130: “Settle it in your repo's agent docs, for example by filling the repo template and putting Summary, Evidence and Merge Danger under it.”
From snapshot/web/aihero.dev/skills-pr.md, line 118: “The agent that wrote the change is the one grading it, so be most suspicious when it says "two-way, small blast radius". The diff also often hides whether a change can be reversed. As one user put it, "rolling back a commit won't unsend a batch of emails"”
From snapshot/web/aihero.dev/skills-pr.md, line 118: “make sure the agent has the ticket or spec in front of it, not just the diff, and write down the changes your repo always treats as one-way”
From snapshot/web/github.com/mattpocock-skills-issues-1331.md, lines 20–21: “The PR body — written with this skill — accurately described the 8 docs files. The PR's actual diff against the target was 70 files including all feature code. 5. The human reviewed the body (not the Commits tab), merged”
From snapshot/web/github.com/mattpocock-skills-pull-1120.md, line 74: “Also merges #876, which renames the domain-doc convention CONTEXT.md/CONTEXT-MAP.md to GLOSSARY.md/GLOSSARY-MAP.md across the skills and docs. On top of it, the rename now also covers pr (graduated here)”
From snapshot/web/aihero.dev/skills-pr.md, line 142: “It writes the body at one point in time, and a PR that changes under review leaves that body stale. Ask the agent to rewrite the body after a large change.”
