# Describe Pr

> Generate a concise PR description with Problems and What does this PR do sections. Use when the user asks to describe a PR, write a PR description, or summarize changes for a pull request.

- Skill: `tiennguyen1203/describe-pr` (Agent Skill)
- Install (CLI): `npx skillmds@latest add tiennguyen1203/describe-pr`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tiennguyen1203/describe-pr/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: tiennguyen1203 (https://skillmd.com/u/tiennguyen1203)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/tiennguyen1203/describe-pr

---


# Describe PR

Generate a pull request description by analyzing the current branch's changes against the main branch.

## Process

1. **Gather context**: Run `git log main..HEAD --oneline` and `git diff main...HEAD --stat` to understand all changes
2. **Read changed files**: Read the key modified files to understand the nature of the changes
3. **Identify the problem**: Understand _why_ the changes were made — what was wrong, missing, or suboptimal before
4. **Summarize the solution**: Describe _what_ the PR does to address the problem

## Output Format

Output the description **inside a fenced ` ```markdown ` code block** so the user can copy it in one click. Always use this exact structure:

## Problems

- [Concise bullet points describing the issues/limitations that existed before this PR]
- [Focus on the "why" — what was wrong, duplicated, missing, or inefficient]

## What does this PR do?

- [Concise bullet points describing the changes made]
- [Focus on the "what" — actions taken, not implementation details]
- [Use active verbs: Remove, Add, Introduce, Reuse, Replace, Decouple, etc.]

## Rules

- **Always write in English**: The description is always in English, no matter what language the user's request is in
- **Keep it short**: The entire description should be scannable in under 30 seconds. Aim for 2-3 bullets per section max
- **Stay high-level**: Give the gist, not the details — describe changes at the feature/behavior level, not the code level. When in doubt, cut
- **Be concise**: Each bullet should be 1 line — 2 lines only if absolutely necessary
- **No implementation details**: Don't mention specific method names, variable names, line numbers, or internal logic
- **Never mention testing**: No tests, specs, test counts, coverage, or test files — the description covers behavior, not verification
- **Problem-first**: The Problems section explains the motivation; the solution section explains the action
- **Use plain language**: Write for reviewers who may not know the codebase deeply
- **Group related changes**: Don't list every file change — group them by logical concern
- **No fluff**: Skip phrases like "This PR aims to..." or "In order to improve..."
- **Highlight key terms**: Use bold or backticks to highlight important domain keywords, statuses, or values that are central to the change (e.g., **ACCEPTED**, `REMOVED`). This makes key terms easy to scan for reviewers