Receber por email
← Voltar para o catálogo

pr-description-writer

Gera uma descrição de pull request clara e estruturada a partir de um git diff, resumo de branch ou lista de commits. Inclui resumo, motivação, mudanças, passos de teste e orientação para o revisor, sendo útil ao documentar alterações de código ou rascunhar um PR.

991estrelas
Atualizado há 4 meses

Ver no GitHub ↗ Licença: MIT

Como adicionar

/plugin marketplace add mohitagw15856/pm-claude-skills

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/pr-description-writer/svg)](https://www.skillteca.com.br/skills/pr-description-writer)

Skills relacionadas

Ver todas de Desenvolvimento →

Alerta por categoria

Receba novas skills de Desenvolvimento toda segunda

1 email curto, só com as skills novas de Desenvolvimento. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

PR Description Writer Skill

Writes structured, reviewer-friendly pull request descriptions from a diff, commit list, or informal notes. Covers the what, why, and how-to-review so reviewers can start immediately.

Required Inputs

Ask for these if not provided:

  • What changed (paste a git diff, git log --oneline, or describe the changes in plain English)
  • Why it was changed (the problem being solved or feature being added)
  • How to test it (any specific steps a reviewer needs to verify it works)
  • Risk level (low / medium / high — affects how much reviewer guidance to include)
  • PR type (feature / bug fix / refactor / dependency upgrade / config change / hotfix)
  • Target branch (e.g. main / develop / release/2.4 — affects risk framing and reviewer guidance)
  • Linked issue or ticket (e.g. JIRA-1234, GitHub #567 — or "none")

Output Format

Title

A clear, imperative-mood title under 72 characters: [type]: [concise description of what changed]

Examples:

  • feat: add rate limiting to the public API
  • fix: resolve race condition in session expiry
  • refactor: extract payment logic into PaymentService

Summary

2–3 sentences covering:

  • What this PR does (the change)
  • Why it was needed (the problem or goal)
  • The approach taken (at a high level)

Changes Made

Bullet list of specific changes — one bullet per logical change, not per file:

  • Added [X] to handle [Y]
  • Refactored [A] to reduce [B]
  • Removed [C] as it was replaced by [D]
  • Updated [E] to fix [F]

Screenshots / Demo

[If UI change: include before/after screenshots or a screen recording] [If API change: include example request/response] [If no visual change and no API contract change: omit this section entirely — do not leave it as a placeholder]

How to Test

Step-by-step instructions a reviewer can follow:

  1. [Setup step if needed]
  2. [Action to take]
  3. [What to verify]
  4. [Edge case to check]

Include any specific commands, test data, or environment flags needed.

Testing Checklist

  • [ ] Unit tests added/updated
  • [ ] Integration tests added/updated
  • [ ] Edge cases covered
  • [ ] Manual testing completed
  • [ ] No regressions in existing tests

Reviewer Notes

Flag anything that warrants extra attention:

  • Areas of uncertainty where a second opinion is welcome
  • Deliberate trade-offs made (and why)
  • Out-of-scope items noticed but not addressed
  • Dependencies on other PRs (link them)

Related

  • Closes #[issue number] (if applicable)
  • Related to #[PR/issue number]

Quality Checks

  • [ ] Title is imperative mood and under 72 characters
  • [ ] Summary explains what AND why (not just what)
  • [ ] Changes list describes logical changes (not file-by-file changes)
  • [ ] Title starts with a valid type prefix (feat / fix / refactor / chore / deps / config / hotfix) and is under 72 characters
  • [ ] Testing steps are reproducible by someone unfamiliar with the code
  • [ ] For high-risk PRs, Reviewer Notes flags at least one specific area of concern or deliberate trade-off; for low-risk PRs, Reviewer Notes is either omitted or kept to one line

Usage Examples

  • "Write a PR description for these changes" + [paste diff or description]
  • "Draft a pull request for [feature]"
  • "I need a PR description — here's what I changed"
  • "Summarise these commits into a PR description"
  • "Write the PR body for this branch"
Compartilhar X LinkedIn