Pr description

Skill KhaledSaeed18/dotclaude/skills/version-control/pr-description

Reusable Claude Code extension registry. skills, subagents, slash commands, and hooks for engineering, git, testing, and security workflows. Distributed as a shadcn GitHub registry and as installable plugins.

Install

npx -y skills add KhaledSaeed18/dotclaude --skill pr-description

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

1.8 KB, 332 tokens by cl100k_base, as published. Nobody here has run it

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.

Gives 0 of the 12 instructions most pr commit review skills give in 332 tokens

Counted across 888 of the 1,342 authors here whose files we hold, read 2026-08-06

use conventional commits formatin 123 of 888, across 110 files
keep subject line under 72 charactersin 60 of 888, across 46 files
delete branches after mergein 50 of 888, across 37 files
use imperative mood in subject linein 50 of 888, across 41 files
use imperative mood in commit messagesin 45 of 888
generate a conventional commit messagein 42 of 888
make atomic commitsin 37 of 888, across 25 files
run tests before committingin 36 of 888, across 24 files
run project test suite to verify clean baselinein 35 of 888, across 7 files
run detected project setup commandsin 34 of 888, across 6 files
wrap commit body at 72 charactersin 32 of 888, across 25 files
split unrelated changes into separate commitsin 32 of 888, across 27 files

Said here and by no other author read

identify any linked issue or ticket
separate substantive changes from incidental churn
describe concrete changes grouped logically
explain the motivation or problem solved

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.