Agent skill

Release Manager

by FerroxLabs in FerroxLabs/wayland

Master semantic versioning, changelog generation, automated release pipelines, and CI/CD workflows for open source project releases Use when the user asks about release manager, related techniques…

Apache-2.0Auto-check passedDevelopment

Install Release Manager

skills CLI
$ npx skills add FerroxLabs/wayland --skill release-manager -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install FerroxLabs/wayland release-manager --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/FerroxLabs/wayland.git skills-src && mkdir -p .claude/skills && cp -r skills-src/src/process/resources/skills-library/bodies/skills/software-engineering/release-manager .claude/skills/release-manager && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
release-manager
GitHub stars
608
Token cost
~2.8k tokens
SKILL.md length
361 words
Files
1
Skills in repo
1,194
Repo updated
First seen
Licence
Apache-2.0

At a glance

Master semantic versioning, changelog generation, automated release pipelines, and CI/CD workflows for open source project releases Use when the user asks about release manager, related techniques…

  • Works in 4 steps: Assessment: Evaluate your current state… → Strategy: Develop a targeted plan based… → Implementation: Execute the plan with… → …
  • The user asks about release manager
  • SKILL.md covers When to Use, Semantic Versioning Deep Dive, Changelog Management and Automated Release Pipelines, plus 6 more sections
  • Calls npm and git; needs NODE_AUTH_TOKEN and NPM_TOKEN

What it does

Release Manager is an agent skill from FerroxLabs/wayland. Master semantic versioning, changelog generation, automated release pipelines, and CI/CD workflows for open source project releases Use when the user asks about release manager, related techniques, best practices, or needs guidance in this domain. Do NOT use when the request is outside the scope of release manager or requires a different specialized skill.

Its SKILL.md is about 2.8k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Changelog and release notes and CI/CD. The repository describes itself as: Wayland - The AI Agent That Perceives. Reasons. Acts. Evolves. The licence is Apache-2.0.

When your agent uses it

  • The user asks about release manager
  • Related techniques
  • Needs guidance in this domain
  • The request is outside the scope of release manager

Example prompts

  • “/release-manager”

Requirements

  • Python 3
  • Node.js
  • A credential in NODE_AUTH_TOKEN
  • A credential in NPM_TOKEN

Workflow steps

4 steps, taken from the first numbered list in SKILL.md.

  1. Assessment: Evaluate your current state and identify key areas for improvement
  2. Strategy: Develop a targeted plan based on best practices
  3. Implementation: Execute the plan with specific, measurable steps
  4. Review: Monitor progress and adjust as needed

What it can do on your machine

Read from SKILL.md and the folder at commit 4c030c7. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • npm
    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use npm and git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names these keys or tokens, usually read from environment variables:

    • NODE_AUTH_TOKEN
    • NPM_TOKEN
    • PYPI_TOKEN

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Release Manager loads about 2.8k tokens when it runs. Until then it costs about 94 tokens; SKILL.md has 361 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~94
When it runs · the whole SKILL.md, loaded when a task matches
~2.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from FerroxLabs/wayland at commit 4c030c7, republished under its Apache-2.0 licence (© FerroxLabs). 361 words, ~2,822 tokens.

Download SKILL.mdSave it as .claude/skills/release-manager/SKILL.md (or your agent's skills folder).
name
release-manager
description
Master semantic versioning, changelog generation, automated release pipelines, and CI/CD workflows for open source project releases Use when the user asks about release manager, related techniques, best practices, or needs guidance in this domain. Do NOT use when the request is outside the scope of release manager or requires a different specialized skill.
license
Apache-2.0
metadata.author
foundry-skills
metadata.version
1.0.0
metadata.tags
best-practices checklist template guide python api-design testing automation
metadata.category
software-engineering
metadata.subcategory
developer-tools
metadata.disclaimer
none
metadata.difficulty
intermediate

Release Manager

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.

When to Use

Use this skill when:

  • User asks about release manager techniques or best practices
  • User needs guidance on release manager concepts
  • 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

Semantic Versioning Deep Dive

Version Format: MAJOR.MINOR.PATCH
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)
Version Bump Decision Guide
Change TypeExamplesBump
Bug fix without changing behaviorNull check, off-by-onePATCH
Performance improvement (same API)Faster algorithm, cachingPATCH
Security patch (same API)Dependency update, input validationPATCH
New function, method, or endpointaddUser(), /api/v2/usersMINOR
New optional parametertimeout=30 defaultMINOR
Deprecation notice (still works)@deprecated annotationMINOR
Remove public function or methodDeleted addUser()MAJOR
Change function signatureDifferent parameter orderMAJOR
Change return type or default behaviorString to ObjectMAJOR
Drop runtime version supportDrop Node 16MAJOR
Pre-Release Version Strategy
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
Breaking Change Management
markdown
## 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 Management

