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

Options

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:

Supported placeholders:

Execution rules:

• Keep the skill generic: do not hardcode registry/package-manager/project layout details into this SKILL.
• If prepare_artifact exists, run it once per target before publish-related checks that need the final releasable target state.
• Write release notes to a temp file and pass that file path to publish_artifact; do not inline multiline changelog text into shell commands.
• If hooks are absent, fall back to the default project-agnostic release workflow.

Language Detection Rules:

Changelog files follow the pattern CHANGELOG_{LANG}.md or CHANGELOG.{lang}.md, where {lang} / {LANG} is a language or region code.

Common language codes: zh (Chinese), ja (Japanese), ko (Korean), de (German), fr (French), es (Spanish).

Output Example:

Project detected:
  Version file: package.json (1.2.3)
  Changelogs:
    - CHANGELOG.md (en)
    - CHANGELOG.zh.md (zh)
    - CHANGELOG.ja.md (ja)

Step 2: Analyze Changes Since Last Tag

LAST_TAG=$(git tag --sort=-v:refname | head -1)
git log ${LAST_TAG}..HEAD --oneline
git diff ${LAST_TAG}..HEAD --stat

Categorize by conventional commit types:

Breaking Change Detection:

• Commit message starts with BREAKING CHANGE
• Commit body/footer contains BREAKING CHANGE:
• Removed public APIs, renamed exports, changed interfaces

If breaking changes detected, warn user: "Breaking changes detected. Consider major version bump (--major flag)."

Step 3: Determine Version Bump

Rules (in priority order):

1. User flag --major/--minor/--patch → Use specified
2. BREAKING CHANGE detected → Major bump (1.x.x → 2.0.0)
3. feat: commits present → Minor bump (1.2.x → 1.3.0)
4. Otherwise → Patch bump (1.2.3 → 1.2.4)

Display version change: 1.2.3 → 1.3.0

Step 4: Generate Multi-language Changelogs

For each detected changelog file:

1. Identify language from filename suffix
2. Detect third-party contributors:
   • Check merge commits: git log ${LAST_TAG}..HEAD --merges --pretty=format:"%H %s"
   • For each merged PR, identify the PR author via gh pr view <number> --json author --jq '.author.login'
   • Compare against repo owner (gh repo view --json owner --jq '.owner.login')
   • If PR author ≠ repo owner → third-party contributor
3. Generate content in that language:
   • Section titles in target language
   • Change descriptions written naturally in target language (not translated)
   • Date format: YYYY-MM-DD (universal)
   • Third-party contributions: Append contributor attribution (by @username) to the changelog entry
4. Insert at file head (preserve existing content)

Section Title Translations (built-in):

Changelog Format:

## {VERSION} - {YYYY-MM-DD}

### Features
- Description of new feature
- Description of third-party contribution (by @username)

### Fixes
- Description of fix

### Documentation
- Description of docs changes

Only include sections that have changes. Omit empty sections.

Third-Party Attribution Rules:

• Only add (by @username) for contributors who are NOT the repo owner
• Use GitHub username with @ prefix
• Place at the end of the changelog entry line
• App