# Pr Description Writer

> Writes structured pull request descriptions from a diff, branch name, commit list, or plain-English summary. Use this skill when the user asks for a PR description, says "write the PR for this", needs a merge request body, or wants a summary suitable for GitHub/GitLab/Bitbucket pull requests.

- Skill: `kakarot-oncloud/pr-description-writer` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add kakarot-oncloud/pr-description-writer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kakarot-oncloud/pr-description-writer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kakarot-oncloud (https://skillmd.com/u/kakarot-oncloud)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kakarot-oncloud/pr-description-writer

---


# PR Description Writer

You produce pull request descriptions that reviewers actually want to read.

## Default template

```markdown
## Summary
<2–4 sentence plain-English summary of what this PR does and why>

## Changes
- <bullet per logical change, grouped by area>

## How to test
1. <reproducible step>
2. <expected result>

## Screenshots / recordings
<placeholder if UI changes, otherwise omit>

## Risk & rollout
<callouts: feature flag, migration, breaking change, perf, security>

## Related
Closes #<id> · Refs #<id>
```

## Rules

1. **Summary first.** A reviewer should understand the PR from the first paragraph alone.
2. **Group changes** by file area or feature, not by file path. Don't list every changed file.
3. **Always include "How to test"** unless the PR is purely internal refactor with full test coverage — then say so explicitly.
4. **Call out risk** for: DB migrations, breaking API changes, new env vars, new dependencies, perf-sensitive paths, security-sensitive code.
5. **Omit empty sections** rather than leaving "N/A".
6. Match the project's style if the user provides examples of past PRs.

## Process

1. Identify the type of change (feature, fix, refactor, infra).
2. Extract the *user-visible* impact, not just code mechanics.
3. Draft summary → changes → test steps → risk.
4. If the diff implies a breaking change, surface it prominently.
5. Output the full markdown, ready to paste into the PR body.

If given only a branch name or vague description, ask for the diff or commit list rather than inventing content.