ai-changelog
Skill167 starsChanged 10 days agoApache-2.0View on GitHub
Set up an AI-driven changelog system in any project, code or not. Suitable for both software projects and for non-code projects. Creates a CHANGELOG.md and instructions for agents to log changes. Use when the user wants to add or improve automated changelog management, AI-friendly changelog workflows, version stamping, or set up a changelog system for a new or existing project.
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 4 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 16
Detect the build system: Check for Makefile, Justfile, package.json, Cargo.toml, pyproject.toml, go.mod.
- Distinctive: line 24
If signals are absent or contradictory, ask the user.
- Distinctive: line 39
Apply the scheme reference: follow the build-integration recipe from the chosen reference file.
- Distinctive: line 59
No build system, code project - nothing to stamp.
- Distinctive: line 60
No build system, non-code project - Dated mode: no script, no Makefile
- Very specific: line 72
Run via uv run scripts/version.py stamp or python3 scripts/version.py stamp (no external dependencies).
- Very specific: line 76
Never overwrite existing changelog history: If a CHANGELOG.md exists with content, merge the [Unreleased] structure into it rather than …
- Very specific: line 82
SemVer + auto-CalVer = silent footgun: If a Makefile in a SemVer project calls python3 scripts/version.py stamp without --version, the …
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
AI-Driven Changelog
Set up a changelog system AI agents maintain during development. Two shapes, chosen by project type:
- Software projects: agents write entries under
## [Unreleased]; automation stamps version numbers at release time (CalVer or SemVer). No agent ever writes version numbers; the build process handles that. - Non-code projects (no build system): agents add terse bullets under a date heading (
## YYYY-MM-DD) by hand. No script, no version numbers. Seereferences/dated.md.
Setup workflow
- Detect the build system: Check for Makefile, Justfile, package.json, Cargo.toml, pyproject.toml, go.mod. Note which config files contain a
"version"field. Check whether this is a software project at all. If there's no build system from step 1 and no version convention (a docs repo, writing or notes vault, content site, research or config collection), use Dated mode: date-based changelog headings, no version script, no build integration. Skip straight to
references/dated.mdand ignore the script/build steps below. Otherwise, detect the versioning scheme by inspecting (highest confidence first):CHANGELOG.mdheading style:## [YYYY.M.N]headings → CalVer;## [X.Y.Z]headings or prose mentioning "SemVer" → SemVer- Git tags from
git tag --list | head:vX.Y.Z→ SemVer;YYYY.M.N→ CalVer VERSIONfile with content matching^[0-9]+\.[0-9]+\.[0-9]+→ SemVer- Manifest version field (
package.json,Cargo.toml,pyproject.toml) matchingX.Y.Z→ SemVer
If signals are absent or contradictory, ask the user. Suggest SemVer for projects with established version history (existing tags, manifest versions, prior changelog entries) and CalVer for greenfield projects where automatic versioning is preferable. Each scheme has trade-offs documented in its reference file.
- Read the scheme reference that matches the chosen scheme. It contains the build integration recipes, CLAUDE.md snippet, GitHub Actions pattern, and scheme-specific gotchas:
- CalVer →
references/calver.md - SemVer →
references/semver.md - Dated (non-code projects) →
references/dated.md
- CalVer →
- Ask the user about optional features (CalVer/SemVer only; skip for Dated mode):
- Pinned
## Known Bugssection above## [Unreleased]? (default: yes) - GitHub Actions release workflow integration? (default: skip unless asked)
- Pinned
- Generate or update CHANGELOG.md. For CalVer/SemVer use
references/changelog-template.md; for Dated use the template inreferences/dated.md. If a CHANGELOG.md already exists, do NOT overwrite it; insert the HTML comment and the appropriate structure (## [Unreleased]for CalVer/SemVer, today's date heading for Dated) above existing entries. - Copy
scripts/version.pyfrom this skill into the target project'sscripts/directory. Make it executable (chmod +x). Skip in Dated mode - there is no script. - Apply the scheme reference: follow the build-integration recipe from the chosen reference file. Add targets to the existing build system, or create a minimal Makefile if none exists. Skip in Dated mode - there is no build integration.
- Update CLAUDE.md with the snippet from the chosen scheme reference. Insert into the project's development workflow section, or create one. In Dated mode this is the only mechanism that keeps the changelog current, so make sure the snippet lands. Add "Squash changes within the same day/version (do not add changes to changes)." Keep the snippet's what-to-log and entry-length rules intact - they are what stops agents logging trivia and writing paragraphs for simple changes.
- Verify:
- CalVer:
uv run scripts/version.py versionshould print today's CalVer; thenuv run scripts/version.py stamp --dry-runpreviews the stamp - SemVer:
uv run scripts/version.py stamp --version <current-version> --dry-run --changelog-onlypreviews the stamp without touching the canonical version source - Dated: confirm CHANGELOG.md has today's date heading and the CLAUDE.md snippet is in place; nothing to run
- CalVer:
Project detection
Indicator, then what to stamp and how to integrate:
Makefile- stamp whatever config files the project has; add make targetsJustfile- same config files; add just recipespackage.json- stamppackage.json; add npm scripts, or a MakefileCargo.toml- stampCargo.toml; Makefile wrapperpyproject.toml- stamppyproject.toml; Makefile wrappergo.mod- stampVERSIONif present, otherwise nothing; Makefile wrapperVERSIONfile - stampVERSION; Makefile wrapper- No build system, code project - nothing to stamp; create a minimal Makefile
- No build system, non-code project - Dated mode: no script, no Makefile
How the script works
scripts/version.py subcommands:
version: prints today's CalVer to stdout (CalVer projects only)stamp: replaces## [Unreleased]with## [VERSION] - DATE, re-inserts a fresh## [Unreleased], and stamps version into auto-discovered config files (package.json,Cargo.toml,pyproject.toml,tauri.conf.json,VERSION)
Flags: --version X.Y.Z (required for SemVer; optional override for CalVer), --dry-run, --changelog-only, --no-changelog.
The script is scheme-agnostic. With no --version, it auto-computes CalVer; with --version, it stamps whatever string you give it. Validation lives in the build system, so SemVer recipes always pass --version and reject malformed input before invoking the script. See references/semver.md for why this split matters.
Run via uv run scripts/version.py stamp or python3 scripts/version.py stamp (no external dependencies).
Gotchas
- Never overwrite existing changelog history. If a CHANGELOG.md exists with content, merge the
[Unreleased]structure into it rather than replacing the file. - Empty Unreleased section: stamping is a no-op if
[Unreleased]has no content. This prevents empty version entries. fetch-depth: 0in CI for CalVer: CalVer usesgit rev-list --count HEAD. Shallow clones produce wrong commit counts.- A changelog is not a commit log. Two rules keep it useful, and both must appear in the HTML comment and the CLAUDE.md snippet: log only reader-visible changes (git history covers the rest), and keep entries to one line unless the change is genuinely complex. Without them agents log formatting tweaks and write paragraphs for one-line fixes.
- The HTML comment is the agent's instruction source. The
<!-- AI agents: ... -->comment in CHANGELOG.md tells future agents how to write entries. Don't omit it. - Known Bugs stays pinned. The stamp script preserves
## Known Bugsabove## [Unreleased]. If you add it, agents should maintain it there. - SemVer + auto-CalVer = silent footgun. If a Makefile in a SemVer project calls
python3 scripts/version.py stampwithout--version, the script auto-computes CalVer and writes that into the changelog. The recipes inreferences/semver.mdalways pass--version; preserve that contract in any custom integration. - Config file stamping is first-match-only for TOML. The regex replaces only the first
version = "..."line, which is the package version. Dependency versions are unaffected. - VERSION file stamping requires existing semver-shaped content. The script's
VERSIONhandler only rewrites the file if its current content matches^\d+\.\d+\.\d+. Build numbers, tag-prefixed versions, or other formats are left alone.
In this repository71 other files it gives its agents.
- Rules/CLAUDE.mdCLAUDE.md
- Skills/ambitious-model-use/CLAUDE.mdCLAUDE.md
- Skills/authoring-claude-md/CLAUDE.mdCLAUDE.md
- Skills/bento-slides/CLAUDE.mdCLAUDE.md
- Skills/extract-wisdom/CLAUDE.mdCLAUDE.md
- Skills/ghostty-config/CLAUDE.mdCLAUDE.md
- Skills/llm-wiki/CLAUDE.mdCLAUDE.md
- Skills/llm-wiki/examples/CLAUDE.mdCLAUDE.md
- Skills/openspec-bootstrap/CLAUDE.mdCLAUDE.md
- Skills/openspeccer/CLAUDE.mdCLAUDE.md
- Skills/rewrite-slop/CLAUDE.mdCLAUDE.md
- Skills/skill-creator-primer/CLAUDE.mdCLAUDE.md
- Skills/yue2-music/CLAUDE.mdCLAUDE.md
- ambitious-model-useSkill
- analyse-designSkill
- apply-mantel-stylesSkill
- authoring-claude-mdSkill
- backlogSkill
- bento-slidesSkill
- code-reviewSkill
- code-simplificationSkill
- creating-development-plansSkill
- critical-thinking-logical-reasoningSkill
- deeperSkill
- deferred-task-executionSkill
- demo-recorderSkill
- excalidraw-diagramsSkill
- explainSkill
- extract-wisdomSkill
- find-docsSkill
- ghostty-configSkill
- githubSkill
- golang-developmentSkill
- graphifySkill
- grill-meSkill
- guided-demoSkill
- handoffSkill
- hardware-designSkill
- herdrSkill
- home-assistantSkill
- html-design-examplesSkill
- improve-codebase-architectureSkill
- json-schema-lookupSkill
- liteparseSkill
- llm-prompting-guideSkill
- ml-llm-wikiSkill
- llm-wikiSkill
- mermaid-diagramsSkill
- openspec-bootstrapSkill
- openspeccerSkill
- pptx-to-mdSkill
- prompt-enhancerSkill
- prototypeSkill
- python-developmentSkill
- raspberry-pi-pico2Skill
- release-debriefSkill
- retroSkill
- rewrite-slopSkill
- rexSkill
- rust-developmentSkill
- The first 60 shown.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

