release
This skill should be used when the user asks to "create release", "bump version", "tag and push", "publish release", "make a release", "new version", "deploy release", "push tag", or after completing a commit/PR merge and needs to create a version release. Automates version bump, git tag creation, push, and GitHub release notes generation.
What this skill does
# Release Automation
Automate semantic version bumps, git tags, and GitHub releases.
## Prerequisites
- Git repository with at least one commit
- `gh` CLI authenticated (`gh auth status`)
- Push access to remote repository
## Workflow
### Phase 1: Verify Release Readiness
```bash
# Check clean working tree
git status --porcelain
# Check remote access
git remote -v
gh auth status
```
**Dirty working tree**: Warn user. Recommend commit or stash before release.
**No remote**: Cannot push tags or create GitHub release. Abort with guidance.
### Phase 2: Detect Current Version
Search for version source file in priority order:
| Priority | File | Pattern |
|----------|------|---------|
| 1 | `package.json` | `"version": "X.Y.Z"` |
| 2 | `Cargo.toml` | `version = "X.Y.Z"` |
| 3 | `pyproject.toml` | `version = "X.Y.Z"` |
| 4 | `setup.py` | `version="X.Y.Z"` |
| 5 | `init.lua` | `obj.version = "X.Y.Z"` |
For detailed patterns: [references/version-patterns.md](references/version-patterns.md)
```bash
# Also check git tags
git describe --tags --abbrev=0 2>/dev/null || echo "No tags"
git tag -l 'v*' | sort -V | tail -5
```
**Version mismatch**: If source file version differs from latest tag, warn user and ask which to use as base.
### Phase 3: Analyze Changes for Bump Type
Get commits since last tag:
```bash
LAST_TAG=$(git describe --tags --abbrev=0 2>/dev/null)
if [ -n "$LAST_TAG" ]; then
git log ${LAST_TAG}..HEAD --oneline
else
git log --oneline -20
fi
```
Determine bump type from commit messages:
| Pattern | Bump Type |
|---------|-----------|
| `BREAKING CHANGE:` in body | **major** |
| `!:` after type (e.g., `feat!:`) | **major** |
| `feat:` or `feat(scope):` | **minor** |
| `fix:`, `docs:`, `chore:`, `refactor:`, `test:`, `style:`, `perf:`, `ci:`, `build:` | **patch** |
**Mixed commits**: Use highest severity (major > minor > patch).
**No conventional commits**: Default to patch, but ask user to confirm.
### Phase 4: Confirm Version Bump
Present analysis to user via `AskUserQuestion`:
```
## Version Bump Analysis
**Current version**: 1.2.3
**Commits since last release**: 5
### Changes detected:
- feat: Add new feature X
- fix: Resolve bug Y
- docs: Update README
**Recommended bump**: minor (1.2.3 -> 1.3.0)
Select version bump type:
```
Options:
- `minor (Recommended)` - 1.3.0
- `patch` - 1.2.4
- `major` - 2.0.0
- `Custom version` - User specifies
### Phase 5: Update Version Source
Update the detected version file:
**package.json** (preferred method):
```bash
npm version $NEW_VERSION --no-git-tag-version
```
**Other files**: Use Edit tool with exact string replacement.
**Multiple version files**: Update all (e.g., `init.lua` + `docs.json` for Spoons).
### Phase 6: Commit Version Bump
```bash
git add -A
git commit -m "chore: bump version to $NEW_VERSION
Co-Authored-By: Claude Opus 4.5 <[email protected]>"
```
### Phase 7: Create and Push Tag
```bash
# Create annotated tag
git tag -a "v$NEW_VERSION" -m "Release v$NEW_VERSION"
# Push commit and tag
git push origin HEAD
git push origin "v$NEW_VERSION"
```
### Phase 8: Create GitHub Release
Generate release notes from commit log, categorized by conventional commit type.
**Step 1**: Collect non-merge commits since last tag:
```bash
git log ${LAST_TAG}..v${NEW_VERSION} --oneline --no-merges
```
**Step 2**: Categorize commits into sections:
| Commit prefix | Section header |
|---------------|---------------|
| `feat!:`, `BREAKING CHANGE:` | **Breaking Changes** |
| `feat:` | **Features** |
| `fix:` | **Bug Fixes** |
| `perf:` | **Performance** |
| `refactor:` | **Refactor** |
| `docs:` | **Documentation** |
| `test:`, `ci:`, `build:`, `chore:` | (omit unless noteworthy) |
**Step 3**: Create release with categorized notes:
```bash
gh release create "v$NEW_VERSION" \
--title "v$NEW_VERSION" \
--notes "$(cat <<'EOF'
## Breaking Changes
- Description of breaking change
## Features
- Feature description (#PR)
## Bug Fixes
- Fix description
**Full Changelog**: https://github.com/owner/repo/compare/vOLD...vNEW
EOF
)"
```
**Rules**:
- Omit empty sections (e.g., no Breaking Changes → skip that header)
- Use commit message as-is for bullet text (strip type prefix)
- Include PR number if available
- `chore: bump version` commits are always excluded
- Append `**Full Changelog**` comparison link at the end
## Output Summary
After successful release:
```
## Release Complete
**Version**: v1.3.0
**Tag**: https://github.com/owner/repo/releases/tag/v1.3.0
**Commits included**: 5
### Changes:
- feat: Add new feature X
- fix: Resolve bug Y
```
## Error Handling
### Push Rejected
```
error: failed to push some refs
hint: Updates were rejected because the remote contains work
```
**Solution**: Pull and rebase, then retry:
```bash
git pull --rebase origin main
git push origin HEAD
git push origin "v$NEW_VERSION"
```
### Tag Already Exists
```
fatal: tag 'v1.3.0' already exists
```
**Solution**: Ask user - delete existing tag or increment version.
### gh CLI Not Authenticated
```
error: gh: To use GitHub CLI...
```
**Solution**: Run `gh auth login` and retry.
### No Version File Found
**Solution**: Ask user which file contains version, or suggest creating `package.json`.
## Special Cases
### Monorepo
Multiple packages with independent versions:
- Ask user which package to release
- Update only that package's version file
- Tag format: `[email protected]` or `package-name-v1.2.3`
### Prerelease
User requests alpha/beta/rc:
```bash
# Examples
1.3.0-alpha.1
1.3.0-beta.2
1.3.0-rc.1
```
Use `--prerelease` flag (with same commit-based notes from Phase 8):
```bash
gh release create "v$NEW_VERSION" --prerelease --notes "..."
```
### Draft Release
User wants to review before publishing:
```bash
gh release create "v$NEW_VERSION" --draft --notes "..."
```
### Changelog File
If `CHANGELOG.md` exists, offer to update it:
```markdown
## [1.3.0] - 2025-01-31
### Added
- Feature X
### Fixed
- Bug Y
```
## Usage Examples
| Request | Action |
|---------|--------|
| "create release" | Full workflow with auto-detected bump type |
| "bump version minor" | Force minor bump, skip analysis |
| "release v2.0.0" | Use specified version |
| "push tag only" | Skip version file update, tag and push only |
| "prerelease alpha" | Create 1.3.0-alpha.1 prerelease |
| "draft release" | Create draft GitHub release |
## Rollback
If release needs to be reverted:
```bash
# Delete remote tag
git push origin --delete "v$VERSION"
# Delete local tag
git tag -d "v$VERSION"
# Delete GitHub release
gh release delete "v$VERSION" --yes
# Revert version commit (if needed)
git revert HEAD
```
## References
- [references/version-patterns.md](references/version-patterns.md) - Version file detection patterns and update commands
Related in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.