Release Skills
Ship a versioned release with bumped manifests, changelog entries, tags, and optional GitHub Releases without hand-rolling steps per stack.
Overview
release-skills is an agent skill most often used in Ship (also Build, Operate) that runs a stack-aware release workflow with auto-detected version files, changelogs, tags, and GitHub Releases.
Install
npx skills add https://github.com/jimliu/baoyu-skills --skill release-skillsWhat is this skill?
- Auto-detects version sources for Node (package.json), Python (pyproject.toml), and Rust (Cargo.toml)
- Supports Claude Plugin releases, annotated Git tags, GitHub Releases, and historical release backfill
- Multi-language changelog workflow with batched user prompts via runtime AskUserQuestion equivalents
- Triggered by release intent in English or Chinese (发布, bump version, release notes, 回填 Release)
- Runs from `/release-skills` with project-type detection so generic repos still get a guided path
- Auto-detects three primary manifest types: package.json, pyproject.toml, and Cargo.toml
- Supports Claude Plugin, GitHub Releases, annotated tags, and historical release backfill
Adoption & trust: 19.5k installs on skills.sh; 20.9k GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are ready to ship but each repo uses a different version file, changelog style, and tagging habit, so releases become error-prone one-offs.
Who is it for?
Solo builders cutting semver releases across Node, Python, Rust, or plugin repos who want one guided ritual instead of copy-pasting release checklists.
Skip if: Teams that only need a local commit without versioning, or repos with fully custom release automation you do not want the agent to touch.
When should I use this skill?
User says release, 发布, new version, bump version, push, 推送, release notes, GitHub Release, or 回填 Release.
What do I get? / Deliverables
You get a consistent bump-and-publish path with updated version metadata, release notes, and git or GitHub Release actions aligned to your detected project type.
- Updated version manifest
- Changelog or release notes entry
- Git tag and/or GitHub Release publish steps completed
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Release is the canonical moment you cut a version and push artifacts—this skill automates that ship-phase ritual across project types. Launch prep under Ship is where version bumps, release notes, and tagged pushes happen before users see the build.
Where it fits
After merging a feature branch, bump package.json and draft release notes before tagging.
Cut v1.2.0 with changelog, annotated tag, and GitHub Release in one guided session.
Backfill missing GitHub Releases for older tags so support and users see a complete history.
How it compares
Use instead of ad-hoc chat instructions for git tag and changelog steps—it is a packaged release workflow, not a CI host replacement.
Common Questions / FAQ
Who is release-skills for?
Indie and solo developers shipping from Claude Code, Cursor, Codex, or similar agents who own versioning and GitHub Releases themselves.
When should I use release-skills?
Use it in Ship when you say release, new version, or GitHub Release; in Build when you finalize a version bump before merge; and in Operate when you backfill or align historical releases on an existing repo.
Is release-skills safe to install?
It drives git pushes and release publishing—review the Security Audits panel on this page and confirm remotes and tokens before allowing network or git actions.
SKILL.md
READMESKILL.md - Release Skills
# Release Skills Universal release workflow supporting any project type with multi-language changelog. ## User Input Tools When this skill prompts the user, follow this tool-selection rule (priority order): 1. **Prefer built-in user-input tools** exposed by the current agent runtime — e.g., `AskUserQuestion`, `request_user_input`, `clarify`, `ask_user`, or any equivalent. 2. **Fallback**: if no such tool exists, emit a numbered plain-text message and ask the user to reply with the chosen number/answer for each question. 3. **Batching**: if the tool supports multiple questions per call, combine all applicable questions into a single call; if only single-question, ask them one at a time in priority order. Concrete `AskUserQuestion` references below are examples — substitute the local equivalent in other runtimes. ## Quick Start Just run `/release-skills` - auto-detects your project configuration. ## Supported Projects | Project Type | Version File | Auto-Detected | |--------------|--------------|---------------| | Node.js | package.json | ✓ | | Python | pyproject.toml | ✓ | | Rust | Cargo.toml | ✓ | | Claude Plugin | marketplace.json | ✓ | | Generic | VERSION / version.txt | ✓ | ## Options | Flag | Description | |------|-------------| | `--dry-run` | Preview changes without executing | | `--major` | Force major version bump | | `--minor` | Force minor version bump | | `--patch` | Force patch version bump | | `--backfill-releases` | Create missing GitHub Releases for existing tags from changelog sections | ## Workflow ### Step 1: Detect Project Configuration 1. Check for `.releaserc.yml` (optional config override) - If present, inspect whether it defines release hooks 2. Auto-detect version file by scanning (priority order): - `package.json` (Node.js) - `pyproject.toml` (Python) - `Cargo.toml` (Rust) - `marketplace.json` or `.claude-plugin/marketplace.json` (Claude Plugin) - `VERSION` or `version.txt` (Generic) 3. Scan for changelog files using glob patterns: - `CHANGELOG*.md` - `HISTORY*.md` - `CHANGES*.md` 4. Identify language of each changelog by filename suffix 5. Detect GitHub release support: - Check whether `origin` points to GitHub - Check whether `gh` is installed and authenticated - Check existing releases with `gh release list --limit 5` when available 6. Display detected configuration **Project Hook Contract**: If `.releaserc.yml` defines `release.hooks`, keep the release workflow generic and delegate project-specific packaging/publishing to those hooks. Supported hooks: | Hook | Purpose | Expected Responsibility | |------|---------|-------------------------| | `prepare_artifact` | Make one target releasable | Validate the target is self-contained, sync/embed local dependencies, optionally stage extra files | | `publish_artifact` | Publish one releasable target | Upload the prepared target (or a staged directory if the project uses one), attach version/changelog/tags | Supported placeholders: | Placeholder | Meaning | |-------------|---------| | `{project_root}` | Absolute path to repository root | | `{target}` | Absolute path to the module/skill being released | | `{artifact_dir}` | Absolute path to a temporary staging directory for this target, when the project uses one | | `{version}` | Version selected by the release workflow | | `{dry_run}` | `true` or `false` | | `{release_notes_file}` | Absolute path to a UTF-8 file containing release notes/changelog text | Execution rules: - Keep the skill generic: do not hardcode registry/package-manager/project layout details into this SKILL. - If