Summarize changes
A collection of Claude Code skills for PR workflows, code review, and project management — with personality.
npx -y skills add n1ddeh/fantastic-skills --skill summarize-changesAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.md
3.3 KB, 735 tokens by cl100k_base, as published. Nobody here has run it
PR Summary
Summarize changes in the working directory for PR preparation.
Process
-
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 HEADand 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...HEADto summarize all branch changes against the target branch
- Run:
-
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
-
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
-
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.