bump-release

リリースのバージョンを更新

これらの手順がスラッシュまたはドル記号による呼び出しですでに会話に含まれている場合は、そのまま従ってください。 スキルツールを使って、このスキルを再度呼び出さないでください。

バージョン更新、変更履歴の記載、コミット、タグ付けを行い、1 つまたは複数のパッケージをリリースします。 単一パッケージのリポジトリ、ワークスペース型モノレポ、安定版リリース、ベータ版リリース、ドライランに対応しています。

引数

• packages：任意のパッケージ名またはディレクトリ。単一パッケージのリポジトリでは省略します。
• version：任意の明示的な semver。ユーザーが選択したパッケージが 1 つの場合にのみ有効です。
• --beta：-beta.X のプレリリースを作成または更新します。
• --dry-run：ファイルの変更、コミット、タグ付けを行わずにプレビューします。

ヘルパーインターフェース

この SKILL.md から <skill-dir> を解決します。ヘルパーの標準出力は JSON のままにし、診断情報は標準エラー出力に出力します。

node "<skill-dir>/scripts/plan-release.mjs" \
  [--cwd <repo>] [--beta] [--dry-run] [--version <semver>] \
  [--package <name-or-dir>]...

読み取り専用の検出出力には schemaVersion: 2 が含まれます。パッケージの識別情報、パッケージごとの変更ファイルの全件、ワークスペースの依存関係と宣言された範囲、以前のタグに関する情報、選択された対象、ワークツリーの状態が報告されます。changeHints はファイル名に基づく、権威のないナビゲーション用のヒントです。リリースとの関連性や変更履歴への記載を判断するために、決して使用しないでください。

エージェントがすべての安定版のパッチ／マイナー／メジャーバージョンを決定した後、検出結果の JSON を一時ファイルに書き込み、次を実行します。

uv run "<skill-dir>/scripts/finalize-release-plan.py" \
  --discovery <discovery.json> \
  [--version <package>=<semver>]...

ファイナライザーは、ベータ版および明示的なバージョンへの移行、安定版プレリリースの昇格、npm の範囲指定への適合、単純な依存関係の範囲指定の提案、依存関係の順序付けを行います。複雑な範囲指定、peer の範囲指定、依存関係の循環、エージェントから提示されていない安定版のバージョンは、未解決の判断事項として報告されます。満たされていない依存関係によって依存元パッケージが追加された場合、そのパッケージのリリースバージョンを選択し、別の --version 指定を加えて再実行してください。ファイナライザーが通常のリリースのバージョン区分や依存関係のポリシーを選択することはありません。

作成した安定版の変更履歴ごとに、決定的な構造を検証します。

uv run "<skill-dir>/scripts/validate-changelog.py" \
  --file <CHANGELOG.md> --version <semver> --date <YYYY-MM-DD> [--tag <tag>]

リリースと日付、見出し／カテゴリの順序、許可されているカテゴリ、リスト構造、リリースリンクのタグが期待どおりかを確認します。重要度、表現、意味上のカテゴリは評価しません。

ワークフロー

1. ユーザーの引数をそのままマッピングしてディスカバリーを実行します。終了コード 2 は対象がリリース可能な Git／パッケージリポジトリではないことを示し、終了コード 64 は入力が無効であることを示します。いずれの場合も中止します。

2. workingTree.clean を必須とします。無関係な作業を取り込みません。

3. 不明または曖昧なパッケージ選択を解決します。ユーザーが明示したバージョンは、単一パッケージにのみ適用します。

4. 各対象の changedFiles 全体と、直前のタグからの正味の差分を確認します。残る変更がリリースに値するかを判断します。実行環境、リファクタリング、ドキュメント、テスト、ツールはいずれも、文脈によっては関連する場合があります。ファイル名だけで判断してはいけません。

5. 明示的なバージョンが指定されていない、関連するすべての安定版対象について、利用者向けの変更内容に基づいてパッチ、マイナー、メジャーのいずれかを選択します。ベータ版リリースでは、最終処理ツールに機械的な移行を計算させます。

