codemie-release
CodeMie Release
Automate the release process for CodeMie CLI following semantic versioning and conventional commits.
Pre-flight Checks
Before starting, verify:
- Branch: Must be on
main. If not, stop and ask user to switch. - Working directory: Check for uncommitted changes. Warn if present.
- Current state: Determine what's already done:
# Current version grep '"version"' package.json | sed 's/.*"version": "\(.*\)".*/\1/' # Latest tag git describe --tags --abbrev=0 2>/dev/null # Check if tag exists git tag -l "v<VERSION>" # Check if release exists gh release view "v<VERSION>" 2>/dev/null
Analyze Commits and Determine Version
CRITICAL: Always analyze commits to determine the appropriate version bump based on conventional commit types.
1. Get Commit Delta
# Get commits since last release (excluding version bump commits)
LAST_TAG=$(git describe --tags --abbrev=0 2>/dev/null)
git log --pretty=format:"%s" ${LAST_TAG:+$LAST_TAG..HEAD} | grep -v "^chore: bump version"
2. Analyze Commit Types
Parse each commit message to identify type:
Conventional Commit Format: <type>(<scope>): <subject>
- Types:
feat,fix,docs,style,refactor,perf,test,chore,ci,revert - Scopes (optional):
cli,agents,providers,assistants,config,proxy,workflows,ci,analytics,utils,deps,tests,skills
Breaking Changes: Check commit bodies for BREAKING CHANGE: footer
# Check for breaking changes
git log --pretty=format:"%B" ${LAST_TAG:+$LAST_TAG..HEAD} | grep -q "BREAKING CHANGE:"
3. Determine Version Bump
Version bump rules (highest precedence wins):
- MAJOR bump (x.0.0) - If any commit contains
BREAKING CHANGE:in body - MINOR bump (0.x.0) - If any commit has
feat:orfeat(scope): - PATCH bump (0.0.x) - If only
fix:,refactor:,perf:,docs:,style:,test:,chore:,ci:,revert:
4. Calculate Target Version
# Current version from package.json
CURRENT=$(grep '"version"' package.json | sed 's/.*"version": "\(.*\)".*/\1/')
# Parse version parts (e.g., "0.0.35" → major=0, minor=0, patch=35)
IFS='.' read -r MAJOR MINOR PATCH <<< "$CURRENT"
# Apply bump based on commit analysis:
# - If BREAKING CHANGE found: MAJOR=$((MAJOR+1)), MINOR=0, PATCH=0
# - If feat: found: MINOR=$((MINOR+1)), PATCH=0
# - Otherwise: PATCH=$((PATCH+1))
TARGET_VERSION="$MAJOR.$MINOR.$PATCH"
5. Present Recommendation
Show the user:
- Current version: e.g.,
0.0.35 - Commits analyzed: List of commit subjects
- Detected bump type: MAJOR/MINOR/PATCH with explanation
- Recommended version: e.g.,
0.0.36 - Ask user to confirm or provide alternative
Example output:
📦 Current version: 0.0.35
📊 Analyzed 3 commits since v0.0.35:
- fix(utils): auto-update PATH during Claude installation on Windows (#120)
- refactor(skills): relocate skills module to codemie-code agent (#117)
🔍 Detected: PATCH bump (only fixes and refactors found)
🎯 Recommended version: 0.0.36
Confirm release version 0.0.36?
Generate Release Notes
CRITICAL: Group commits by type and generate concrete, user-focused release notes.
1. Categorize Commits
# Get full commit messages since last tag
LAST_TAG=$(git describe --tags --abbrev=0 2>/dev/null)
git log --pretty=format:"%s|%b" ${LAST_TAG:+$LAST_TAG..HEAD} | grep -v "^chore: bump version"
Group commits by type:
- ✨ Features (feat)
- 🐛 Bug Fixes (fix)
- ⚡ Performance (perf)
- ♻️ Refactoring (refactor)
- 📚 Documentation (docs)
- 🔧 Maintenance (chore, ci, test, style)
2. Extract Concrete Details
For each commit:
- Remove type prefix:
feat(agents): add feature→add feature - Capitalize first letter:
add feature→Add feature - Keep PR numbers:
(#123) - Extract scope for context:
feat(agents):→ show as "[agents]"
3. Format Breaking Changes
If breaking changes exist:
## ⚠️ BREAKING CHANGES
- **[scope]**: Description of what broke and how to migrate
Extract from commit body after BREAKING CHANGE: line.
4. Release Notes Template
## What's Changed
### ✨ Features
- **[scope]**: Feature description (#PR)
### 🐛 Bug Fixes
- **[scope]**: Fix description (#PR)
### ⚡ Performance Improvements
- **[scope]**: Performance improvement (#PR)
### ♻️ Refactoring
- **[scope]**: Refactoring description (#PR)
### 📚 Documentation
- **[scope]**: Documentation change (#PR)
### 🔧 Maintenance
- **[scope]**: Maintenance task (#PR)
**Full Changelog**: https://github.com/codemie-ai/codemie-code/compare/${LAST_TAG}...v<VERSION>
Example concrete release notes:
## What's Changed
### 🐛 Bug Fixes
- **[utils]**: Auto-update PATH during Claude installation on Windows (#120)
### ♻️ Refactoring
- **[skills]**: Relocate skills module to codemie-code agent (#117)
**Full Changelog**: https://github.com/codemie-ai/codemie-code/compare/v0.0.35...v0.0.36
Release Steps
Execute each step, skipping if already completed:
1. Update Version
npm version <VERSION> --no-git-tag-version
Skip if package.json already at target version.
2. Commit Version Bump
git add package.json package-lock.json
git commit -m "chore: bump version to <VERSION>
🤖 Generated with release script"
Skip if commit message chore: bump version to <VERSION> exists in HEAD.
3. Create Tag
git tag -a "v<VERSION>" -m "Release version <VERSION>"
Skip if tag v<VERSION> already exists.
4. Push to Origin
git push origin main
git push origin "v<VERSION>"
5. Create GitHub Release
# Create release with generated notes
gh release create "v<VERSION>" \
--title "Release v<VERSION>" \
--notes "<GENERATED_RELEASE_NOTES>" \
--latest
Skip if release v<VERSION> already exists.
Use the concrete, categorized release notes generated in the previous section.
Completion
After successful release, inform user:
- ✅ Release v created successfully
- 🔄 Monitor GitHub Actions for npm publish
- 📦 Package will be available at:
npm install @codemieai/code@<VERSION> - 🔗 View release:
https://github.com/codemie-ai/codemie-code/releases/tag/v<VERSION>
More from codemie-ai/codemie-code
git-worktree
Manages git worktrees including listing, creating, removing, and switching between worktrees. Use when the user mentions creating worktrees, create a work tree, create worktree, new worktrees, parallel branches, or working on multiple branches simultaneously. CRITICAL - PROACTIVE BRANCH PROTECTION - Before starting ANY development work (implementing features, fixing bugs, writing code, making changes), check the current branch. If on main/master branch, IMMEDIATELY suggest creating a feature branch worktree to prevent accidental commits to main. This is mandatory for all development requests.
25spec-reviewer
Reviews technical specifications from solution-architect against Jira ticket requirements and project design guidelines. Identifies critical gaps and design principle violations. Provides focused feedback without code snippets. Verdict is APPROVED for implementation or NEEDS WORK with specific issues.
13dark-factory
This skill should be used when the user asks to "delegate a Jira ticket to dark factory", "start working on EPMCDME ticket as a factory", "implement EPMCDME ticket",
6codemie-pr
>-
6tech-lead
This skill should be used when the user asks to "implement a Jira ticket", "start working on EPMCDME ticket", "analyze task", "begin implementation", "implement new task", "implement feature", "act as tech lead", "plan implementation", "how should I implement", or wants structured technical leadership for implementing features. Acts as a technical lead to guide implementation from requirements (Jira ticket or user description) through complexity assessment, architectural analysis, branch creation, and pattern-driven coding.
5