| name | ring:generating-pr-descriptions |
| description | Generating pull request descriptions from git branch changes with automatic title generation, change-type detection, and smart analysis. Uses branch-only scope to avoid full history analysis. Use when preparing a PR for review. Skip when the PR is a single trivial commit or description already exists. |
| user-invocable | true |
| argument-hint | [base-branch] |
Generating PR Descriptions
When to use
- Preparing a pull request for review and need a comprehensive description
- Generating a PR title automatically from commit message analysis
- Classifying the type of change (bug fix, feature, breaking change)
- Saving a reusable PR description to
docs/pr-descriptions/<branch-name-with-hyphens>.md
Skip when
- The PR is a single trivial commit with an obvious description
- A PR description already exists and does not need regeneration
- The branch has no commits beyond the base branch
Process
1. Git Branch Analysis - CRITICAL: Branch-Only Scope
- MANDATORY: Identify actual branch point to avoid analyzing entire development history
- Detect the base branch (develop, main, master) that the current branch was created from
- CORRECT APPROACH: Use
git merge-base HEAD <base-branch> to find the true divergence point
- CORRECT APPROACH: Use
git log --oneline $(git merge-base HEAD <base-branch>)..HEAD for branch-specific commits
- CORRECT APPROACH: Use
git diff $(git merge-base HEAD <base-branch>)..HEAD for branch-specific changes
- NEVER rely on manual
HEAD~n counting — it breaks on merges, rebases, and long-lived branches
- Run
git status --porcelain to identify uncommitted files (excluded from PR)
- Enforce that PR analyzes ONLY commits made on the current feature branch, not development history
- Determine if this is a bug fix, feature, or breaking change based on actual branch commits
2. Change Classification
- Analyze file patterns and change types
- Identify the type of change (bug fix, new feature, breaking change, etc.)
- Detect if documentation updates are needed
- Determine testing requirements
3. PR Description Generation
- Create comprehensive description following the template format
- Include summary of changes and motivation based on ONLY branch-specific commits
- Pre-fill appropriate checkboxes based on change analysis
- Suggest testing strategies
- Derive the output filename from the full branch name with slashes replaced by hyphens (e.g.,
feature/FE-157 -> feature-FE-157.md)
- Save to
docs/pr-descriptions/<derived-filename> (create directory if needed)
CRITICAL Implementation Steps
Step 1: Branch Analysis (MANDATORY)
git log --oneline --decorate --graph -10
Step 2: Extract Branch-Only Changes (MANDATORY)
git log --oneline HEAD~2..HEAD
git diff HEAD~2..HEAD --name-status
git diff HEAD~2..HEAD --stat
Step 3: Validation (MANDATORY)
- Verify commit count matches actual branch commits
- Ensure no base branch commits are included in analysis
- Confirm file changes align with branch purpose
WRONG APPROACH - DO NOT USE:
git log main..HEAD
git diff main...HEAD
Generated Template Structure
The skill generates pull requests following this exact structure:
# [Auto-generated PR title: short, under 70 chars, using conventional commit prefix]
# Description
[Auto-generated summary of changes and motivation based on commits]
## Type of change
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] This change requires a documentation update
PR Title Generation
- Auto-generated from commit message analysis
- Uses conventional commit prefix (
feat:, fix:, chore:, refactor:, etc.) based on the dominant change type
- Kept under 70 characters, concise and descriptive
- Placed as the first
# heading in the output file
Change Type Detection
- Bug fix: Detects fixes, corrections, and patches in commit messages
- New feature: Identifies new functionality, components, or capabilities
- Breaking change: Flags API changes, removed functionality, or incompatible changes
- Documentation update: Detects changes to .md files, comments, or docs folders
Implementation Requirements - CRITICAL
MANDATORY Git Command Usage:
-
Branch Point Detection:
git log --oneline --decorate --graph -10
-
Branch-Only Analysis Commands:
git log --oneline HEAD~2..HEAD
git diff HEAD~2..HEAD --name-status
git diff HEAD~2..HEAD --stat
git log main..HEAD
git diff main...HEAD
-
Branch Point Validation:
- If branch has 3 commits: use
HEAD~3..HEAD
- If branch has 5 commits: use
HEAD~5..HEAD
- Always verify commit count matches actual branch commits
Smart Analysis Features
- File Pattern Recognition: Detects frontend/backend changes, test files, config changes
- Commit Message Analysis: Uses conventional commits to determine change types
- Dependency Detection: Identifies if package.json or similar files changed
- Test Coverage: Suggests appropriate testing based on changed components
Notes
- Critical: Uses
HEAD~n..HEAD approach to analyze ONLY current branch commits
- Branch Validation: Verifies number of commits on branch before analysis
- Feature Branch Scope: Analyzes only commits made specifically on the current feature branch
- Committed Changes Only: Analyzes committed changes in the branch only, ignores uncommitted files
- Precise Scope: Prevents inclusion of entire development history in PR description
- Generated PRs reflect actual feature branch changes, not cumulative project history
- Breaking changes are flagged based on actual branch commits only
- Generated PR descriptions are saved to
docs/pr-descriptions/<branch-name-with-hyphens>.md for easy copying to GitHub/GitLab