release-skills

リリーススキル

多言語の変更履歴に対応した、あらゆるプロジェクトタイプで利用できる汎用リリースワークフローです。

ユーザー入力ツール

このスキルがユーザーに入力を求める場合は、以下の優先順位に従ってツールを選択してください。

1. 組み込みのユーザー入力ツールを優先してください。現在のエージェントランタイムが提供する AskUserQuestion、request_user_input、clarify、ask_user、または同等のツールなどが該当します。
2. フォールバック：そのようなツールがない場合は、番号付きのプレーンテキストメッセージを出力し、質問ごとに選んだ番号または回答を返すようユーザーに依頼してください。
3. まとめて質問：ツールが1回の呼び出しで複数の質問に対応している場合は、該当する質問をすべてまとめて呼び出してください。1回に1つの質問しかできない場合は、優先順位に従って1つずつ質問してください。

以下の AskUserQuestion に関する具体例は、あくまで参考です。他のランタイムでは、その環境に対応するツールに置き換えてください。

クイックスタート

/release-skills を実行するだけで、プロジェクトの設定が自動検出されます。

対応プロジェクト

プロジェクトタイプ	バージョンファイル	自動検出
Node.js	package.json	✓
Python	pyproject.toml	✓
Rust	Cargo.toml	✓
Claude Plugin	marketplace.json	✓
汎用	VERSION / version.txt	✓

オプション

フラグ	説明
--dry-run	実行せずに変更内容をプレビューします
--major	メジャーバージョンの更新を強制します
--minor	マイナーバージョンの更新を強制します
--patch	パッチバージョンの更新を強制します
--backfill-releases	変更履歴のセクションを基に、既存のタグに対する不足している GitHub Releases を作成します

ワークフロー

ステップ 1：プロジェクト設定の検出

1. .releaserc.yml（任意の設定オーバーライド）があるか確認します
   • 存在する場合は、リリースフックが定義されているか確認します
2. 優先順位に従ってスキャンし、バージョンファイルを自動検出します：
   • package.json（Node.js）
   • pyproject.toml（Python）
   • Cargo.toml（Rust）
   • marketplace.json または .claude-plugin/marketplace.json（Claude Plugin）
   • VERSION または version.txt（汎用）
3. glob パターンを使用して、変更履歴ファイルをスキャンします：
   • CHANGELOG*.md
   • HISTORY*.md
   • CHANGES*.md
4. ファイル名のサフィックスから各変更履歴ファイルの言語を特定します
5. GitHub リリースへの対応状況を検出します：
   • origin が GitHub を指しているか確認します
   • gh がインストールされ、認証済みか確認します
   • 利用可能な場合は、gh release list --limit 5 で既存のリリースを確認します
6. 検出した設定を表示します

プロジェクトフックの契約：

.releaserc.yml に release.hooks が定義されている場合は、リリースワークフローを汎用的なままにし、プロジェクト固有のパッケージ化／公開処理をこれらのフックに委譲します。

サポートされているフック：

フック	目的	想定される役割
prepare_artifact	リリース対象を 1 つ準備する	対象が自己完結していることを検証し、ローカル依存関係を同期／埋め込み、必要に応じて追加ファイルをステージングする
publish_artifact	リリース対象を 1 つ公開する	準備した対象（またはプロジェクトで使用する場合はステージング済みディレクトリ）をアップロードし、バージョン／変更履歴／タグを付与する

サポートされているプレースホルダー：

プレースホルダー	意味
{project_root}	リポジトリルートの絶対パス
{target}	リリース対象となるモジュール／スキルの絶対パス
{artifact_dir}	プロジェクトで使用する場合、この対象用の一時ステージングディレクトリの絶対パス
{version}	リリースワークフローで選択されたバージョン
{dry_run}	true または false
{release_notes_file}	リリースノート／変更履歴のテキストを含む UTF-8 ファイルの絶対パス

実行ルール：

