mcpField
C
create-release

create-release

github.com/frostney開発072 回インストール3 日前に更新
リポジトリ

create-release について

create-releaseは、ソフトウェアリリースを準備し、許可がある場合に証拠に基づく単一の経路で公開するスキルです。バージョンと変更履歴の更新、検証、リリース用プルリクエスト、公開結果の確認を扱います。

主な機能

  1. 01準備と公開の段階を分離
  2. 02変更履歴とバージョン宣言を更新
  3. 03リリース関連の検証を実行
  4. 04ドラフトのリリース用プルリクエストを作成
  5. 05文書化された公開経路を一つ選択
  6. 06公開と成果物の結果を確認

活用シーン

  1. 01バージョン付きリリース用プルリクエストの準備
  2. 02マージ後のリリース公開
  3. 03タグとリリースを担うワークフローの確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/frostney/known-good-route --skill create-release

インストール後、Claude Code で/create-releaseを入力して読み込まれたか確認します。

詳細

リリースの作成

変更履歴を含むタグを用意し、公開が承認された場合に限り、証拠に基づいて1つの経路から公開します。

承認

  • 準備：バージョンを決定し、変更履歴とバージョン宣言を更新して検証し、リリース PR を作成します。準備、バージョンの更新、またはリリースノートの生成を依頼された場合に承認されるのは、この段階のみです。
  • 公開：PR のマージ後、リポジトリで確立されている公開手段を通じてタグ／リリースを作成または開始します。リリースの実行、タグ付け、公開、または /create-release の実行を依頼された場合は、この段階も承認されます。
  • /milestone-rush の呼び出し元は、検証済みのマイルストーン境界で公開権限を付与します。確定済みのリリース計画とバージョンを再利用してください。別途ユーザーのコマンドを求める必要はありません。/deliver によるデリバリーの統合は、このトリガーには該当しません。
  • 単独の依頼で承認が曖昧な場合は、「準備」のみを実行してください。

不変条件

  • 変更履歴とバージョンの更新は、スカッシュマージされた PR を通じてタグより先に反映します。
  • リポジトリで設定されたツールと最新のドキュメントを使用してください。生成される変更履歴は手動で編集せず、再生成してください。
  • 宣言されているリリース関連のゲートを実行し、実際に確認できた結果のみを報告してください。
  • コミットの amend、強制プッシュ、タグの強制更新、フックのスキップ、複数の経路からの公開は決して行わないでください。

準備

  1. 作業ツリーがクリーンであることを確認してから、承認された段階、リモートのデフォルトブランチ、変更履歴／バージョン管理ツール、直近のリリース、リモートタグ、ワークフロー、リリースドキュメントを確認します。
  2. リリース可能なコミットがない場合は中止します。
  3. 明示されて確定済みのバージョンを使用するか、プロジェクトの決定的なバージョンポリシーに従って算出します。いずれでも確定しない場合は、未リリースの Conventional Commits をもとにバージョンを提案し、その選択を確認します。
  4. 最新のリモートベースからリリースブランチを作成します。
  5. プロジェクトのツールを使って変更履歴のセクションを生成し、権威あるバージョン宣言をすべて更新します。プロジェクトがタグからバージョンを導出する場合、マニフェストの更新を独自に追加しないでください。
  6. リリース関連のゲートを実行し、chore(release): <version> をコミットして、/create-pr を通じて変更履歴のセクションと確認済みの検証結果を含むドラフトリリース PR を作成します。「準備」のみの依頼はここで終了します。

公開

  1. 公開権限がある場合は、/address-feedback automatic-merge を通じてリリース PR の処理を進め、続いて delivery-wait を使ってスカッシュマージと統合されたリビジョンを確認します。すでに検証済みのマージがある場合はそれを再利用します。オープン中の PR ブランチには決してタグを付けないでください。
  2. マージ済みのベースを更新してから、実際のワークフロー YAML とリリースドキュメントを読み直します。タグの作成、GitHub リリースの作成、アーティファクトの署名、レジストリへの公開をそれぞれ担当する主体を特定します。
  3. タグやリリースが二重に作成されないよう、次のうち1つだけを選択します。
    • タグとリリースをワークフローが担当する場合：ワークフローの開始または監視のみを行います。
    • タグをエージェントが、リリースをワークフローが担当する場合：検証済みのタグを1回だけプッシュし、その後監視します。
    • タグをワークフローが、リリースをエージェントが担当する場合：タグを確認してから、GitHub リリースを1つ作成します。
    • タグとリリースの両方をエージェントが担当する場合：どちらの操作もワークフローが担当しない場合に限り、検証済みのタグを1回だけプッシュし、リリースを1つ作成します。
  4. 担当が曖昧な場合、またはドキュメントとワークフローに食い違いがある場合は中止します。
  5. 選択した経路のみを実行し、その経路が担当する最終タグの対象、リリース、ワークフローの結果、アーティファクト、レジストリの状態を検証します。これらの GitHub 上の遷移にはヘルパーの wait workflow-terminal、wait tag-target、wait release-assets 操作を使用し、変化のない状態をモデルのターンをまたいで監視しないでください。

リリースの結果、PR／リリース URL、選択した公開手段、現在確認できている証拠を最初に伝えてください。確認できていない状態を完了したと説明してはいけません。

コメント

Markdown 対応