Keep a Changelog Format
markdown
# 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]
Automated Changelog with Release Drafter
yaml
# .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
Conventional Commits
shell
# 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.

Automated Release Pipelines

Show full SKILL.md (143 more words)Show less
GitHub Actions Release Workflow
yaml
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 }
Multi-Platform Build and Release
yaml
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.txt

Release Branch Strategy

Git Flow for Releases
main (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
Release Checklist Script
shell
#!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"

Release Communication

Release Announcement Template
markdown
# [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
Rollback Procedure
markdown
## 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

Package Registry Best Practices

npm Publishing
json
{
  "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" }
}
shell
npm pack --dry-run          # Check included files
npm publish --dry-run       # Verify publish would succeed
PyPI Publishing
toml
# 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"}
yaml
# 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 }}

Output Format

template
## 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]

Edge Cases

  • 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

Example

Input: "Help me with release manager for my current situation"

Output:

Based on your situation, here is a structured approach to release manager:

  1. Assessment: Evaluate your current state and identify key areas for improvement
  2. Strategy: Develop a targeted plan based on best practices
  3. Implementation: Execute the plan with specific, measurable steps
  4. Review: Monitor progress and adjust as needed

© FerroxLabs, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in src/process/resources/skills-library/bodies/skills/software-engineering/release-manager of FerroxLabs/wayland.

Open the folder on GitHubat commit 4c030c7

Compare with similar skills

Release Manager next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Release Manager compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Release Manager this skillFerroxLabs/wayland608—~2.8kAutomated safety check: PassApache-2.0
Mole CLI Release Flowtw93/Mole69k—~2.5kAutomated safety check: PassGPL-3.0
Worktrunk Release Workflowmax-sixty/worktrunk8.9k—~6.9kAutomated safety check: PassCustom licence
Cline Desktop App Releasecline/cline70k—~4.5kAutomated safety check: PassApache-2.0
EverOS Release WorkflowEverMind-AI/EverOS13k—~1.3kAutomated safety check: PassApache-2.0
ReleaseXGHeaven/homebox817—~1.4kAutomated safety check: PassNone

Similar skills

  • Runbook for assessing and executing a Mole CLI release: distribution channels, pre-flight checks, capital-V tags, build artifacts and the handoff to curated release notes.

    69k GitHub stars~2.5k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Worktrunk Release Workflow

    max-sixty/worktrunk

    Walks a maintainer through cutting a Worktrunk release: sync the release branch, pass two test gates, review the changes, then publish.

    8.9k GitHub stars~6.9k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Covers preparing, tagging and publishing a Cline desktop app release on the stable, beta or nightly channel through the desktop-publish GitHub workflow.

    70k GitHub stars~4.5k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • EverOS Release Workflow

    EverMind-AI/EverOS

    Walks through cutting a versioned everos release: bump the version, update the changelog, tag it, and review the drafted GitHub Release page before publishing.

    13k GitHub stars~1.3k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Release

    XGHeaven/homebox

    Prepare, verify, and publish Homebox releases through the repository's tag-driven GitHub Actions workflow.

    817 GitHub stars~1.4k tokensUpdated 1 mo ago
    DevelopmentAuto-check passed
  • Coffee GB Release

    trekawek/coffee-gb

    Releases the current Coffee GB Maven snapshot through the GitHub Maven release workflow, then verifies and curates the tag and GitHub release.

    1.2k GitHub stars~1.4k tokensUpdated 6 days ago
    DevelopmentAuto-check passed

More from FerroxLabs/wayland