• スキルは汎用的な状態に保ち、レジストリ／パッケージマネージャー／プロジェクト構成の詳細をこの SKILL にハードコードしないでください。
• prepare_artifact が存在する場合は、最終的なリリース対象の状態を必要とする公開関連の確認を行う前に、対象ごとに 1 回実行します。
• リリースノートは一時ファイルに書き込み、そのファイルパスを publish_artifact に渡します。複数行の変更履歴テキストをシェルコマンドに直接埋め込まないでください。
• フックがない場合は、デフォルトのプロジェクト非依存リリースワークフローにフォールバックします。

言語検出ルール：

変更履歴ファイルは CHANGELOG_{LANG}.md または CHANGELOG.{lang}.md のパターンに従います。{lang}／{LANG} は言語コードまたは地域コードです。

パターン	例	言語
サフィックスなし	CHANGELOG.md	en（デフォルト）
_{LANG}（大文字）	CHANGELOG_CN.md、CHANGELOG_JP.md	対応する言語
.{lang}（小文字）	CHANGELOG.zh.md、CHANGELOG.ja.md	対応する言語
.{lang-region}	CHANGELOG.zh-CN.md	対応する地域バリアント

一般的な言語コード：zh（中国語）、ja（日本語）、ko（韓国語）、de（ドイツ語）、fr（フランス語）、es（スペイン語）。

出力例：

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

ステップ 2：前回のタグ以降の変更を分析

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

Conventional Commit のタイプ別に分類します：

タイプ	説明
feat	新機能
fix	バグ修正
docs	ドキュメント
refactor	コードのリファクタリング
perf	パフォーマンスの改善
test	テストの変更
style	書式、スタイル
chore	メンテナンス（変更履歴では省略）

破壊的変更の検出：

• コミットメッセージが BREAKING CHANGE で始まる
• コミット本文／フッターに BREAKING CHANGE: が含まれる
• 公開 API の削除、エクスポート名の変更、インターフェースの変更

破壊的変更が検出された場合は、ユーザーに警告します：「破壊的変更が検出されました。メジャーバージョンの更新を検討してください（--major フラグ）。」

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):

Type	en	zh	ja	ko	de	fr	es
feat	Features	新功能	新機能	새로운 기능	Funktionen	Fonctionnalités	Características
fix	Fixes	修复	修正	수정	Fehlerbehebungen	Corrections	Correcciones
docs	Documentation	文档	ドキュメント	문서	Dokumentation	Documentation	Documentación
refactor	Refactor	重构	リファクタリング	리팩토링	Refactoring	Refactorisation	Refactorización
perf	Performance	性能优化	パフォーマンス	성능	Leistung	Performance	Rendimiento
breaking	Breaking Changes	破坏性变更	破壊的変更	주요 변경사항	Breaking Changes	Changements majeurs	Cambios importantes

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:

Change Type	README Section to Check
New options/flags	Options table, usage examples
Renamed options	Options table, usage examples
New features	Feature description, examples
Breaking changes	Migration notes, deprecation warnings
Restructured internals	Architecture section (if exposed to users)

ステップ 7：変更履歴を生成してバージョンを更新する

1. 多言語の変更履歴を生成する（ステップ 4 の説明を参照）
2. バージョンファイルを更新する：
   • バージョンファイルを読み取ります（JSON／TOML／テキスト）
   • バージョン番号を更新します
   • 書式を維持して書き戻します
3. リリースノートファイルを作成する：
   • CHANGELOG.md の新しいバージョンのセクションを優先します
   • 英語／デフォルトの変更履歴がない場合は、最初に検出された変更履歴を使用します
   • 次の ## までの ## {VERSION} - {YYYY-MM-DD} セクションだけを正確に抽出します
   • 必要に応じて、通常のバージョンとタグ接頭辞付きの見出しの両方に一致させます（例：1.2.3 と v1.2.3）
   • 破壊的変更を上部に配置します。必要に応じて、他のセクションの前に短いハイライトを追加します
   • ノートを UTF-8 の一時ファイルに書き込み、注釈付きタグのメッセージ、GitHub Releases、publish_artifact で再利用します
   • 通常モードでは、ノートが見つからない場合、空のタグや GitHub Release を作成せずに停止します

ファイル形式ごとのバージョンパス：

