pr

name	pr
description	Creates pull requests with proper formatting. Use when creating PRs, opening pull requests, or preparing changes for review.

Pull Requests

PR Title

Use Conventional Commit format, same as commit messages:

<type>(<scope>): <description>

Types

• feat: User-facing features or behavior changes (must change production code)
• fix: Bug fixes (must change production code)
• docs: Documentation only
• style: Code style/formatting (no logic changes)
• refactor: Code restructuring without behavior change
• test: Adding or updating tests
• chore: CI/CD, tooling, dependency bumps, configs (no production code)

PR Description Template

## Summary

One sentence describing the overall change.

- Optional supporting details
- If needed

## Test plan

- [ ] How to verify it works

Labels

Apply labels using gh pr create --label <label> or gh pr edit --add-label <label>.

Apply all labels that fit. Only use these labels:

• enhancement - User-facing features or improvements (must change production code behavior)
• refactor - Production code changes that don't alter behavior
• bug - Fixes broken production code functionality
• test - Changes to tests
• documentation - Documentation changes

No label needed for dependency bumps, CI/CD, tooling, or infrastructure changes - these go in "Other Changes" in release notes.

Branch Naming

Use type/short-description:

feat/user-login-flow
fix/csrf-token-handling
chore/ci-pipeline

Instructions

1. Run git log main..HEAD to see commits for this branch
2. Run git diff main...HEAD to see all changes
3. Summarize the changes in 1-2 sentences. Adhere to "title and body quality" below.
4. Create a test plan with verification steps
5. Apply appropriate labels
6. Once submitted, give the user a CLICKABLE hyperlink to the PR

PR title and body quality

No references to plan docs. Neither plans in /docs/plans/ nor ~/.claude/plans/. Future readers of PR history will not have access to these. Instead, describe the actual change or goal or idea.

No planning ephemera — phase/step labels like "PRE3", "REF1", "POST2", "phase", "step N". These are scaffolding from plan docs, not durable facts about the code. Those labels mean nothing to a future reader of PR history; they age out the moment the plan is done. Instead, describe the actual change.