update-pr

# Comprehensive PR Description Creator

Create thorough PR descriptions that document EVERY meaningful change, not just the headline feature.

## Critical Rule: Complete Coverage

**NEVER assume you know what's in the PR based on branch name or first glance.**

PRs often contain:
- Main feature work
- Bug fixes discovered during development
- Performance optimizations
- Test infrastructure improvements
- Documentation updates
- Dependency changes
- Configuration adjustments

You MUST systematically review ALL changes and include them in the summary.

## Phase 1: Complete Change Inventory

First, determine the base branch for comparison. Run these commands separately:

**Step 1: Try to get base branch from PR:**
```bash
gh pr view --json baseRefName -q '.baseRefName' 2>/dev/null
```

**Step 2: If no PR exists (empty output above), get the default branch:**
```bash
git rev-parse --abbrev-ref origin/HEAD 2>/dev/null | sed 's#origin/##' || echo 'main'
```

Use the result as `BASE_BRANCH` for the commands below.

Then gather context. These commands are independent and can be run as separate tool calls:

**PR and working tree status:**
```bash
gh pr status
```

```bash
git status --short
```

**Changed files:**
```bash
git diff origin/$BASE_BRANCH...HEAD --stat
git diff origin/$BASE_BRANCH...HEAD --name-status
```

**Commit history:**
```bash
git log origin/$BASE_BRANCH..HEAD --oneline --no-merges
```

**Note**: Using the PR's actual base branch ensures accurate diffs for release backports or PRs targeting non-default branches.

## Phase 2: Systematic File Analysis

Using the `--name-status` output, create a categorized inventory of EVERY changed file:

### 2.1 Core Application Changes
- Check files matching your framework patterns (e.g., `*Service*`, `*Controller*`, `*Component*`)
- Look for: new methods, refactoring, bug fixes, performance improvements
- Read key diffs to understand WHAT changed and WHY

### 2.2 Bug Fixes & Corrections
- Scan commit messages for: "fix",