dotclaude

Skill in version-control

pr-description

Generate a clear, reviewer-friendly pull-request description from a diff, covering what changed, why, risk, and how it was tested. Use when opening a pull request or writing/improving a PR body.

Arguments
(optional) base branch, ticket, or PR focus

Install

As a plugin

Bundled in the git plugin. Add the marketplace once, then install the bundle; it updates with the marketplace.

/plugin marketplace add KhaledSaeed18/dotclaude
/plugin install git@dotclaude

As a single item

Run from the project root; the skill lands under .claude/. Copy it to ~/.claude/ to make it global.

npx shadcn@latest add KhaledSaeed18/dotclaude/pr-description

Files installed

  • .claude/skills/pr-description/SKILL.md

What it does

Write a pull-request description from the actual changes on this branch. Base it on the diff, not on what you assume was intended.

Gather context

  • Diff the branch against its base (default to the repo's main branch, or the base the user named): review the changed files, the commits, and their messages.
  • Identify the linked issue/ticket if one is referenced in the branch name, commits, or arguments.
  • Separate the substantive change from incidental churn (formatting, renames, generated files).

Write the description

Use this structure, omitting any section that genuinely doesn't apply:

  • Summary: one or two sentences on what this PR does.
  • What changed: the concrete changes, grouped logically, referencing key files.
  • Why: the motivation or problem being solved; link the issue.
  • Risk / impact: blast radius, backward compatibility, breaking changes, data migrations, config/env or infra changes, anything reviewers should scrutinise.
  • Testing: how it was verified, including tests added/updated, manual steps, and explicitly what was not covered.
  • Notes for reviewers: trade-offs, follow-ups, screenshots for UI changes.

Rules

  • Be factual and specific; describe what the diff does, and don't speculate or oversell.
  • Call out breaking changes and required migration steps prominently.
  • Keep it scannable: short paragraphs and bullets over walls of text.
  • If the repo has a PR template (.github/PULL_REQUEST_TEMPLATE*), match its structure.
  • Never fabricate test results; if something wasn't tested, say so.

This is the skill as installed, rendered from its source on GitHub. Read it as Markdown.

  • changelogGenerate a changelog or release notes from Git history, grouped by change type, written in user-facing language, with issue/PR links and breaking changes...
  • finish-branchWrap up a completed development branch by verifying tests pass, detecting the workspace state, then presenting clear merge / PR / keep / discard options...
  • git-commitCommit work the right way by gathering full repo state, respecting the project's commitlint/pre-commit/branch rules, staging only understood files, and...
  • git-undoRecover safely from Git mistakes such as discard, unstage, amend, reset, revert, restore lost commits via reflog, recover deleted branches, and fix bad...
  • git-worktreesSet up an isolated workspace for feature work so the current branch and working tree stay untouched, detecting existing isolation first, preferring the...
  • gitignoreGenerate or repair a .gitignore tailored to the project's actual stacks, frameworks, OS, and editors, and untrack files that are already committed but...