cimtechniques-service-suite/.claude/commands/release-notes.md at main

Files

Andy 63169a7644 feat: add versioning and changelog system

Conventional-Commit-driven version bumps (scripts/bump.py), a commit-msg validation hook, and a /release-notes workflow that produces a human-reviewed CHANGELOG.md. Adds an in-app version badge + 'What's new' dialog on the launcher. The version is single-sourced from pyproject.toml (cim_suite.__version__), and the deterministic bump backbone lives in scripts/release/ with tests in tests/release/. Marks the 1.0.0 baseline.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-06 11:31:22 -04:00

2.3 KiB

Raw Permalink Blame History

description

description
Draft plain-language CHANGELOG.md release notes from commits since the last version, for human review before committing.

You are drafting the human-facing release notes for the CIMTechniques Service Suite. The git history is the technical record; CHANGELOG.md is what non-technical users read. Accuracy is paramount — never invent a user-facing benefit a commit doesn't support, and when a commit's user impact is unclear, flag it for the user instead of guessing.

Follow these steps exactly:

Collect the commits. Run:
```
.venv\Scripts\python scripts/release_notes.py --json
```
If there is no version tag yet and the digest reaches back into pre-rewrite history, ask the user for a --baseline <commit-or-tag> and re-run with it. The JSON gives you current_version, suggested_version, suggested_bump, and commits bucketed into features, fixes, breaking, and an internal_count.
Draft entries in Keep a Changelog format for the suggested_version (or a version the user specifies), dated today:
- Group under Added / Changed / Fixed / Removed — omit any empty group.
- feat commits → usually Added (or Changed if they alter existing behavior). fix → Fixed. breaking → call out clearly (often Changed/Removed).
- Write for a non-technical reader: explain what changed and why it matters to them, not the implementation. One bullet per user-visible change; merge related commits into a single clear bullet.
- Collapse all internal work (refactor/test/chore/style/docs/build/ci) into at most a single line: "Maintenance and under-the-hood improvements." Drop it if there were none.
- Flag any commit whose user impact you're unsure of, and ask rather than guess.
Show the draft to the user in chat and ask them to edit/approve. Do not write the file yet.
Only after approval, prepend the approved entry above the previous version's entry in CHANGELOG.md (reverse-chronological). Do not auto-commit; leave the change in the working tree for the user unless they ask you to commit it.
If the version number should change, remind the user to run .venv\Scripts\python scripts/bump.py (which is deterministic and edits pyproject.toml). You never set the version number yourself.

2.3 KiB Raw Permalink Blame History

2.3 KiB

Raw Permalink Blame History