Agent skill · warpdotdev
write-pr-description
Writes the body of a pull request - the summary, the repository template sections, and reviewer guidance such as a recommended reading order and focus areas. Use whenever drafting or revising a PR description, filling in a repository's PR template, refreshing a description that no longer matches the branch, or preparing a branch for review. Use it even when the user only says "open a PR", "put this up for review", or "write this up" without naming the description.
What it needs
About 10k tokens when loaded.
What this skill does
write-pr-description A pull request description has one job: give the reviewer what the diff cannot. The diff already states what changed. The description states why it changed, what it affects, which decisions were made along the way, and where the author wants attention. Everything below follows from that. When a rule here conflicts with what a specific reviewer needs, serve the reviewer. create-pr covers the mechanics of opening the PR. This skill covers what goes in the body. 1. Collect the facts before drafting Usually you did the work and already know most of this. When you are describing a branch you did not write, or a PR you have just been handed, start here. Read the commit bodies before the diff. They are usually the richest source of motivation. Then verify what they claim: a commit message saying "matches the existing pattern in this file" is an assertion about code, and it is often wrong. Do not forward a claim you have not checked. Verify by looking, not by reasoning. The checks worth making are cheap and specific: Read what the change deletes. When a change exists to fix something, the defect is usually visible in the removed code. Ask the system what a thing means, rather than inferring it: gcloud iam roles describe for a role's permission set, the provider or API schema for a resource's fields, the parser for what a marker does. Grep a flag across the environment files before claiming it is on or off. Open the file a comment or commit message points at, and confirm it says what the pointer claims. One check of this kind usually produces the best sentence in the description. Gather what the diff cannot tell the reviewer: The motivation. What breaks, costs, or stays impossible without this change. The linked issue, spec, or design doc, and any spec files committed on the branch. Decisions with a real alternative, and why the alternative lost. The blast radius: what this can break beyond the files it touches. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills warpdotdev/write-pr-description