pr-description

Update a GitHub pull request description based on the changes in the PR.

Arguments

/pr-description <PR_NUMBER> [--fixes <ISSUE_NUMBERS>]

• •PR_NUMBER (required): The pull request number to update
• •--fixes (optional): Comma-separated issue numbers that this PR fixes (e.g., --fixes 123,456)

Examples:

• •/pr-description 3534
• •/pr-description 3534 --fixes 123
• •/pr-description 3534 --fixes 123,456,789

Instructions

1. •

   First, gather information about the PR:

   • •Use GitHub plugin to get PR details (title, current description, base branch)
   • •Use local git to get commits: git log main..HEAD --oneline
   • •Use local git to get the diff: git diff main..HEAD
   • •Parse any --fixes argument for issue numbers
2. •

   Check the existing PR description:

   • •If it already has a complete, accurate description that reflects the changes, do nothing
   • •If it's missing sections, incomplete, or outdated compared to the actual changes, proceed to update
   • •If it only has the template placeholder text, generate a full description
3. •

   Analyze the changes:

   • •Understand the purpose of each commit
   • •Identify any breaking changes (API changes, removed features, behavior changes)
   • •Look for new features, bug fixes, refactoring, or documentation changes
   • •Collect issue numbers from:
     • •The --fixes argument (if provided)
     • •Commit messages (patterns like "Fixes #123", "Closes #456", "Resolves #789")
4. •

   Generate or update the PR description with these sections:

PR Description Format

Summary (always include)

Brief bullet points describing what changed and why. Focus on the purpose and impact, not implementation details.

## Summary

- Added X to enable Y
- Fixed bug where Z would happen
- Refactored W for better maintainability

Breaking Changes (include only if applicable)

Document any changes that affect existing users or APIs.

## Breaking Changes

- `ClassName.method()` now requires a `param` argument
- Removed deprecated `old_function()` - use `new_function()` instead

Testing (include when non-obvious)

How to verify the changes work. Skip for trivial changes.

## Testing

- Run `uv run pytest tests/test_feature.py` to verify the fix
- Example usage: `uv run examples/new_feature.py`

Fixes (include if issues are provided or found in commits)

List issues this PR fixes. GitHub will automatically close these issues when the PR is merged.

## Fixes

- Fixes #123
- Fixes #456

Note: Use "Fixes #X" format (not "Closes" or "Resolves") for consistency. Each issue should be on its own line with "Fixes" to ensure GitHub auto-closes them.

Guidelines

• •Be concise - Reviewers should understand the PR in 30 seconds
• •Focus on why - The diff shows what changed, explain why
• •Skip empty sections - Only include sections that have content
• •Use bullet points - Easier to scan than paragraphs
• •Don't duplicate the diff - Avoid listing every file or line changed

Example Output

## Summary

- Added `/docstring` skill for documenting Python modules with Google-style docstrings
- Skill finds classes by name and handles conflicts when multiple matches exist
- Skips already-documented code to avoid unnecessary changes

## Testing

/docstring ClassName

## Fixes

- Fixes #123

Checklist

Before updating the PR:

• • Verified existing description needs updating (not already complete)
• • Summary accurately reflects the changes
• • Breaking changes are clearly documented (if any)
• • No unnecessary sections included
• • Description is concise and scannable