pr-description

Write pull request titles and bodies that explain why changes exist and how they work.

8|1|Updated Feb 17, 2026
One-click install
npx skills add https://github.com/jaredpalmer/skills --skill pr-description-jaredpalmer
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: pr-description
Source: https://github.com/jaredpalmer/skills/tree/main/pr-description
Command: npx skills add https://github.com/jaredpalmer/skills --skill pr-description-jaredpalmer

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Most pull request descriptions merely restate the diff, forcing reviewers to reverse-engineer intent and leaving future readers of git log without context. This Skill produces PR titles and bodies that teach the reader the problem, the mechanism, the assumptions, and the evidence behind a change. ## Core Features & Use Cases - Essay-style PR writing: Structures descriptions as problem first, mechanism second, risks third, and omitted scope last, modeled on Andrew Clark and Sebastian Markbåge's PRs on facebook/react. - Repo-aware conventions: Reads the full branch (git log main..HEAD, git diff main...HEAD), checks PR templates and project rules, and matches existing title and squash-merge commit conventions. - Evidence-based test plans: Ends with a Test plan checklist carrying re-runnable evidence such as exact commands, before/after timings, and byte-identical output comparisons. - Use Case: After finishing a feature branch, ask for a PR description and get a title following repo conventions plus a body that explains the motivation, defines key terms, states assumptions and decision rules for uncertain bets, and lists verifiable test evidence. ## Quick Start Write a pull request title and description for my current branch compared to main, following this repo's conventions.

Frequently Asked Questions about pr-description

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a good pull request description?▼

Start with the problem as it exists before the change, then explain the mechanism as an argument with one concrete artifact per idea. State the assumption the change relies on, what is uncertain, what is deliberately excluded, and end with a test plan carrying evidence a reviewer could re-run.

How to write a PR title for squash merge commits?▼

Write the title as the change in a sentence, naming the surface it touches and linking the issue or plan item when one exists, since it usually becomes the squash commit subject. Follow the repo's existing prefix or scope conventions found in recent git log subjects.

What should a pull request test plan include?▼

A test plan should carry evidence a reviewer could re-run: exact commands, what was compared against what such as byte-identical output against main or before/after timings, and screenshots for UI changes. Avoid vague claims like tests pass.

Does this work with repos that have PR templates?▼

Yes. The Skill checks for pull request templates and project rules like AGENTS.md or CONTRIBUTING.md first, and their required sections and conventions take priority. The prose is written inside the template's structure.

How long should a pull request description be?▼

Length follows novelty. A new subsystem or public API earns headings like Motivation and Mechanism, while a one-line fix earns a single sentence of reason. Headings are only used when there is enough text to navigate.