Skills/ai-changelog/SKILL.md
Set up an AI-driven changelog system in any project. Creates CHANGELOG.md with an [Unreleased] section for AI agents, a Python version/changelog stamping script (CalVer or SemVer), and build/CI integration. Use when the user wants to add automated changelog management, AI-friendly changelog workflows, version stamping, or set up a changelog system for a new or existing project. Also use when asked to improve an existing changelog process.
npx skillsauth add sammcj/agentic-coding ai-changelogInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Set up a changelog system where AI coding agents write entries under ## [Unreleased] during development, and automation stamps version numbers at release time. No agent ever writes version numbers; the build process handles that.
Detect the build system: Check for Makefile, Justfile, package.json, Cargo.toml, pyproject.toml, go.mod. Note which config files contain a "version" field.
Detect the versioning scheme by inspecting (highest confidence first):
CHANGELOG.md heading style: ## [YYYY.M.N] headings → CalVer; ## [X.Y.Z] headings or prose mentioning "SemVer" → SemVergit tag --list | head: vX.Y.Z → SemVer; YYYY.M.N → CalVerVERSION file with content matching ^[0-9]+\.[0-9]+\.[0-9]+ → SemVerpackage.json, Cargo.toml, pyproject.toml) matching X.Y.Z → SemVerIf 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:
references/calver.mdreferences/semver.mdAsk the user about optional features:
## Known Bugs section above ## [Unreleased]? (default: yes)Generate or update CHANGELOG.md using references/changelog-template.md. If a CHANGELOG.md already exists, do NOT overwrite it; insert the HTML comment and the ## [Unreleased] (and optional ## Known Bugs) structure above existing entries.
Copy scripts/version.py from this skill into the target project's scripts/ directory. Make it executable (chmod +x).
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.
Update CLAUDE.md with the snippet from the chosen scheme reference. Insert into the project's development workflow section, or create one.
Verify:
uv run scripts/version.py version should print today's CalVer; then uv run scripts/version.py stamp --dry-run previews the stampuv run scripts/version.py stamp --version <current-version> --dry-run --changelog-only previews the stamp without touching the canonical version source| Indicator | Config files to stamp | Build integration |
|---|---|---|
| Makefile | depends on project | Add make targets |
| Justfile | depends on project | Add just recipes |
| package.json | package.json | Add npm scripts or Makefile |
| Cargo.toml | Cargo.toml | Makefile wrapper |
| pyproject.toml | pyproject.toml | Makefile wrapper |
| go.mod | VERSION (if present) or none | Makefile wrapper |
| VERSION file | VERSION | Makefile wrapper |
| None | none | Create minimal Makefile |
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).
[Unreleased] structure into it rather than replacing the file.[Unreleased] has no content. This prevents empty version entries.fetch-depth: 0 in CI for CalVer: CalVer uses git rev-list --count HEAD. Shallow clones produce wrong commit counts.<!-- AI agents: ... --> comment in CHANGELOG.md tells future agents how to write entries. Don't omit it.## Known Bugs above ## [Unreleased]. If you add it, agents should maintain it there.python3 scripts/version.py stamp without --version, the script auto-computes CalVer and writes that into the changelog. The recipes in references/semver.md always pass --version; preserve that contract in any custom integration.version = "..." line, which is the package version. Dependency versions are unaffected.VERSION handler only rewrites the file if its current content matches ^\d+\.\d+\.\d+. Build numbers, tag-prefixed versions, or other formats are left alone.development
Use when answering questions from this machine-learning knowledge base. Triggers: questions about transformers, attention cost and efficiency, and long-context scaling; 'what do we know about attention', 'check the ML wiki'. Read-only querying of compiled knowledge; to add, update, supersede, lint, or audit, use the llm-wiki skill instead.
development
Use when building or maintaining a self-contained personal knowledge base (an LLM wiki) as plain markdown, optionally opened as an Obsidian vault. Triggers: ingesting sources into a wiki, querying wiki knowledge, linting wiki health, auditing article claims against their sources, superseding stale knowledge, 'add to wiki', or any mention of 'LLM wiki' or 'Karpathy wiki'.
tools
Provides guidance and tools for hardware design. Activate when using KiCAD, looking up electronic parts or designing PCBs.
testing
Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise.