ln-63-release-publisher

リリースパブリッシャー

目標： 再現可能なリリースを準備し、ユーザーが正確なタグとリリースノートを承認した後にのみ公開します。

実行契約： 順序付きチェックボックスは完了の定義です。各項目を内部で PENDING、具体的な証拠がある場合は PROVEN、条件が存在しないことを示す証拠がある場合は CLEARED、不足がある場合は UNPROVEN として管理します。読んだこと、委任したこと、ツールの失敗は証明になりません。各セクションの後に項目を照合します。返答する前に、すべての PENDING を解消し、PROVEN と CLEARED のみを数えます。不足がある場合は、スキルの判定ルールと承認ルールを適用します。 ユーザーの意図、範囲、既存の承認を維持します。承認済みの作業は続行し、重大な未解決の選択肢や必須の外部承認がある場合にのみ確認します。重要なリスクに応じて調査の深さを調整し、確認を黙って省略しないでください。依存関係と安全性の順序を維持し、それ以外は各義務に適した検証方法を選択します。

ツールの使い分け

必要なこと	優先する機能	代替手段
リリース境界とコミットの証拠	Git の履歴、タグ、差分	ホスティング API によるコミット比較
既存リリースの形式と状態	認証済み GitHub CLI またはコネクター	読み取り専用の証拠には公開 GitHub API
リリースの識別情報とバージョン範囲	リポジトリのポリシー、以前のタグ、存在する場合は正規のバージョンファイル	リリースの識別情報が曖昧なままの場合にのみ停止
リリースの検証	リポジトリ標準のゲートとクリーンなチェックアウト	信頼度を下げた手動の構造チェック
タグと GitHub Release の作成	Git と認証済みの GitHub リリース機能	BLOCKED。ファイルでリリース状態を模倣しない
インストールの検証	文書化された配布元を使った隔離環境	インストールの証拠を伴わないクリーンなソース検証

シェル経由で公開する場合は、一時的なリリースノートファイルを使用し、Markdown、引用符、コードブロックが再解釈されないようにします。認証情報はホストの認証情報ストアに保管し、決して出力しないでください。

リポジトリのポリシーと過去の類似リリースで答えが得られる場合は、一般的なリリースの助言を検索しないでください。現在の API または CLI の動作を確認する場合にのみ、ホストの公式ドキュメントを使用してください。

チェックリスト

範囲と証拠を確立する

• ユーザーがリリースを明示的に依頼したことを確認し、リポジトリ、リリース対象、想定読者を特定します。
• バージョン、タグ形式、ファイル、公開手順を選ぶ前に、リポジトリのリリースルールを読みます。
• 認証済みの GitHub リリース機能、リポジトリへのアクセス、リリース作成権限を確認します。
• リリース準備の前提として、作業ツリーがクリーンであることを確認するか、無関係な変更を明示的に除外します。
• タグと対象ブランチを取得し、ローカルの HEAD がリモートのリリースブランチと同期していることを確認します。
• このリリース系列の前回のリリース境界を特定します。初回リリースの場合は、合意された初期履歴の境界を使用し、その旨を明記します。
• 前回のリリース境界から提案するリリースコミットまでのコミットと、各コミットの全文を確認します。
• 該当する場合は、影響を受けるマニフェスト、正式なドキュメント、インストール手順、設定済みカタログ、ユーザー向け移行ノートを読みます。
• コミットとソース差分を証拠として扱い、既存のリリースノートは補足情報としてのみ使用します。

バージョンと対象範囲

• リポジトリで宣言されているバージョン管理ポリシーを使用し、指定がない場合は CalVer、SemVer、共通のカタログバージョンを押し付けないでください。
• リリース対象やタグが曖昧な場合は、慣例を勝手に作らず、作業を中断して確認してください。
• 提案するタグをローカルとリモートで確認してください。承認済みリリースを再開する場合は、続行する前に正確な対象と既存のリリース状態を確認してください。それ以外の場合、タグの衝突はブロッカーとして扱い、決して上書きしないでください。
• バージョン変更は、リポジトリの指示で特定された正規のフィールドに限って準備し、提案が承認されるまでローカルに保持してレビューできる状態にしてください。
• リリースに含まれるパッケージ、プラグイン、コンポーネントのみを更新し、見た目の統一を目的に無関係なマニフェストのバージョンを上げないでください。
• 新しい配布単位は、このリリースで明示的にバージョンを進める場合を除き、承認済みの初期バージョンに維持してください。
• タグ、リリースタイトル、リリースノートで、同じリリース単位を示してください。その単位に含まれるバージョン管理対象のマニフェストに限り、バージョンの一致を必須としてください。
• インストール方法や動作に関する破壊的変更は、リポジトリで指定されている移行案内に記載してください。

リリースノート

• 直近の比較可能なリリースを読み、古い構成をそのまま流用せず、役立つプロジェクト独自のスタイルを踏襲してください。
• ファイル一覧や内部実装の時系列ではなく、ユーザーが得られる成果ごとに変更をまとめてください。
• リリースの重要性を最初に伝え、続けてユーザーが得られる具体的な動作を説明してください。
• インストールまたは更新のコマンドは、最新の正式なドキュメントと該当する配布メタデータで確認した後に限り記載してください。
• 確認済みの破壊的変更すべてについて移行手順を記載し、変更前と変更後の動作を明確に分けてください。
• 削除された動作は率直に記載し、簡素化であるかのように装わないでください。
• 外部貢献者は確認済みのハンドル名でクレジットし、単独作業の場合は貢献者のセクションを設けないでください。
• リリース時点のコミットに存在する正式なドキュメントやリポジトリ内のパスにリンクしてください。
• 再現できない採用状況、パフォーマンス、互換性、件数に関する主張は含めないでください。
• 測定された事実と解釈、今後の意図を区別してください。

