Agent-Skills.md

Agent Skills: Comprehensive PR Description Creator

Creates comprehensive PR descriptions by systematically reviewing ALL changes - features, bug fixes, tests, docs, and infrastructure. Use when user asks to "update the PR", "prepare PR for review", "write PR description", or "document branch changes". Requires gh CLI.

UncategorizedID: propstreet/claude-powerpack/update-pr

Repository

propstreet/claude-powerpack
propstreetLicense: MIT
2

Install this agent skill to your local

pnpm dlx add-skill https://github.com/propstreet/claude-powerpack/tree/HEAD/skills/update-pr

Skill Files

Browse the full folder contents for update-pr.

Download Skill

Loading file tree…

skills/update-pr/SKILL.md

Skill Metadata

Name
update-pr
Description
Creates comprehensive PR descriptions by systematically reviewing ALL changes - features, bug fixes, tests, docs, and infrastructure. Use when user asks to "update the PR", "prepare PR for review", "write PR description", or "document branch changes". Requires gh CLI.

Comprehensive PR Description Creator

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

Phase 1: Complete Change Inventory

Determine the PR's base branch, then review the full diff, changed files, and all commits since branching.

NEVER assume you know what's in the PR based on branch name or first glance. PRs often contain secondary bug fixes, performance optimizations, test infrastructure improvements, documentation updates, dependency changes, and configuration adjustments alongside the main feature.

Phase 2: Categorize Changes

Using the diff output, create a categorized inventory of EVERY changed file:

| Category | What to look for | |----------|-----------------| | Core application | New methods, refactoring, bug fixes, performance improvements | | Bug fixes | Scan commit messages for "fix", "bug", "correct", "resolve" | | Infrastructure | Interceptors, middleware, base classes, test fixtures | | Configuration | Config files, constants, environment settings, package files | | Tests | New test files vs modified, test patterns, coverage improvements | | Documentation | README, docs folders, inline documentation | | Build & tooling | package.json, build configs, CI/CD, scripts | | UI/Frontend | Components, styles, state management |

For each commit, identify the category (feature, bugfix, test, docs, refactor, perf, chore) and understand WHY the change was made, not just WHAT changed.

Phase 3: Write Comprehensive Summary

Structure the PR description to cover all categories:

## Summary

[One sentence covering the MAIN change, plus brief mention of other significant improvements]

## User Impact

**[Main Feature Category]:**
- [Specific user-facing improvements]

**[Secondary Categories if applicable — e.g., Reliability, Performance]:**
- [Bug fixes with impact]
- [Performance improvements]

## Technical Notes

### 1. [Main Feature Name]
[Detailed explanation with file references]

### 2. [Bug Fixes / Corrections]
[Each bug fix: location, what was wrong, impact, fix]

### 3. [Infrastructure / Performance]
[Test improvements, framework changes, optimizations]

### 4. [Configuration & Dependencies]
[Constants, config changes, dependency updates]

### 5. [Documentation]
[README updates, new docs, removed obsolete content]

## Testing

[Comprehensive test results with specific numbers]

## Implementation Approach

[List ALL commits with brief explanation of each]

---

Generated with [Claude Code](https://claude.com/claude-code)

Phase 4: Update the PR

Show the summary to the user and ask if they want to update the PR. Only update with gh pr edit after approval.

Quality Checklist

Before finalizing, verify:

  • Completeness: Every commit is represented in the summary
  • Accuracy: All bug fixes are documented with impact
  • Context: WHY changes were made, not just WHAT changed
  • Organization: Changes grouped logically
  • Specificity: File paths for critical changes
  • Impact: User-facing vs internal changes clearly separated
  • Testing: Actual test results reported, not assumptions

Gotchas

  • PRs often contain a week's worth of work across multiple areas. The biggest mistake is focusing only on the main feature and skipping "small" changes like constants, config, docs, and especially bug fixes.
  • If no PR exists yet, create one first before running the update process.
  • Shell constructs like $(), &&, and variable assignments in Bash calls can trigger permission prompts. Prefer simple, single-command calls when possible.