# Summarize Changes

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

- Skill: `n1ddeh/summarize-changes` (Agent Skill)
- Install (CLI): `npx skillmds@latest add n1ddeh/summarize-changes`
- Raw SKILL.md: https://api.skillmd.com/api/skills/n1ddeh/summarize-changes/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: n1ddeh (https://skillmd.com/u/n1ddeh)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/n1ddeh/summarize-changes

---


# 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

```markdown
### 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.