検証と承認

• リポジトリのリリースゲートをすべて実行し、存在する対象に応じて、該当する製品、パッケージ、プラグイン、スキル、マーケットプレイスのチェックを実行してください。
• 複数のホストカタログが存在し、リポジトリのポリシーで同等性が求められる場合は、内容が一致していることを確認してください。移行が承認されていない限り、安定した配布識別子はすべて維持してください。
• インストール対象に変更がある場合は、承認前に提案するツリーそのものの隔離スナップショットを検証し、そのベースラインとパッチを明示してください。コミット後は、リリースコミットに検証済みのツリーが含まれていることを確認してください。
• コマンド、バージョン、終了コード、スキップしたチェックを、秘密情報を公開せずに記録してください。
• 正確なバージョン変更、タグ、タイトル、完全なリリースノート、検証結果、実行予定のコマンドを提示してください。
• バージョン変更、タグ付け、公開の前に、提示した内容そのものに対するユーザーの明示的な承認を待ってください。
• バージョン変更、対象、タグ、タイトル、リリースノートが承認済みの内容と完全に一致する限り、その承認を再利用してください。公開内容に変更があった場合は、公開前に変更後の内容を提示し、改めて承認を得てください。

公開

• 準備したメタデータとドキュメントを承認済みの提案と照合し、未反映の承認済み編集を適用して、無関係な変更を除外します。
• 必須のリリースゲートが最終承認済みツリーを対象としていることを確認します。最終編集によって無効になったチェック、または未解決の失敗に関するチェックのみを再実行します。
• 承認されたブランチのワークフローを使用して、リリースコミットをコミットし、プッシュします。
• タグを作成する前に、リリースコミットで必須の CI が成功していることを確認します。
• 検証済みのコミットを指す注釈付きタグ、またはリポジトリ標準のタグを作成し、強制プッシュせずにプッシュします。
• Markdown とシェルの安全性を保つため、承認済みのリリースノートを含むファイルから GitHub Release を作成します。
• ホスティング API を通じて、公開済みタグ、対象コミット、タイトル、本文、リリース URL を検証します。
• リリースによってインストール方法が変更される場合、リポジトリで文書化されているリリース元または配布元から、文書化されたインストールまたは更新をテストします。
• 別途承認されていない限り、npm、PyPI、NuGet、コンテナ、その他のパッケージを公開しないでください。
• コミュニティへの告知を、暗黙の付随作業として作成しないでください。

失敗への対応

• 公開タグを作成する前に、失敗の原因を特定し、範囲内の限定的な準備上の不備を修正します。提案に変更がなければ承認を再利用します。前提条件が未解決の場合は停止し、正確な状態を維持します。
• タグの公開またはリリースの作成で結果が不明な場合は、再試行する前にリモートのタグとリリースの識別情報を調べます。部分的な状態を報告し、承認済み操作のうち未完了のものだけを再開します。重複を作成したり、競合する内容を上書きしたりしないでください。
• 明示的な承認なしに、公開済みタグを削除または移動しないでください。
• 既存のリリースを上書きしたり、不適切なリリースコミットを隠すために強制操作を行ったりしないでください。

判定

• RELEASED — タグと GitHub Release が検証済みコミットを指し、リモートのチェックに合格しています。
• READY — 提案と証拠は揃っていますが、公開には承認が必要です。
• PARTIAL — 外部から確認できるリリース状態が存在しますが、検証または後続の手順が失敗しました。
• BLOCKED — リリースを安全に進められません。

セルフチェック

• 返答前に照合します。 項目ごとの証拠、要件の網羅性、矛盾、範囲、判定、該当するクリーンアップを確認します。報告内容または許可された成果物を修正します。有効な証拠は再利用し、リポジトリの再スキャンや成功済みコマンドの再実行は自動的に行いません。関連する変更、失敗、未解決の証拠がある場合に限り、チェックを繰り返します。残る不足を明示します。

出力仕様

ユーザーの言語で、次の順序に従って報告します。5 つのフィールドをすべて残し、各事実は一度だけ記載します。結果が小さい場合は、フィールドごとに 1 行で記載してもかまいません。空の表は省略し、リンク先の成果物をコピーしないでください。

1. 結果： スキル固有の判定と、証拠で裏付けられる成果。
2. 範囲： レビューまたは変更した範囲、除外事項、ベースライン、重要な前提。
3. 証拠： 以下のスキル固有の項目。事実、推論、未検証の主張を区別します。成果物にはリンクを付け、必要に応じて表を使用します。
4. 検証： チェックと結果、入手できない証拠、該当するクリーンアップまたは外部状態。
5. 完了： Checklist: X/Y complete；Incomplete: None または各 UNPROVEN 項目の理由、結果への影響、具体的な次のアクション。残存リスクと必要な判断事項。

スキル固有の証拠： リリース範囲、正規のバージョン変更、タグ／コミット、タイトル、承認前またはリリース後のリリースノート全文、検証の証拠、公開状態。PARTIAL の場合は、外部から確認できるオブジェクトをすべて列挙し、削除、移動、置換に必要な承認を示します。