reviewing-pr-description

Evaluates pull request titles and descriptions for readability and proposes concrete rewrites.

45.7k|4.4k|Updated Aug 24, 2019
One-click install
npx skills add https://github.com/streamlit/streamlit --skill reviewing-pr-description
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: reviewing-pr-description
Source: https://github.com/streamlit/streamlit/tree/main/.claude/skills/reviewing-pr-description
Command: npx skills add https://github.com/streamlit/streamlit --skill reviewing-pr-description

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Pull request titles and descriptions often bury the actual change under context, restate the diff, or use jargon that reviewers cannot parse, making code review slower and the commit history less useful. This Skill evaluates PR prose against readability principles and produces concrete proposed rewrites.

Core Features & Use Cases

  • Readability Evaluation: Checks whether the title stands alone, the description leads with the change and its purpose, and non-obvious decisions explain the why.
  • Concrete Rewrites: Produces findings paired with specific proposed rewrites for the title and description, without applying them automatically.
  • Light Format Check: Secondarily confirms the title follows the [type] Description pattern within ~63 characters and required template sections are present.
  • Use Case: Before requesting review on a PR, run this Skill to catch vague titles like "[fix] Fix the bug" and descriptions that narrate the diff instead of explaining intent.

Quick Start

Review the title and description of PR number 123 for readability and suggest improved wording.

Frequently Asked Questions about reviewing-pr-description

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a pull request description for readability?

Fetch the PR title and body with gh pr view, then check whether the title stands alone, the description leads with the change and its purpose, and non-obvious decisions explain why. Flag jargon, passive voice, meta-commentary, and bullets that merely restate the diff.

What makes a good pull request title?

A good PR title conveys the change on its own in a commit list or changelog, without needing the body for context. It should follow the [type] Description pattern, stay within roughly 63 characters, use active voice, and name the actor.

Does this Skill edit the PR description automatically?

No, it only evaluates and produces findings with concrete proposed rewrites. The caller decides whether to apply the rewrites to the PR or present them as feedback to the author.

When should I use reviewing-readability instead of PR description review?

Use reviewing-readability for code comments, docstrings, and naming inside the codebase. Use the PR description review only for the PR title and description prose that reviewers and changelog readers see.

What common PR description problems should reviewers flag?

Flag titles that only make sense with the body, descriptions opening with context instead of the change, bullets restating the diff, unexplained deprecations or trade-offs, undefined acronyms, passive phrasing, and meta-commentary like "This PR...".