Universal Project Release Workflow

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
• Apply to all languages consistently (always use (by @username) format, not translated)

Multi-language Example:

English (CHANGELOG.md):

## 1.3.0 - 2026-01-22

### Features
- Add user authentication module (by @contributor1)
- Support OAuth2 login

### Fixes
- Fix memory leak in connection pool

Chinese (CHANGELOG.zh.md):

## 1.3.0 - 2026-01-22

### 新功能
- 新增用户认证模块 (by @contributor1)
- 支持 OAuth2 登录

### 修复
- 修复连接池内存泄漏问题

Japanese (CHANGELOG.ja.md):

## 1.3.0 - 2026-01-22

### 新機能
- ユーザー認証モジュールを追加 (by @contributor1)
- OAuth2 ログインをサポート

### 修正
- コネクションプールのメモリリークを修正

Step 5: Group Changes by Skill/Module

Analyze commits since last tag and group by affected skill/module:

1. Identify changed files per commit
2. Group by skill/module:
   • skills/<skill-name>/* → Group under that skill
   • Root files (CLAUDE.md, etc.) → Group as "project"
   • Multiple skills in one commit → Split into multiple groups
3. For each group, identify related README updates needed

Example Grouping:

baoyu-cover-image:
  - feat: add new style options
  - fix: handle transparent backgrounds
  → README updates: options table

baoyu-comic:
  - refactor: improve panel layout algorithm
  → No README updates needed

project:
  - docs: update CLAUDE.md architecture section

Step 6: Commit Each Skill/Module Separately

For each skill/module group (in order of changes):

1. Check README updates needed:

   • Scan README*.md for mentions of this skill/module
   • Verify options/flags documented correctly
   • Update usage examples if syntax changed
   • Update feature descriptions if behavior changed

2. Stage and commit:

   git add skills/<skill-name>/*
   git add README.md README.zh.md  # If updated for this skill
   git commit -m "<type>(<skill-name>): <meaningful description>"

3. Commit message format:

   • Use conventional commit format: <type>(<scope>): <description>
   • <type>: feat, fix, refactor, docs, perf, etc.
   • <scope>: skill name or "project"
   • <description>: Clear, meaningful description of changes

Example Commits:

git commit -m "feat(baoyu-cover-image): add watercolor and minimalist styles"
git commit -m "fix(baoyu-comic): improve panel layout for long dialogues"
git commit -m "docs(project): update architecture documentation"

Common README Updates Needed: