PR Describer

What it does

Title and description from your diff. No filler.

Your agent loads it when the user opens or describes a pull request. It carries 5 rules and reads a profile.md with your details before it starts, so the output matches your brand and project.

SKILL.md, first 40 lines

---
name: pr-describer
description: "Use when the user says 'write the PR description', 'describe this PR', 'PR title', 'summarise my changes', 'what should the commit message be', or is about to open a pull request. Reads the diff and the commits, then writes a short, honest title and description: what changed, why, how to test it, risk, and a screenshots placeholder for UI changes. No filler. Reads profile.md for project, stack, strictness and conventions."
---

# PR Describer

A pull request description exists so a reviewer can decide in two minutes where to look hardest. It is not a diary and not a sales pitch.

## Before you start

Read `profile.md` in this folder:

| profile.md line | Use |
|---|---|
| **Project** | Name the service or area in the summary when it helps a reader outside the team. |
| **Stack** | Pick the right test commands and the right words (migration, route, component, handler). |
| **Strictness** | Gentle: describe and flag only the obvious risk. Standard: the full template. Strict: also list what you did not test and every behaviour change. |
| **Conventions** | Title format (for example conventional commits), commit and branch rules. Follow them exactly. |

If a line says "not set", ask once, write the answer into profile.md, continue.

## Workflow

1. **Get the change.** Run `git diff <base>...HEAD --stat`, then the full diff, then `git log <base>..HEAD --oneline`. If the user pasted a diff, use that. Never describe a change you have not read.
2. **Find the why.** Look in commit messages, the branch name, linked issue numbers and code comments. If the reason is not in any of them, ask one question: "Why is this needed now?" Do not invent a motivation.
3. **Classify the change.** One primary type: feature, fix, refactor, perf, docs, test, chore, migration. If the diff mixes a refactor with a behaviour change, say so in the description and suggest splitting.
4. **Write the title** using the Conventions line. Without one: imperative mood, under 72 characters, no trailing period, says what the change does ("Retry webhook delivery with backoff"), not what you did ("Updated webhook code").
5. **Write the description** with the template below. Every section is required, but a section may be one line.
6. **Run the honesty check** at the end before you hand it over.

## Template

```markdown
## What
<1-3 sentences: the behaviour that is different after this merges.>

## Why
<The problem or ticket. Link the issue. One short paragraph at most.>

Install

One command, in your project folder. It detects your agent; add --agent all for every agent.

npx proskills-cli add pr-describer

Or copy the skill folder (the one holding SKILL.md) into the directory your agent reads, then restart it or start a new session.

More from Code Review

• PR Reviewer$12Staff-level review. Every finding labelled, with a line.
• Security Review$12Exploit sketch, severity and fix for each finding.
• Test Writer$9Tests that fail before the fix and pass after.