Skip to content

Release Notes Generation (/release-notes)

In plain terms

Writes tidy, categorized release notes from your recent commits and bumps the version number.

What this skill does

Generates categorized release notes from commits since the last entry and bumps version numbers across the project. Use when the user asks to cut a release, bump the version, tag a release, or generate release notes.

[!IMPORTANT] Run before committing to update docs/general/RELEASE_NOTES.md and bump version numbers.

Trigger Conditions

  • Keywords: "Generate release notes", "New release", "Bump version", "Tag release"

0. Guard — Check for Double-Bump

Before doing anything else:

  1. Read the version from package.json
  2. Read the version from the most recent header in docs/general/RELEASE_NOTES.md (format: ## X.X.X (YYYY-MM-DD))
  3. If they match — stop immediately. Respond with:

    Release notes are already up to date for version X.X.X. Nothing to do.

Only continue to step 1 if package.json version does not match the latest release notes header.

1. Identify Last Release Date

  • Read docs/general/RELEASE_NOTES.md
  • Extract the date from the most recent version header: ## X.X.X (YYYY-MM-DD)

2. Get Commits Since Last Entry

  • Run: 
    git log --since="YYYY-MM-DD" --oneline
    (using the extracted date from step 1)
  • If no commits found, check for uncommitted changes: git status and git diff --stat

3. Analyze Changes

For each commit or change, categorize by type:

Category Emoji What qualifies
New Features 📄 New functionality, new pages, new components
Enhancements 🔍 Improvements to existing features
Bug Fixes 🐛 Error corrections
UI Improvements 🎨 Visual/UX changes
Documentation 📚 Docs, manual, README updates
Technical 🔧 Refactoring, performance, infrastructure

4. Bump the Version Number

  • Determine the current version from package.json
  • Increment patch by 1 (e.g., 1.0.0 → 1.0.1)
  • Update version strings everywhere they appear in this project:
  • package.json — update the "version" field
  • backend/package.json — update the "version" field if the project keeps a separate backend manifest (skip if it doesn't)
  • docs/general/MANUAL.md — update **Version**: X.X.X and **Last updated**: Month DD, YYYY
    • Also bump **Manual Version**: Y.Y if the manual content changed

5. Generate Release Notes Entry

Create the new entry using this format:

## X.X.X (YYYY-MM-DD)

### 📄 New Features
- Description of new feature

### 🔍 Enhancements
- Description of enhancement

### 🐛 Bug Fixes
- Description of fix
  • The version MUST match the bumped version from step 4
  • Omit categories with no changes
  • Keep descriptions concise but informative — reference component/file names where helpful

6. Update Release Notes File

  • Prepend the new entry after the # Release Notes header in docs/general/RELEASE_NOTES.md
  • Add --- separator before the previous entry

7. Optional Git Tagging

  • If requested by the user, create a git tag for the new version:
  • git tag -a vX.X.X -m "Release vX.X.X"
  • git push origin --tags

8. Stage All Changes

  • Run: 
    git add .
  • Ensure all functional code changes AND version bumps are included in the same commit
  • Inform the user that release notes, version bumps, and all code changes are ready and staged

Output Guidelines

  • Use emoji prefixes for visual scanning
  • Group related changes under the same category
  • Reference component/file names where helpful (e.g., "Updated InvitationModal save behavior")
  • Omit categories with no changes