ahgraber/changelog
skills/changelog/SKILL.md
Use when writing, updating, or generating a CHANGELOG.md — for a new release, an unreleased section update, or drafting from git history or diff. Triggers: "update the changelog", "write release notes", "what changed since X", "generate changelog for v1.2.0", "add this to the changelog", "draft unreleased section". Not for commit messages (use commit-message skill) or internal deployment runbooks.
$ install --global
skillsauthnpx skillsauth add ahgraber/skills changelogInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: May 3, 2026, 3:44 AM145.5s3 files scanned
SKILL.md
- name:
- changelog
- description:
- |-
- Use when writing, updating, or generating a CHANGELOG.md — for a new release, an unreleased section update, or drafting from git history or diff. Triggers:
- update the changelog", "write release notes", "what changed since X", "generate changelog for v1.2.0", "add this to the changelog", "draft unreleased section". Not for commit messages (use commit-message skill) or internal deployment runbooks.
Changelog
Draft or update a CHANGELOG.md following Keep a Changelog conventions.
Invocation Notice
Inform the user when this skill is being invoked by name: changelog.
When to Use
- Writing or updating
CHANGELOG.mdfor an upcoming or recent release - Drafting or appending to an
[Unreleased]section from recent merged work - Generating a changelog from git history, a commit range, or a diff
- Editing or cleaning up an auto-generated changelog draft
When Not to Use
- Writing a git commit message — use
commit-messageskill - Writing internal release notes or deployment runbooks (audience is operators, not users)
- Full code review — use
code-reviewskill
Workflow
1. Determine scope
Infer target version, release date, and commit range from context. Ask only if neither the version nor the range can be determined.
- Default range:
git log <previous-tag>..HEAD --oneline --no-merges - If no prior tag exists:
git log --oneline --no-merges - If updating
[Unreleased]only: use commits since last tagged release
Check for an existing [Unreleased] section in CHANGELOG.md — do not duplicate entries already there.
2. Collect commits
git log <range> --oneline --no-merges
Also read the existing CHANGELOG.md to understand document structure and last version.
3. Filter noise
Exclude commits with no user-visible effect.
Retain only what matters to users.
See references/entry-guidelines.md for the full include/exclude list.
Quick exclusion rule: if a user reading the changelog would not care, cut it.
4. Categorize
Map surviving entries to Keep a Changelog categories (in display order):
| Category | When to use | | -------------------- | -------------------------------------------------------------- | | Breaking Changes | Any change requiring user action — config, API, CLI, behavior | | Added | New features, commands, endpoints, options | | Changed | Modified behavior, performance improvements, visible refactors | | Deprecated | Things that still work but will be removed | | Removed | Deleted features, commands, options | | Fixed | Bug fixes | | Security | Vulnerability patches |
Breaking changes get their own subsection at the top of the version block.
See references/entry-guidelines.md for the Conventional Commits → category mapping.
5. Write entries
- One entry per logical user-visible outcome — consolidate multi-commit features into one line
- Imperative present tense:
Add X,Fix Y,Remove Z - For breaking changes: state what broke AND the migration path (e.g.,
Remove X — replace with Y; see docs/migration.md) - One reference link per entry; prefer PR over commit hash over issue number
- Do not include implementation details, commit hashes in entry text, or "WIP" notes
6. Insert into CHANGELOG.md
See references/changelog-format.md for the exact block structure and version comparison link format.
New release (no [Unreleased] section): insert ## [x.y.z] - YYYY-MM-DD block at the top of the file.
New release (existing [Unreleased] section):
- If
[Unreleased]IS the release being cut: replace## [Unreleased]with## [x.y.z] - YYYY-MM-DD; add a fresh empty## [Unreleased]above it. - If
[Unreleased]contains unrelated upcoming work: insert the new versioned block between[Unreleased]and the previous version.
Updating [Unreleased] only: append entries under the matching category subsection; create the subsection if absent.
Add or update the version comparison link at the bottom of the file.
7. Verify before delivering
- [ ] Version bump is semantically correct: breaking → major, new feature → minor, fix → patch
- [ ] No CI/CD, formatting, test-only, or dev-tooling entries present
- [ ] Breaking changes include a migration path
- [ ] Date is ISO 8601 (
YYYY-MM-DD) - [ ] No duplicate entries from the existing
[Unreleased]section
Output
An updated CHANGELOG.md with the new version block inserted (or [Unreleased] section updated), ready for user review before commit.
References
references/entry-guidelines.md— include/exclude heuristics and Conventional Commits mappingreferences/changelog-format.md— full Keep a Changelog format rules and examples
Related Skills
ahgraber/editorial-review
development
VerifiedTrustedCommunity
Use when the user wants rigorous, non-sycophantic editorial feedback on a draft, essay, blog post, or argument through back-and-forth dialogue — pressure-testing thesis, structure, argument, clarity, tone, and evidence. Triggers: "be my sparring partner", "pressure-test this draft", "poke holes in my argument", "is this ready to publish", "sharpen this post", "where is this weak". Not for one-shot copyediting, proofreading, or ghostwriting.
2SKILL.mdUpdated May 26, 2026
ahgraber/synthesize
testing
VerifiedTrustedCommunity
Use when distilling the through-line gist of one or more sources — the spine, argument, tension, or recurring frame running through a set of documents, notes, research, or transcripts, OR across the ideas within a single rich piece — into a few concise paragraphs. Triggers: "synthesize", "what's the through-line/gist", "extract the insight", "pull these together". Not for faithful summary or condensation that covers what a source says, nor for comparisons or catalogs where enumeration is the deliverable.
2SKILL.mdUpdated May 22, 2026
ahgraber/writing-tests
development
VerifiedTrustedCommunity
Use when writing or reviewing tests in any language, or diagnosing a suite that is slow, brittle, or hard to read. Triggers: "write tests", "how should I test this", "what kind of test", "test is flaky/fragile", "should I mock this", "test is hard to read". For Python-specific guidance see `python-testing`.
2SKILL.mdUpdated May 16, 2026
ahgraber/strudel
development
VerifiedTrustedCommunity
Use when writing, debugging, or explaining Strudel live-coding music patterns — mini-notation syntax, pattern functions (fast/slow/every/off/stack), synth/sample selection, audio effects, scale/chord/voicing API, or EDM production recipes. Triggers: "write a Strudel pattern", "how do I make a bassline in Strudel", "what does .every() do", "strudel drum beat", "strudel chord voicing", any Strudel code question.
2SKILL.mdUpdated May 16, 2026