6. 最終処理ツールを実行します。未解決のワークスペース依存関係を確認します。単純な依存関係の範囲で、そのポリシーが適切な場合に限り、提案を受け入れます。ピア依存関係と複雑な範囲のポリシーは明示的に選択します。依存パッケージと、エージェントが選んだリリースバージョンを追加し、パッケージの集合と依存関係の順序が確定するまで再実行します。

7. ドライランの場合は、パッケージ／バージョンの順序付き計画、範囲の編集、変更履歴／タグ／コミットの操作、エージェントが判断したスキップを報告します。書き込み前に停止します。

8. 安定版リリースの場合は、references/common-changelog.md を読み、範囲を限定した正味の差分から利用者向けの項目を作成します。項目の選定、表現、重要度、カテゴリはエージェントが決定します。ベータ版リリースでは変更履歴を更新しません。

9. マニフェストと、受け入れた依存関係の範囲を更新します。すべての安定版の変更履歴をヘルパーで検証します。

10. リポジトリで確立されている最も対象を絞ったコマンドを使い、書式設定を一度だけ実行します。

11. 依存パッケージを依存先パッケージより先にコミットしてタグ付けします。パッケージごとにコミットと注釈付きタグを1つずつ使用します。

    • 単一パッケージのコミット：docs: release <version>。
    • モノレポのコミット：docs: release <package> <version>。
    • 単一パッケージのタグ：確認できた v<version> またはバージョンのみの形式に従います。
    • モノレポのタグ：確認できたパッケージタグの形式に従い、既定では <package-dir>@<version> を使用します。

12. プッシュしません。成功後、この実行で作成したタグだけを含む正確な git push origin <tag>... コマンドを推奨します。--tags は使用しません。

13. 最終報告の前に、.github/workflows/ を調べ、プッシュされたタグから GitHub リリースを作成または公開する有効なワークフローがあるか確認します。release.yml のようなファイル名は手がかりであり、証拠ではありません。$cli-gh を読み取り専用で使用し、このリポジトリに維持されている GitHub リリースの確立された履歴があるかを確認します。履歴がある場合は、次のルールに従い、ユーザーの承認を得たうえで、新しいタグごとに GitHub リリースを作成することを提案します。

    • タグが1つで、リリース CI がある場合：手動でのリリース作成は提案しません。タグのプッシュで CI が起動するはずです。
    • タグが1つで、リリース CI がない場合：$cli-gh でリリースを作成することを提案します。
    • 複数のタグをまとめてプッシュする場合：リリース CI があっても、$cli-gh でタグごとに1つのリリースを作成することを提案します。複数タグのプッシュでは、その自動化が確実に起動するとは限らないためです。

    ユーザーの承認なしに GitHub リリースを作成してはいけません。リリース履歴を確認できない場合は不明と報告し、書き込みを提案しません。

安全性と完了

ヘルパーの失敗は、不正な入力、不変条件への違反、または検証の失敗を意味します。エージェントの判断が未解決のままであることは、JSON 内のデータであり、ヘルパーの失敗ではありません。ディスカバリーとドライランは読み取り専用です。最終的に安定したパッケージセットが確定する前に変更履歴を書き込まないでください。また、ディスカバリーで報告された確認済みの事実からタグの規則を推測しないでください。

ドライランの完了には、ディスカバリーに基づきエージェントがレビューしたアクションプレビューと、書き込みが一切ないことが必要です。リリースの完了には、検証済みのマニフェストと安定した変更履歴、フォーマット、依存関係の順にパッケージごとに作成された1つのコミットと注釈付きタグ、作成したコミット／タグ、エージェントが判断したスキップ、正確なタグのプッシュコマンド、および該当する場合は GitHub リリースの提案を記載したレポートが必要です。

該当する場合は、### ⛔ Release stopped — working tree is not clean、### ⚠️ Confirm release plan、### 🔎 Release preview — no files, commits, or tags written、または ### 🏁 Release complete を使用してください。ヘルパーの JSON、バージョン、ハッシュ、タグ、コマンド、変更履歴のテキストは、正確なまま装飾を加えないでください。