Change summary
Reusable agent skills for real repository work: review, implementation, release, documentation, and project hygiene.
npx -y skills add bakerstreetco/skills --skill change-summaryAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 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 per-file changes from the current session or a given diff, focusing on file paths and function signatures rather than implementation bodies. Use when asked to recap what just changed, summarize work done in each file, review a big change without reading the full diff, or surface anything weird from recent edits.
SKILL.md
2.3 KB, as published. Nobody here has run it
Change Summary
Use this skill to produce a tight per-file recap of recent work so the reviewer can scan it instead of reading the full diff. The goal is fast signal: which files changed, what function signatures moved, and one line on why. Skip function bodies.
Workflow
- Determine the change scope from the request:
- Current session: uncommitted staged + unstaged + untracked work.
- Recent commits: a commit range or
HEADagainst a base branch. - A supplied diff, patch, or PR.
- List the changed files with their change type (added / modified / deleted / renamed).
- For each modified or added file, extract the public surface that changed: new, changed, or removed function, method, class, type, and exported signatures. Include names, parameters, return types, and exported symbols. Do not paste bodies.
- Add a one-line purpose per file explaining why it was touched.
- Flag anything weird: unexpected files, surprise deletions, renamed public APIs, new dependencies, generated files, or scope creep outside the request.
What to Include
- File path and change type.
- Function, method, class, type, and export signatures that were added, changed, or removed.
- One-line purpose per file.
- A short "Weird / unexpected" callout section when anything stands out.
What to Skip
- Function bodies and implementation logic.
- Full pasted diffs or large code blocks.
- Unchanged files and cosmetic-only noise unless it hides a real change.
Output
Return one block per file, ordered by how much it matters, using this shape:
path/to/file.ts — modified
+ function foo(bar: string): Promise<Result>
~ function baz(): void -> baz(opts?: Opts): void
- function oldHelper(): void
why: add async foo, widen baz opts, drop unused oldHelper
Close with a short "Weird / unexpected" section listing anything that does not match the stated intent, or say "Nothing unexpected" if the change is clean.
Gives 0 of the 12 instructions most note taking skills give
Counted across 686 of the 876 authors here whose files we hold, read 2026-08-06
- include a visual element on every slidein 44 of 686, across 13 files
- use wikilinks for internal vault linksin 35 of 686, across 11 files
- commit to a single visual motif across every slidein 34 of 686, across 9 files
- read pptxgenjs guide before creating presentations from scratchin 30 of 686, across 6 files
- keep 0.5 inch minimum marginsin 30 of 686, across 7 files
- use subagents to visually inspect rendered slidesin 30 of 686, across 6 files
- re-verify affected slides after every fixin 27 of 686, across 5 files
- run content QA checks before declaring successin 26 of 686, across 3 files
- Use Markdown links for external URLs onlyin 26 of 686, across 10 files
- pick a bold topic specific color palettein 24 of 686, across 2 files
- read editing guide before editing existing presentationsin 23 of 686, across 1 file
- use one dominant color across all slidesin 23 of 686, across 1 file
Said here and by no other author read
- determine the change scope from the request
- list changed files with their change type
- extract changed public signatures
- do not paste implementation bodies
- add a one-line purpose per file
- flag anything weird or unexpected
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.