Pr description

Skill kwhorne/elyra-skills/skills/pr-description

51 production-grade Agent Skills for AI coding agents — full software lifecycle (idea → spec → build → review → ship → operate → maintain) plus Laravel/TALL/VILT/Filament stack workflows. Works with Elyra, Claude Code, Cursor, and more.

Install

npx -y skills add kwhorne/elyra-skills --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

1 stars1 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

Write a clear, scannable pull request description from a diff or branch. Use when the user asks to draft a PR description, summarize a branch, prepare a change for review, or fill out a PR template.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.5 KB, 807 tokens by cl100k_base, as published. Nobody here has run it

PR Description

A reviewer should be able to answer "what changed and why" in 30 seconds. That's the whole goal.

When to use

"Write a PR description for this branch"
"Summarize what's in this PR"
"Fill out the PR template"
"Draft a pull request"

Procedure

Identify the change set. Default to git diff <base>...HEAD where <base> is the merge target (usually main / master / develop).

git fetch origin
BASE=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@' || echo main)
git log --oneline "origin/$BASE..HEAD"
git diff --stat "origin/$BASE...HEAD"

Look for an existing template. Check .github/pull_request_template.md or docs/PULL_REQUEST_TEMPLATE.md. If found, follow its structure; otherwise use the default below.
Read the diff itself, not just commit messages. Commit messages lie or lag; the diff is truth.
Identify:
- The one sentence that summarizes the change (this is the PR title)
- The why — problem, context, motivation
- The what — what actually changed, grouped logically (not file-by-file)
- Anything reviewer-visible: API changes, migrations, env vars, breaking changes
- Verification steps the reviewer can run
Draft. Then trim. First draft is always too long. Cut anything the diff already shows.

Default template

## Summary
<one or two sentences — the elevator pitch>

## Why
<problem this solves, links to issues/discussions>

Closes: #123

## Changes
- <grouped logical change>
- <another grouped logical change>
- <…>

## How to verify
1. <concrete step a reviewer can run>
2. <…>

## Notes for reviewer
<anything non-obvious: tricky bits, deliberate trade-offs, things you want extra eyes on>

## Risk & rollout
<breaking changes, migrations, feature flags, env vars, deploy order>

Drop sections that don't apply. A docs PR doesn't need "Risk & rollout."

Title

<type>(<scope>): <imperative summary> if the project uses Conventional Commits, otherwise a clear imperative sentence ≤72 chars. No trailing period.

✅ feat(auth): support passwordless email login ✅ Fix race condition in cache invalidation ❌ Updates ❌ WIP - some changes to auth

Anti-patterns

❌ Listing files changed — the diff already does that
❌ "Various fixes and improvements" — useless to reviewer and to future archaeology
❌ Copy-pasting commit messages as the body
❌ Hiding breaking changes in the middle of a bullet list
❌ "Tested locally ✅" without saying what was tested
❌ Putting the "why" only in a linked issue — the reviewer should not need to context-switch

Tips

Screenshots / before-after are gold for UI changes
Migration notes: if a consumer needs to do something, put it in its own section with a ⚠️ so it can't be missed
Stacked PRs: link to the parent and explicitly say "depends on #N"
Draft PRs: prefix the summary with what's still TODO before review is welcome
If the PR ended up doing more than one thing, suggest splitting before writing the description — it'll be a better PR

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

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

use conventional commits formatin 127 of 888, across 115 files
keep subject line under 72 charactersin 62 of 888, across 48 files
delete branches after mergein 51 of 888, across 38 files
use imperative mood in subject linein 51 of 888, across 42 files
use imperative mood in commit messagesin 44 of 888
verify directory is ignored before creating worktreein 43 of 888, across 12 files
generate a conventional commit messagein 43 of 888
add unignored worktree directories to gitignorein 42 of 888, across 10 files
make atomic commitsin 39 of 888, across 27 files
run tests before committingin 36 of 888, across 25 files
verify clean test baselinein 35 of 888, across 9 files
split unrelated changes into separate commitsin 35 of 888, across 30 files

Said here and by no other author read

look for an existing template
draft then trim
drop sections that do not apply
use an imperative summary for the title
suggest splitting if the PR does more than one thing

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.