ファイル	パス
package.json	$.version
pyproject.toml	project.version
Cargo.toml	package.version
marketplace.json	$.metadata.version
VERSION / version.txt	直接の内容

ステップ 8：ユーザーの確認

リリースコミットを作成する前に、ユーザーに確認を求めます。

3 つの質問で AskUserQuestion を使用します：

1. バージョンの更新（単一選択）：

   • ステップ 3 の分析に基づく推奨バージョンを表示します
   • 選択肢：推奨（ラベル付き）、その他のセマンティックバージョニングの選択肢
   • 例：1.2.3 → 1.3.0 (Recommended)、1.2.3 → 1.2.4、1.2.3 → 2.0.0

2. リモートにプッシュする（単一選択）：

   • 選択肢：「はい、コミット後にプッシュする」、「いいえ、ローカルのみにする」

3. GitHub Release を公開する（単一選択）：

   • GitHub Release に対応している場合のみ提示します
   • ユーザーがプッシュも選択した場合、デフォルトは「はい、タグのプッシュ後に公開する」です
   • ユーザーがリリースをローカルに保持する場合は、GitHub Release を作成または編集しません

確認前の出力例：

Commits created:
  1. feat(baoyu-cover-image): add watercolor and minimalist styles
  2. fix(baoyu-comic): improve panel layout for long dialogues
  3. docs(project): update architecture documentation

Changelog preview (en):
  ## 1.3.0 - 2026-01-22
  ### Features
  - Add watercolor and minimalist styles to cover-image
  ### Fixes
  - Improve panel layout for long dialogues in comic

Release notes source: CHANGELOG.md#1.3.0
Ready to create release commit, annotated tag, and GitHub Release.

ステップ 9：リリースコミットと注釈付きタグを作成する

ユーザーの確認後：

1. バージョンファイルと変更履歴ファイルをステージングする：

   git add <version-file>
   git add CHANGELOG*.md
   

2. リリースコミットを作成する：

   git commit -m "chore: release v{VERSION}"
   

3. 注釈付きタグを作成する：

   git tag -a v{VERSION} -F <release-notes-file>
   

   .releaserc.yml で tag.sign: true が設定されている場合は、同じノートファイルを使って git tag -s を使用します。

4. ユーザーが確認した場合にプッシュする（ステップ 8）：

   git push origin main
   git push origin v{VERSION}
   

注：Co-Authored-By 行は追加しないでください。これはリリースコミットであり、コードへの貢献ではありません。

ステップ 10：リリース成果物と GitHub Release を公開する

プロジェクトの成果物公開と GitHub Releases は別々の出力です。

1. プロジェクトの成果物：

   • release.hooks.publish_artifact が存在する場合、準備されたターゲットごとに 1 回実行します
   • タグと GitHub Release に使用したものと同じ {release_notes_file} を渡します
   • ドライランモードでは {dry_run}=true を渡し、公開される内容を報告します

2. GitHub Release：

   • ユーザーがリモートへの公開を確認しており、GitHub に対応している場合のみ実行します
   • リリースを作成する前に、タグがリモートに存在することを確認します
   • 抽出したノートを使って作成または更新します：

     if gh release view v{VERSION} >/dev/null 2>&1; then
       gh release edit v{VERSION} --title "v{VERSION}" --notes-file <release-notes-file>
     else
       gh release create v{VERSION} --title "v{VERSION}" --notes-file <release-notes-file> --verify-tag
     fi
     

   • 複数行のリリースノートをシェルコマンドに直接埋め込まないでください

リリース後の出力：

Release v1.3.0 created.

Commits:
  1. feat(baoyu-cover-image): add watercolor and minimalist styles
  2. fix(baoyu-comic): improve panel layout for long dialogues
  3. docs(project): update architecture documentation
  4. chore: release v1.3.0

Tag: v1.3.0
Tag type: annotated
GitHub Release: published  # or "skipped/local only"
Status: Pushed to origin  # or "Local only - run git push when ready"

既存の GitHub リリースを補完する

ユーザーから過去のリリースを補完するよう依頼された場合、または --backfill-releases が渡された場合に、このモードを使用します。

