/generating-pr-descriptions

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)

# 1. Get branch structure to identify commits
git log --oneline --decorate --graph -10

# 2. Count commits unique to current branch
# Look for where branch diverged from main/develop
# Example output shows 2 commits on feature/PLU-393:
# * 06603bf (HEAD -> feature/PLU-393) fix(i18n): add missing translations
# * d40c631 feat(ui): enhance templates system with calendar filter
# * 30664b1 (develop) Merge branch 'develop' into feature/libs

Step 2: Extract Branch-Only Changes (MANDATORY)

# Use HEAD~n where n = number of branch commits
git log --oneline HEAD~2..HEAD           # Get branch commits
git diff HEAD~2..HEAD --name-status      # Get changed files
git diff HEAD~2..HEAD --stat            # Get change statistics

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      # Includes entire development history
git diff main...HEAD    # Includes all changes since branch creation

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:**

1. **Branch Point Detection:**

   git log --oneline --decorate --graph -10
   # Identify where current branch diverged from base
   # Count commits unique to current branch

2. **Branch-Only Analysis Commands:**

   # For 2 commits on current branch:
   git log --oneline HEAD~2..HEAD
   git diff HEAD~2..HEAD --name-status
   git diff HEAD~2..HEAD --stat

   # NEVER use these (includes all development history):
   git log main..HEAD  # WRONG
   git diff main...HEAD  # WRONG

3. **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