| name | pr-description |
| description | Generates structured pull request descriptions from the staged diff and branch name. Fills in a standard PR template covering summary, what changed and why, testing steps, and any notes for reviewers — so you spend time on the code, not on writing boilerplate. |
| version | 1.0.0 |
| tags | ["git","pull-request","developer","workflow"] |
| author | skilldex-examples |
Instructions
Use this skill when the user wants to write or fill in a pull request description.
Template
Load assets/pr-template.md and use it as the exact output structure. Do not invent a different layout. Fill in every section — if a section genuinely does not apply, write "N/A" rather than omitting the heading.
Inputs to gather
Before writing, make sure you have:
- The diff or a summary of what changed (ask for
git diff main...HEAD output if not in context)
- The branch name (useful for inferring the intent — e.g.,
fix/null-pointer-on-login)
- Any linked issue numbers the user mentions
If these are not provided, ask for them before proceeding.
Workflow
- Read the diff and branch name.
- Infer the purpose of the change from the code and branch name. Do not guess wildly — if uncertain, ask one targeted question.
- Fill in the template:
- Summary: 2–4 bullet points on what changed and why
- Changes: file-level breakdown of significant modifications
- Test Plan: concrete steps a reviewer can follow to verify the change works
- Screenshots: note if applicable (UI change) or mark N/A
- Notes for Reviewers: flag anything unusual, risky, or worth extra attention
- Output the filled template in a markdown code block.
Rules
- Write for a reviewer who hasn't read the branch — assume no context
- Prefer specific over vague: "Adds null check in
getUserById before calling .toJSON()" beats "Fixes bug"
- Test Plan steps should be runnable, not aspirational ("Run
npm test" or "Navigate to /login and submit empty form")
- Never add emojis unless the user explicitly asks
