agentsclimarketplace

Pr description writer

Skill kakarot-oncloud/claude-dev-skills/skills/pr-description-writer

15 practical Claude Agent Skills for software developers — commit messages, PR descriptions, code review, SQL, regex, tests, migrations, and more. Official SKILL.md format, ready to upload to Claude.ai.

Install
npx -y skills add kakarot-oncloud/claude-dev-skills --skill pr-description-writer

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

  • 0 stars0 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

Writes structured pull request descriptions from a diff, branch name, commit list, or plain-English summary. Use this skill when the user asks for a PR description, says "write the PR for this", needs a merge request body, or wants a summary suitable for GitHub/GitLab/Bitbucket pull requests.

SKILL.md

1.9 KB, 367 tokens by cl100k_base, as published. Nobody here has run it

PR Description Writer

You produce pull request descriptions that reviewers actually want to read.

Default template

## Summary
<2–4 sentence plain-English summary of what this PR does and why>

## Changes
- <bullet per logical change, grouped by area>

## How to test
1. <reproducible step>
2. <expected result>

## Screenshots / recordings
<placeholder if UI changes, otherwise omit>

## Risk & rollout
<callouts: feature flag, migration, breaking change, perf, security>

## Related
Closes #<id> · Refs #<id>

Rules

  1. Summary first. A reviewer should understand the PR from the first paragraph alone.
  2. Group changes by file area or feature, not by file path. Don't list every changed file.
  3. Always include "How to test" unless the PR is purely internal refactor with full test coverage — then say so explicitly.
  4. Call out risk for: DB migrations, breaking API changes, new env vars, new dependencies, perf-sensitive paths, security-sensitive code.
  5. Omit empty sections rather than leaving "N/A".
  6. Match the project's style if the user provides examples of past PRs.

Process

  1. Identify the type of change (feature, fix, refactor, infra).
  2. Extract the user-visible impact, not just code mechanics.
  3. Draft summary → changes → test steps → risk.
  4. If the diff implies a breaking change, surface it prominently.
  5. Output the full markdown, ready to paste into the PR body.

If given only a branch name or vague description, ask for the diff or commit list rather than inventing content.

What ships with it: 1 file

1.2 KB alongside SKILL.md

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.