home / skills / toilahuongg / shopify-agents-kit / git-pr
This skill builds a comprehensive PR description from branch changes, helping you document intent and impact when opening reviews.
npx playbooks add skill toilahuongg/shopify-agents-kit --skill git-prReview the files below or copy the command above to add this skill to your agents.
---
name: git-pr
description: Generate a pull request description from branch changes. Use when creating a PR or preparing PR documentation.
disable-model-invocation: true
allowed-tools: Bash(git:*), Bash(gh:*)
---
# Generate PR Description
Create a comprehensive pull request description based on the branch diff.
## Process
### 1. Gather Context
```bash
# Get current branch name
git branch --show-current
# Find base branch (usually main or master)
git remote show origin | grep 'HEAD branch'
# Get all commits on this branch
git log main..HEAD --oneline
# Get the full diff
git diff main...HEAD --stat
git diff main...HEAD
```
### 2. Analyze Changes
Categorize the changes:
- **Features**: New functionality
- **Fixes**: Bug fixes
- **Refactors**: Code improvements without behavior change
- **Docs**: Documentation updates
- **Tests**: Test additions/changes
- **Chores**: Dependencies, configs, tooling
### 3. Generate PR Description
Use this format:
```markdown
## Summary
[2-3 sentences describing what this PR does and why]
## Changes
- [Bullet point for each logical change]
- [Group related file changes together]
- [Focus on what changed, not how]
## Type of Change
- [ ] Bug fix (non-breaking change that fixes an issue)
- [ ] New feature (non-breaking change that adds functionality)
- [ ] Breaking change (fix or feature that causes existing functionality to change)
- [ ] Refactor (no functional changes)
- [ ] Documentation update
## Testing
[How was this tested? What should reviewers verify?]
- [ ] Unit tests pass
- [ ] Integration tests pass
- [ ] Manual testing completed
## Screenshots (if applicable)
[Add screenshots for UI changes]
## Checklist
- [ ] My code follows the project's style guidelines
- [ ] I have performed a self-review
- [ ] I have added tests that prove my fix/feature works
- [ ] New and existing unit tests pass locally
- [ ] Any dependent changes have been merged
---
Generated with Claude Code
```
### 4. Determine Title
PR title format: `type(scope): description`
Examples:
- `feat(auth): add OAuth2 login support`
- `fix(api): handle null response from payment service`
- `refactor(db): extract query builder into separate module`
### 5. Output
Provide:
1. Suggested PR title
2. Full PR description in markdown
3. Suggested reviewers (if CODEOWNERS exists)
4. Labels to add (if .github/labels.yml exists)
### 6. Create PR (Optional)
If user confirms, create the PR:
```bash
gh pr create --title "..." --body "..."
```
## Guidelines
- Focus on **why** over **what** (the diff shows what)
- Link to related issues: `Fixes #123` or `Relates to #456`
- Call out breaking changes prominently
- Mention any manual steps required post-merge
- Keep bullet points scannable (one line each)
This skill generates a clear, reviewer-friendly pull request description from the branch diff and commit history. It suggests a standardized title, organizes changes into logical categories, and produces a ready-to-paste markdown body for PR creation. Use it to save time and make reviews faster and more consistent.
The skill inspects the current branch name, commit list, and the unified diff against the base branch to summarize what changed. It categorizes edits into features, fixes, refactors, docs, tests, and chores, then composes a summary, change list, testing notes, checklist, and optional screenshots section. It can also suggest a conventional PR title and metadata like reviewers and labels based on the repository context.
Can this produce a PR title automatically?
Yes. It suggests a title using the format type(scope): description based on commits and changed files.
Will it detect breaking changes?
It flags potential breaking changes if the diff touches public interfaces or explicitly notes behavior changes; confirm manually before merging.