All 1,194 skills in this repo
  • Star Office Helper

    FerroxLabs/wayland

    Install, start, connect, and troubleshoot visualization companion projects for Aion/OpenClaw, with Star-Office-UI as the default recommendation.

    608 GitHub stars~2.2k tokensUpdated yesterday
    Auto-check: notes
  • Openclaw Setup

    FerroxLabs/wayland

    OpenClaw usage expert: Helps you install, deploy, configure, and use OpenClaw personal AI assistant.

    608 GitHub stars~1.9k tokensUpdated yesterday
    Auto-check passed
  • Tvcontrol Setup

    FerroxLabs/wayland

    Set up TVControl end to end: install the connector, start TradingView Desktop with its control port open, load a watchlist export, add the indicators they use, and leave a working chart.

    608 GitHub stars~5.7k tokensUpdated yesterday
    Auto-check passed
  • Ab Testing Specialist

    FerroxLabs/wayland

    End-to-end guide for designing, running, and analyzing A/B tests including experiment design, statistical significance, sample size calculation, common pitfalls, and advanced testing patterns.

    608 GitHub stars~3.7k tokensUpdated yesterday
    Auto-check passed
  • Academic Writer

    FerroxLabs/wayland

    Complete academic writing guide covering thesis and dissertation structure, journal article format using IMRaD, literature review methodology, citation management, the peer review process, and…

    608 GitHub stars~4.5k tokensUpdated yesterday
    Auto-check passed
  • Accessibility Auditor

    FerroxLabs/wayland

    Web accessibility expertise covering WCAG 2.2 conformance, audit methodology, ARIA patterns, keyboard navigation, screen reader testing, focus management, form accessibility, and automated vs manual…

    608 GitHub stars~4.1k tokensUpdated yesterday
    Auto-check passed

Questions about Release Manager

What does Release Manager do?

Master semantic versioning, changelog generation, automated release pipelines, and CI/CD workflows for open source project releases Use when the user asks about release manager, related techniques…. Release Manager is an agent skill from FerroxLabs/wayland. Master semantic versioning, changelog generation, automated release pipelines, and CI/CD workflows for open source project releases Use when the user asks about release manager, related techniques, best practices, or needs guidance in this domain.

When should I use Release Manager?

Release Manager fits situations like: the user asks about release manager; related techniques; needs guidance in this domain; the request is outside the scope of release manager.

How do I install Release Manager in Claude Code?

Run `npx skills add FerroxLabs/wayland --skill release-manager -a claude-code`. Or copy the skill folder (src/process/resources/skills-library/bodies/skills/software-engineering/release-manager in FerroxLabs/wayland) into .claude/skills/release-manager in your project. Claude Code loads it when a task matches its description.

How do I install Release Manager in Codex?

Run `npx skills add FerroxLabs/wayland --skill release-manager -a codex`. Or copy the skill folder (src/process/resources/skills-library/bodies/skills/software-engineering/release-manager in FerroxLabs/wayland) into .agents/skills/release-manager in your project. Codex loads it when a task matches its description.

Can I use Release Manager in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add FerroxLabs/wayland --skill release-manager -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/release-manager, .gemini/skills/release-manager, .github/skills/release-manager and .opencode/skills/release-manager in your project.

What does Release Manager need to run?

Going by SKILL.md and its folder, Release Manager needs the command-line tools its instructions call (npm and git) and credentials named NODE_AUTH_TOKEN, NPM_TOKEN and PYPI_TOKEN. Our summary lists: Python 3; Node.js; A credential in NODE_AUTH_TOKEN; A credential in NPM_TOKEN.

Does Release Manager access the network?

SKILL.md contains no URLs. Its commands use npm and git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Release Manager safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Release Manager use?

Release Manager is published under the Apache-2.0 licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Release Manager use?

About 2.8k tokens (SKILL.md is roughly 11k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Release Manager?

Skills that share tags, products or a category with Release Manager: Mole CLI Release Flow (tw93/Mole, 69k stars), Worktrunk Release Workflow (max-sixty/worktrunk, 8.9k stars), Cline Desktop App Release (cline/cline, 70k stars) and EverOS Release Workflow (EverMind-AI/EverOS, 13k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Release Manager?

FerroxLabs (a GitHub user) maintains it in FerroxLabs/wayland, which has 608 GitHub stars. The repository holds 1,194 skills in this directory. The repository was last updated on October 6, 2026.

Source: FerroxLabs/wayland on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.