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

Generate categorized release notes from commits since last entry and bump version numbers

[!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 current version from package.json
  • Increment patch by 1 (e.g., 1.0.0 → 1.0.1)
  • Update version strings in these files:
  • package.json — update "version" field
  • docs/general/MANUAL.md — update **Version**: X.X.X and **Last updated**: Month DD, YYYY

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

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

[!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

Current version: 1.6.3 (update this reference after each release)

  • Determine current version from package.json
  • Increment patch by 1 (e.g., 1.6.1 → 1.6.2)
  • Update version strings in ALL three files:
  • package.json — update "version" field
  • backend/package.json — update "version" field
  • docs/general/MANUAL.md — update **Version**: X.X.X and **Last updated**: Month DD, YYYY
    • Also bump **Manual Version**: Y.Y if 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. 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 OpportunityModal save behavior")
  • Omit categories with no changes