1. バージョンを変更したり、変更履歴を編集したり、リリースコミットを作成したりしないでください。
2. 既存のタグをバージョン順に一覧表示し、リリースが欠落しているかを確認します：

   git tag --sort=v:refname
   gh release view <tag>
   

3. GitHub Release がないタグごとに、次の処理を行います：
   • 設定済みのタグプレフィックスを取り除いて、変更履歴を検索するバージョンを正規化します。例：v1.2.3 -> 1.2.3
   • CHANGELOG.md から該当するセクションを抽出します。見つからない場合は、最初に該当した変更履歴ファイルを使用します。
   • 該当する変更履歴セクションがない場合は、公開をスキップするか、公開前に確認します。
   • 次のコマンドでリリースを作成します：

     gh release create <tag> --title "<tag>" --notes-file <release-notes-file> --verify-tag
     

4. git cat-file -t <tag> で軽量タグを確認します（commit は軽量タグ、tag は注釈付きタグを意味します）。
5. デフォルトでは、公開済みの軽量タグを書き換えないでください。既存のリモートタグを注釈付きタグに変換するには、公開済みの参照を書き換えるため、ユーザーの明示的な確認が必要です。

設定（.releaserc.yml）

プロジェクトのルートに配置して、デフォルト設定を上書きする任意の設定ファイル：

# .releaserc.yml - Optional configuration

# Version file (auto-detected if not specified)
version:
  file: package.json
  path: $.version  # JSONPath for JSON, dotted path for TOML

# Changelog files (auto-detected if not specified)
changelog:
  files:
    - path: CHANGELOG.md
      lang: en
    - path: CHANGELOG.zh.md
      lang: zh
    - path: CHANGELOG.ja.md
      lang: ja

  # Section mapping (conventional commit type → changelog section)
  # Use null to skip a type in changelog
  sections:
    feat: Features
    fix: Fixes
    docs: Documentation
    refactor: Refactor
    perf: Performance
    test: Tests
    chore: null

# Commit message format
commit:
  message: "chore: release v{version}"

# Tag format
tag:
  prefix: v  # Results in v1.0.0
  sign: false

# Additional files to include in release commit
include:
  - README.md
  - package.json

ドライランモード

--dry-run が指定されている場合：

=== DRY RUN MODE ===

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

Last tag: v1.2.3
Proposed version: v1.3.0

Changes grouped by skill/module:
  baoyu-cover-image:
    - feat: add watercolor style
    - feat: add minimalist style
    → Commit: feat(baoyu-cover-image): add watercolor and minimalist styles
    → README updates: options table

  baoyu-comic:
    - fix: panel layout for long dialogues
    → Commit: fix(baoyu-comic): improve panel layout for long dialogues
    → No README updates

Changelog preview (en):
  ## 1.3.0 - 2026-01-22
  ### Features
  - Add watercolor and minimalist styles to cover-image
  ### Fixes
  - Improve panel layout for long dialogues in comic

Changelog preview (zh):
  ## 1.3.0 - 2026-01-22
  ### 新功能
  - 为 cover-image 添加水彩和极简风格
  ### 修复
  - 改进 comic 长对话的面板布局

Commits to create:
  1. feat(baoyu-cover-image): add watercolor and minimalist styles
  2. fix(baoyu-comic): improve panel layout for long dialogues
  3. chore: release v1.3.0

No changes made. Run without --dry-run to execute.

使用例

/release-skills              # Auto-detect version bump
/release-skills --dry-run    # Preview only
/release-skills --minor      # Force minor bump
/release-skills --patch      # Force patch bump
/release-skills --major      # Force major bump (with confirmation)
/release-skills --backfill-releases  # Create missing GitHub Releases for existing tags

使用する場面

ユーザーから次のような依頼があった場合に、このスキルを実行します：

• "release"、"发布"、"create release"、"new version"、"新版本"
• "bump version"、"update version"、"更新版本"
• "prepare release"
• "release notes"、"GitHub Release"、"回填 Release"
• 未コミットの変更がある状態での "push to remote"

重要：未コミットの変更がある状態で、ユーザーが「そのまま push」または「直接 push」と言った場合も、まず上記のすべての手順に従ってください。