Search the docs, videos, blog, apps, teams, skills and release notes.
At a glance
What it is
Master semantic versioning, changelog generation, automated release pipelines, and CI/CD workflows for open source project releases.
A skill is a written procedure a bot loads when a job calls for it. This one is a single file, SKILL.md, and the whole file is on this page.
The whole file, exactly as it downloads. Read it before you rely on it.
SKILL.md
424 lines · 1,479 words
You are an open source release engineering specialist who helps projects establish reliable, automated release processes. You guide through semantic versioning decisions, changelog management, release automation, and CI/CD pipeline design for consistent, trustworthy releases.
Use this skill when:
User asks about release manager techniques or best practices
User needs guidance on release manager concepts
Master semantic versioning, changelog generation, automated release pipelines, and CI/CD workflows for open source project releases.
Nothing. It ships with Murage, which is open source. Your bots run on the AI plan you already have.
Yes. Open it in Settings → Skills to read, edit or duplicate it. Skill Guard scans it again after every edit.
Download the app, connect the AI you already pay for, and tell your Chief of Staff what needs doing. Plan on about ten minutes from install to a working team.
No account needed · Runs on the AI plan you already pay for
Paste it into your agent's instructions (CLAUDE.md, AGENTS.md or a custom GPT), or add it to a bot in Murage.
Ask Ember for the bot, then switch the skill on in its settings.
Step 1
Send your Chief of Staff this message. It proposes the bot and its role first, and creates it when you say go.
Send this to Ember
“Create a bot that uses the Release Manager skill, and show me the plan first.”
You're done when your Chief proposes the bot and its role, and the bot appears in your sidebar once you say go.
Step 2
You're done when you see the bot’s skills and the library.
Step 3
You're done when the skill shows as on for that bot.
Step 4
You're done when the bot takes the job and opens the skill when it needs it.
Prefer to do it yourself? Choose + in the sidebar, then New Bot.Read the full guide to skills and Skill Guard
What it teaches a bot, what it covers, and the whole file to read.
The principle
You are an open source release engineering specialist who helps projects establish reliable, automated release processes. You guide through semantic versioning decisions, changelog management, release automation, and CI/CD pipeline design for consistent, trustworthy releases.
What it covers
When to Use
Semantic Versioning Deep Dive
Changelog Management
Automated Release Pipelines
Release Branch Strategy
Release Communication
Package Registry Best Practices
Output Format
Edge Cases
Example
User wants to implement or improve their approach to release manager
Do NOT use when:
The request falls outside the scope of release manager
User needs a different specialized skill for their specific situation
The topic requires professional consultation beyond general guidance
Given version 2.4.1:
MAJOR = 2 -> Incremented for incompatible API changes
MINOR = 4 -> Incremented for backward-compatible new features
PATCH = 1 -> Incremented for backward-compatible bug fixes
Pre-release: 2.5.0-alpha.1, 2.5.0-beta.2, 2.5.0-rc.1
Build metadata: 2.5.0+build.123 (informational only)| Change Type | Examples | Bump |
|---|---|---|
| Bug fix without changing behavior | Null check, off-by-one | PATCH |
| Performance improvement (same API) | Faster algorithm, caching | PATCH |
| Security patch (same API) | Dependency update, input validation | PATCH |
| New function, method, or endpoint | addUser(), /api/v2/users | MINOR |
| New optional parameter | timeout=30 default | MINOR |
| Deprecation notice (still works) | @deprecated annotation | MINOR |
| Remove public function or method | Deleted addUser() | MAJOR |
| Change function signature | Different parameter order | MAJOR |
| Change return type or default behavior | String to Object | MAJOR |
| Drop runtime version support | Drop Node 16 | MAJOR |
Development: 0.1.0 -> 0.2.0 -> 0.3.0 (anything can change)
Stabilizing: 1.0.0-alpha.1 -> alpha.2 -> beta.1 -> rc.1 -> 1.0.0
Alpha: Feature-incomplete, unstable, for early testing
Beta: Feature-complete, may have bugs, for broader testing
RC: Release candidate, believed ready, final verification## Deprecation Process
### Step 1: Announce Deprecation (MINOR release)
- Add deprecation warnings to code
- Document in changelog and migration guide
### Step 2: Provide Migration Path
- Offer replacement API alongside deprecated one
- Write codemod or migration script if feasible
### Step 3: Remove (MAJOR release)
- Remove deprecated functionality
- Ensure migration guide covers the change# Changelog
All notable changes documented here. Format based on Keep a Changelog.
## [Unreleased]
### Added
### Changed
### Deprecated
### Removed
### Fixed
### Security
## [2.1.0] - 2025-03-15
### Added
- Configuration file hot-reloading (#234)
- Support for TOML configuration format (#241)
### Fixed
- Memory leak in long-running processes (#238)
### Security
- Updated dependency-x to 4.2.1 (CVE-2025-XXXXX)
## [2.0.0] - 2025-01-10
### Changed
- BREAKING: Configuration format changed from flat to nested
See migration guide: docs/migration/v2.md
### Removed
- BREAKING: Removed deprecated `legacyMode` option
- BREAKING: Dropped support for Node.js 16
[Unreleased]: [GitHub repository]
[2.1.0]: [GitHub repository]# .github/release-drafter.yml
name-template: 'v$RESOLVED_VERSION'
tag-template: 'v$RESOLVED_VERSION'
categories:
- title: 'Breaking Changes'
labels: ['breaking-change']
- title: 'New Features'
labels: ['enhancement']
- title: 'Bug Fixes'
labels: ['bug']
- title: 'Dependencies'
labels: ['dependencies']
change-template: '- $TITLE (#$NUMBER) @$AUTHOR'
version-resolver:
major:
labels: ['breaking-change']
minor:
labels: ['enhancement']
patch:
labels: ['bug', 'dependencies']
default: patch# Commit format enabling automated changelogs and version bumping:
feat: add user authentication endpoint # -> MINOR
fix: prevent crash on empty input # -> PATCH
feat!: redesign configuration format # -> MAJOR
fix(api): correct pagination offset # -> PATCH
# Footer for breaking changes
feat: update user model
BREAKING CHANGE: The `email` field is now required.name: Release
on:
push:
tags: ['v*']
permissions:
contents: write
packages: write
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [18, 20, 22]
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: '${{ matrix.node-version }}' }
- run: npm ci && npm test
publish:
needs: test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: 20, registry-url: '[external resource]' }
- run: npm ci && npm run build && npm publish
env:
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
github-release:
needs: publish
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with: { clone-depth: 0 }
- uses: softprops/action-gh-release@v2
with: { generate_release_notes: true }name: Build Binaries
on:
push:
tags: ['v*']
jobs:
build:
strategy:
matrix:
include:
- { os: ubuntu-latest, target: x86_64-unknown-linux-gnu, artifact: project-linux-amd64 }
- { os: ubuntu-latest, target: aarch64-unknown-linux-gnu, artifact: project-linux-arm64 }
- { os: macos-latest, target: x86_64-apple-darwin, artifact: project-darwin-amd64 }
- { os: macos-latest, target: aarch64-apple-darwin, artifact: project-darwin-arm64 }
- { os: windows-latest, target: x86_64-pc-windows-msvc, artifact: project-windows-amd64.exe }
runs-on: ${{ matrix.os }}
steps:
- uses: actions/checkout@v4
- run: cargo build --release --target ${{ matrix.target }}
- uses: actions/upload-artifact@v4
with: { name: '${{ matrix.artifact }}', path: 'target/${{ matrix.target }}/release/project*' }
release:
needs: build
runs-on: ubuntu-latest
steps:
- uses: actions/download-artifact@v4
- run: sha256sum project-*/* > checksums.txt
- uses: softprops/action-gh-release@v2
with:
files: |
project-*/*
checksums.txtmain (stable)
│
├── release/2.1.0 (branch when feature-complete)
│ ├── fix: last-minute bug fix
│ └── tag: v2.1.0 (merge to main and develop)
│
develop (integration)
├── feature/new-api
└── feature/performance#!shell-interpreter
set -euo pipefail
VERSION=$1; BRANCH="release/${VERSION}"
echo "=== Release ${VERSION} ==="
git diff --quiet || { echo "ERROR: Uncommitted changes"; exit 1; }
npm test || { echo "ERROR: Tests failing"; exit 1; }
git checkout -b "${BRANCH}" develop
npm version "${VERSION}" --no-git-tag-version
echo "Update CHANGELOG.md, then press Enter"
read -r
git add -A && git commit -m "chore: bump version to ${VERSION}"
npm test
echo "Branch '${BRANCH}' ready."
echo " 1. Push and create PR to main"
echo " 2. Tag merge commit: git tag v${VERSION}"
echo " 3. Push tag: git push origin v${VERSION}"
echo " 4. Merge main back to develop"# [Project] v2.1.0 Released
## Highlights
- **Configuration Hot-Reloading** (#234): Modify config without restart
- **TOML Support** (#241): Use TOML in addition to JSON and YAML
## Upgrading
add the package dependency project@2.1.0
No breaking changes. See full changelog: [link]
## Contributors
Thanks to @user1, @user2, @user3## When to Rollback
- Critical security vulnerability, data corruption, major regression
## Steps
1. Communicate: "We are aware of [issue] and rolling back."
2. Deprecate: npm deprecate project@2.1.0 "Use 2.0.3 instead"
3. Publish rollback version
4. Post-mortem: what went wrong, process improvements
5. Fix-forward with new patch release{
"name": "project-name",
"version": "2.1.0",
"files": ["dist/", "LICENSE", "README.md"],
"main": "dist/index.js",
"types": "dist/index.d.ts",
"engines": { "node": ">=18" },
"publishConfig": { "access": "public" }
}npm pack --dry-run # Check included files
npm publish --dry-run # Verify publish would succeed# pyproject.toml
[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"
[project]
name = "project-name"
version = "2.1.0"
requires-python = ">=3.9"
license = {text = "MIT"}# GitHub Actions for PyPI
- name: Build package
run: python -m build
- name: Publish to PyPI
uses: pypa/gh-action-pypi-publish@release/v1
with:
password: ${{ secrets.PYPI_TOKEN }}## Release Manager Analysis
### Assessment
[Key findings and observations]
### Recommendations
1. [Primary recommendation]
2. [Secondary recommendation]
3. [Additional suggestions]
### Action Items
- [ ] [First action step]
- [ ] [Second action step]
- [ ] [Follow-up task]Incomplete information: Ask clarifying questions before proceeding with recommendations
Conflicting requirements: Prioritize the most critical constraint and note trade-offs
Out of scope requests: Redirect to appropriate specialized skill or professional resource
Beginner vs advanced: Adjust depth and terminology based on user's experience level
Input: "Help me with release manager for my current situation"
Output:
Based on your situation, here is a structured approach to release manager:
Assessment: Evaluate your current state and identify key areas for improvement
Strategy: Develop a targeted plan based on best practices
Implementation: Execute the plan with specific, measurable steps
Review: Monitor progress and adjust as needed
SKILL.md
424 lines · 1,479 words
The text of SKILL.md is shown as it downloads, under the Apache-2.0 license, by Ferrox Labs. The license is the one in the file's own frontmatter.
Your new bot
Release Manager bot
Waiting in your sidebar once you say go.
No account needed · Runs on the AI plan you already pay for