home / skills / laurigates / claude-plugins / github-pr-title

github-pr-title skill

/git-plugin/skills/github-pr-title

This skill crafts PR titles using conventional commits to drive release automation and maintain clear, consistent git history.

npx playbooks add skill laurigates/claude-plugins --skill github-pr-title

Review the files below or copy the command above to add this skill to your agents.

Files (1)
skill.md
4.1 KB
---
model: haiku
created: 2026-01-30
modified: 2026-02-14
reviewed: 2026-02-14
name: github-pr-title
description: |
  Craft PR titles using conventional commits format. Use when creating PRs or
  ensuring consistent PR naming. PR titles MUST follow conventional commits to
  drive release-please automation and maintain consistent git history.
allowed-tools: Bash(git log *), Bash(git diff *), Bash(gh pr *), Read, Grep, Glob, TodoWrite
---

# GitHub PR Title

Craft clear PR titles using conventional commits format.

**CRITICAL:** PR titles must follow conventional commit format. This drives release-please version automation and ensures consistent git history when using squash-and-merge.

## When to Use

| Use this skill when... | Use X instead when... |
|------------------------|----------------------|
| Creating a PR title | Full PR workflow (`git-pr`) |
| Reviewing title format | Issue titles (`github-issue-writing`) |
| Updating existing PR title | Fixing committed messages (see `git-commit`) |

## Format

```
<type>(<scope>): <subject>
```

See [Conventional Commits Standards](../../.claude/rules/conventional-commits.md) for comprehensive format guide.

### Type Selection

| Type | Use Case | Version Bump |
|------|----------|--------------|
| `feat` | New feature | Minor |
| `fix` | Bug fix | Patch |
| `perf` | Performance improvement | Patch |
| `refactor` | Code restructure (no behavior change) | None |
| `docs` | Documentation only | None |
| `test` | Tests | None |
| `build` | Build/deps | None |
| `ci` | CI config | None |
| `chore` | Maintenance | None |

**Decision tree:** Feature → `feat` | Bug → `fix` | Performance → `perf` | Restructure → `refactor` | Docs → `docs` | Everything else → `chore`

### Scope

Optional component identifier. Keeps commits organized:

```
feat(auth): add OAuth support
fix(api): handle null response
docs(readme): update install steps
refactor(core): simplify error handling
```

**Discover repo scopes:**
```bash
gh pr list --state merged -L 30 --json title | jq -r '.[].title' | grep -oE '\([^)]+\)' | sort | uniq -c | sort -rn
```

Or from commits:
```bash
git log --format='%s' -n 50 | grep -oE '\([^)]+\)' | sort | uniq -c | sort -rn
```

### Subject

- **Imperative mood**: "add" not "adds" or "added"
- **Lowercase**: Start with lowercase after colon
- **No period**: Don't end with punctuation
- **Under 50 chars**: Keep concise

**Examples:**

| ❌ Bad | ✅ Good |
|--------|---------|
| `Added login button` | `add login button` |
| `Fixes the bug.` | `fix null pointer in auth` |
| `Update` | `update dependencies` |
| `Resolved Performance Issues` | `improve query performance` |

### Breaking Changes

Append `!` before colon:

```
feat(api)!: remove deprecated endpoints
fix!: require Node.js 18+
refactor(db)!: change schema format
```

Breaking changes trigger major version bumps.

### Reverts

```
revert: feat(auth): add OAuth support
```

## Quick Reference

| Scenario | Template |
|----------|----------|
| Feature | `feat(<scope>): add <what>` |
| Bug fix | `fix(<scope>): resolve <what>` |
| Performance | `perf(<scope>): optimize <what>` |
| Docs | `docs(<scope>): update <what>` |
| Refactor | `refactor(<scope>): simplify <what>` |
| Deps | `build(deps): bump <pkg> to <ver>` |
| Breaking | `feat(<scope>)!: change <what>` |

## Why This Matters

**Conventional commit PR titles ensure:**

1. **Accurate automation** - release-please reads PR titles to determine version bumps
2. **Clean git history** - squash-and-merge uses PR title as commit message
3. **Searchable commits** - type prefix makes filtering easy
4. **CHANGELOG accuracy** - commits are grouped by type in generated changelogs

## Agentic Optimizations

| Context | Command |
|---------|---------|
| Get commits | `git log main..HEAD --format='%s' -n 10` |
| Changed dirs | `git diff main..HEAD --name-only \| xargs dirname \| sort -u` |
| Update title | `gh pr edit N --title "new title"` |
| Discover scopes | `gh pr list --state merged -L 30 --json title \| jq -r '.[].title' \| grep -oE '\([^)]+\)' \| sort \| uniq` |

## Reference

For detailed rules, patterns, and troubleshooting, see [Conventional Commits Standards](../../.claude/rules/conventional-commits.md).

Overview

This skill crafts clear GitHub PR titles using the Conventional Commits format to drive release automation and keep a consistent git history. It enforces type/scope/subject structure so squash-and-merge results and changelogs are predictable. Use it whenever you create or rename pull request titles to ensure automation like release-please works correctly.

How this skill works

The skill inspects the proposed PR title and formats or validates it as <type>(<scope>): <subject>, recommending an appropriate type (feat, fix, perf, etc.), optional scope, and an imperative, lowercase subject under 50 characters. It flags breaking changes, reverts, and offers commands to discover repo scopes, preview recent commit subjects, or update an existing PR title via the GitHub CLI.

When to use it

  • When creating a new pull request and you need a title that drives release automation
  • When reviewing or standardizing existing PR titles before merging
  • When renaming a PR to reflect a conventional-commits change
  • When preparing a squash-and-merge so the final commit message is structured
  • When you want consistent changelog grouping and searchable commit history

Best practices

  • Choose the correct type: feature→feat, bug→fix, performance→perf, restructure→refactor, docs→docs
  • Include an optional scope that identifies the affected component (e.g., feat(auth): ...)
  • Write the subject in imperative mood, lowercase, no trailing period, and keep it under ~50 chars
  • Mark breaking changes with a ! before the colon (e.g., feat(api)!: remove endpoint)
  • Use provided shell commands to discover common scopes and to update titles via gh

Example use cases

  • Create a new feature PR: feat(ui): add responsive header
  • Fix a bug and ensure patch bump: fix(api): handle null response
  • Document a change: docs(readme): update install instructions
  • Declare a breaking API change: feat(auth)!: remove legacy token flow
  • Rename an existing PR using GitHub CLI: gh pr edit 123 --title "fix(cli): handle empty args"

FAQ

What if my change touches multiple components?

Pick the most relevant scope or omit scope and use a concise subject; aim for a single clear focus per PR when possible.

How do breaking changes affect versioning?

A title with ! before the colon signals a breaking change and triggers a major version bump in release automation.