summarize-changes

name: summarize-changes description: Summarize uncommitted changes or recent commits for PR preparation. Use when asked to summarize changes, prepare a PR description, review what changed, or generate a summary of work done.

PR Summary

Summarize changes in the working directory for PR preparation.

Process

1. Determine what to summarize:

   • Run: git status --short
   • If output is non-empty: Summarize uncommitted changes with git diff HEAD
   • If output is empty: Summarize the last commit with git diff HEAD~1 HEAD and note which commit (git log -1 --oneline --no-walk)
   • If the last commit is automated (version bumps, CI-generated commits like "publish v1.3.1756 [skip ci]", dependency updates), review the last non-automated commit instead
   • If on a feature branch: Use git diff main...HEAD to summarize all branch changes against the target branch

2. Handle large diffs:

   • If the diff exceeds ~500 lines, summarize by file or module rather than reading everything line-by-line
   • Focus on the most significant changes and group related files together
   • Note "and X other minor changes" for trivial modifications

3. For non-trivial changes, read surrounding context:

   • Open modified files to understand what the code does, not just what changed
   • Check related types, constants, or config files referenced in the diff
   • Limit exploration to the same module/directory unless changes are cross-cutting

4. Analyze the changes and produce the output below.

Output Format

### Summary

[1-3 sentences explaining what this change accomplishes and why. Write for a technical reviewer who has context on the project but hasn't seen this specific task.]

### Changes

**Added**
- `src/path/NewFile.tsx` - Brief description of purpose

**Modified**
- `src/path/ExistingFile.tsx` - What changed and why

**Renamed/Moved**
- `src/old/path.tsx` → `src/new/path.tsx` - Why it was moved

**Deleted**
- `src/path/OldFile.tsx` - Why it was removed

### Implementation Notes

[Optional section. Include only if there are notable details:]
- New dependencies added
- Feature flags introduced (name and how to enable)
- Database/schema changes
- Environment variables added
- Non-obvious architectural decisions

### QA Steps

1. [Specific step to verify the change works]
2. [Another step if applicable]
3. ...

For feature-flagged changes, include:
- Flag name: `FLAG_NAME`
- How to enable: [instructions]

For bug fixes, include:
- How to reproduce the original bug
- How to verify it's fixed

Guidelines

• Be concise: Reviewers skim. Lead with the most important information.
• Be specific: "Fixed bug" → "Fixed null pointer when user has no profile photo"
• Group logically: If 5 files changed for one reason, describe the reason once, not per-file.
• Skip empty sections: If nothing was deleted, omit the "Deleted" section entirely.
• Never use tables in the output.

Special Cases

• Visual/UI changes: Remind the user to capture before/after screenshots for the PR.
• API changes: List affected endpoints and any breaking changes to request/response shape.
• Refactors with no behavior change: State this explicitly so reviewers know not to look for functional differences.
• Database migrations: Note if migrations need to be run and any data considerations.