How do I install the Pr Description skill?

Run npx skillmds@latest add pandemonium-research/pr-description in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Pr Description safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Pr Description?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Pr Description free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Pr Description?

Pandemonium-Research (@pandemonium-research) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Pr Description by pandemonium-research

Name: Pr Description
Author: Pandemonium-Research

Pr 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.

File contents

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.

Shared conventions

Load ../assets/commit-conventions.md. The PR title uses the same type(scope): form as a commit, and the type you pick determines which changelog section the change lands in — so it must agree with the commit convention the rest of this skillset follows, not a per-PR judgement call.

When the branch name already carries a type (fix/null-pointer-on-login), prefer it. Otherwise infer the type from the diff using the same table.

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

---name: pr-descriptiondescription: 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.---## InstructionsUse this skill when the user wants to write or fill in a pull request description.### TemplateLoad `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.### Shared conventionsLoad `../assets/commit-conventions.md`. The PR title uses the same `type(scope):` form as a commit, and the type you pick determines which changelog section the change lands in — so it must agree with the commit convention the rest of this skillset follows, not a per-PR judgement call.When the branch name already carries a type (`fix/null-pointer-on-login`), prefer it. Otherwise infer the type from the diff using the same table.### Inputs to gatherBefore writing, make sure you have:1. The diff or a summary of what changed (ask for `git diff main...HEAD` output if not in context)2. The branch name (useful for inferring the intent — e.g., `fix/null-pointer-on-login`)3. Any linked issue numbers the user mentionsIf these are not provided, ask for them before proceeding.### Workflow1. Read the diff and branch name.2. Infer the purpose of the change from the code and branch name. Do not guess wildly — if uncertain, ask one targeted question.3. 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 attention4. 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

Frequently asked questions