pull-request

Format pull request titles, bodies, and change summaries to repository guidelines.

Updated Mar 2, 2026
One-click install
npx skills add https://github.com/alexmensch/claude-sdlc-plugins --skill pull-request-alexmensch
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: pull-request
Source: https://github.com/alexmensch/claude-sdlc-plugins/tree/main/plugins/feature-development/skills/pull-request
Command: npx skills add https://github.com/alexmensch/claude-sdlc-plugins --skill pull-request-alexmensch

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Enforces a consistent, reviewer-friendly pull request format so reviewers can quickly understand what changed, why it changed, and how to validate it.

Core Features & Use Cases

  • Title conventions: Use an optional semver prefix for version bumps, keep titles under 70 characters (excluding the prefix), and write in sentence case focused on user-facing changes.
  • Structured body: Optionally include a Requirements GUID line, a Changes table summarizing observable behavioral changes, and a conditional Test plan only when manual testing is required.
  • Review rules: Avoid implementation details and provenance statements, and focus on observable behavior to make reviews efficient and consistent.
  • Use case: Use this when opening feature, bugfix, or release PRs to ensure reviewers can validate changes without ambiguity.

Quick Start

Create a pull request using the project's format: include the optional semver prefix in the title if applicable, add a Requirements GUID line when available, provide a Changes table describing observable behavior, and include a Test plan only when manual testing is required.

Frequently Asked Questions about pull-request

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

FAQPage Schema
How do I format a pull request for clear code review?

Format a pull request by using a sentence-case title under 70 characters, a Changes table for observable behavior, and a conditional Test plan. This standardizes PR content so reviewers can quickly validate what changed and why without ambiguity.

What should be included in a git pull request body?

A git pull request body should optionally include a Requirements GUID line and must provide a Changes table summarizing observable behavioral changes. Include a Test plan only when manual testing is required, avoiding implementation details and provenance statements.

When do I need to add a semver prefix to a pull request title?

Add a semver prefix to a pull request title for version bumps and release PRs. The prefix is optional and excluded from the 70-character limit, which applies to the sentence-case text focused on user-facing changes.

Why avoid implementation details in pull request descriptions?

Avoid implementation details in pull request descriptions to focus on observable behavior, making code review efficient and consistent. Describing how code works internally creates noise; reviewers need clear, observable change descriptions to validate features and bugfixes.

Does this pull request format work for bugfixes and feature branches?

Yes, this pull request format works for feature, bugfix, and release PRs in a Git workflow. It standardizes titles and change summaries across branch types so reviewers can validate observable behavioral changes without ambiguity.

What is the best way to summarize code changes for reviewers?

The best way to summarize code changes is providing a Changes table in the pull request body that describes observable behavioral changes. This structured format lets reviewers quickly understand what changed and how to validate it without reading implementation details.