ツールリリース

作業手順の正本は docs/conventions/publishing.md。 本スキルは手順を再掲せず、対話的に進める規律と、CHANGELOG の生成手順・PR案のひな形を定める。 規律: 提案 → ユーザー確認(修正があれば反映して再提示)→ 実行、を要所ごとに繰り返す。 スキルが実行するのは PR の作成まで(git・gh CLI の操作)。判断(バージョンの決定・PR案の確定)は 自動化せずユーザーに残し、マージとタグ作成・タグ push はユーザーが GitHub・手元で別途行う (スキルは実行せず、残タスクとして提示する)。 確認を得ていない外向き操作を実行しない。

提示の方法: ユーザーへの提示(CHANGELOG の節・PR案・残タスクのコマンドなど)はチャット本文に 書き、転記・確認してもらう文面はコードブロックで示す。AskUserQuestion の前置き文や選択肢の プレビューは表示されない環境があるため、確定を要する本文をそこへ載せない(確定は返信で受ける)。

入力

• 対象ツール名(tools/<ツール>/ のパッケージ名。複数ツールの同時リリースなら全部)。
• リリースするバージョン(ツールごとの MAJOR.MINOR.PATCH)。原則、バージョンは指定されて実行する。勝手に 付けない。 バージョンの指定が無いツールがある場合は、docs/conventions/versioning.md §3 に従い、 PR に記載するバージョンを判断根拠(どの契約面に触れたか)つきで提案し、ユーザーの了承を得てから A を実行する。

進め方

1. 開始時に作業ツリーとブランチの状態を確認する。未コミットの変更がある場合、または現在の ブランチが develop でない場合は、その状態を提示してユーザーに確認を取る(勝手に stash・破棄・ 切り替えをしない)。問題がなければ develop に切り替え、その上で publishing.md の A → B → C を 順に実行する。
   • B(公開前検証)の実行・計測は run-and-bench スキルの規律で行う。
   • C(ドキュメント)の CHANGELOG 更新は CHANGELOG の生成手順で行う。
2. 各まとまりの編集が終わるごとに codex-review-loop で収束させ、commit スキルでコミットする。
3. D(リリース確定)は PR の作成までをスキルが実行する(gh の利用開始時のアカウント確認と、 gh が使えないときの代替は gh の利用とフォールバックに従う):
   1. PR案のひな形で PR案(タイトル・本文)を作成して提示し、ユーザーの確認(修正があれば反映して 再提示)を経て確定する。
   2. 確定したら、develop を push し、確定した PR案どおりに develop から main への PR を作成する (gh pr create)。PR案の確定をもってこの2操作の確認とみなし、個別には確認しない。
   3. CI の結果を確認し(gh pr checks)、緑になったことを報告する。赤なら原因を報告して指示を待つ。
4. マージとタグ作成・タグ push はユーザーが GitHub・手元で別途行う作業であり、スキルは実行しない。 CI 緑の報告と合わせて、次を残タスクとして提示して締める(タグのコマンドはコピーしやすい ようにコードブロックで示す。タグの形式・種別は versioning.md §5):
   • PR をマージする。
   • main のマージコミットへ、リリースする構成要素ごとの注釈付きタグを打って push する。
   • タグ push で CI が GitHub Release を自動作成するので、作成された Release を確認する。 依頼があればスキルが確認を代行し(gh run list / gh release view でタイトル・本文が CHANGELOG 該当節と一致すること)、失敗時は実行済みの範囲を報告する(巻き戻しはしない)。

gh の利用とフォールバック

D の操作は認証済みの gh CLI で実行するのが基本。gh を使い始める前に gh auth status の ログイン中アカウント(ホスト・ユーザー名)をユーザーに提示し、そのアカウントで問題ないかの 確認を得てから gh 操作を始める(リリースは外向き操作なので、意図しないアカウントでの実行を 防ぐ)。問題ありと言われたら gh 操作を始めず、アカウントの切り替えをユーザーに依頼して待つ。 リモート URL が SSH エイリアスのとき gh がリポジトリを解決できないことがあるため、gh コマンドには --repo <owner>/<リポジトリ> を明示する。

gh が使えない(未インストール・未認証)ときは作業を止めず、gh の操作だけを次の代替に置き換えて進める。 判断ポイント(バージョンの決定・PR案の確定)と残タスクの提示は変えない。gh auth login で自動化できる旨を 伝えてよいが、認証は代行しない。

• PR 作成: develop の push まで行い、PR のタイトルと本文を提示してユーザーに作成を依頼する (main との比較画面の URL を添える)。
• CI 確認: PR 画面での CI 結果の確認をユーザーに依頼し、結果を教えてもらう。
• Release 確認の代行を依頼された場合: Releases ページでの実体確認をユーザーに依頼する。

CHANGELOG の生成手順

エントリの形式・粒度・書き方の規準は docs/conventions/changelog.md が正。本節は素材の集め方と 対話の順を定める。複数ツールの同時リリースでは、リリースする各ツールについて行う。

1. 前バージョンの特定: 対象ツールのタグ(<ツール>/v*)の最新バージョンを取る。CHANGELOG 先頭のバージョンと一致する はずで、一致しなければ進めずユーザーに確認する。
2. 素材収集: 前バージョンのタグから HEAD までの tools/<ツール>/ 配下のコミットを列挙する (git log <ツール>/v<前バージョン>..HEAD -- tools/<ツール>)。前バージョンのタグのツリーでツールの配置が 現行と異なる場合(ディレクトリ再編など)は、旧パスも範囲に加える(パス絞りは改名を遡らない)。 加えて同範囲の libs/ 配下(旧配置なら旧ライブラリパスも)の変更から、対象ツールの挙動に 効くものを拾う(依存ライブラリの変更は、利用者にはツールの挙動変化として見える)。
3. 取りこぼし検査: 前バージョンのタグと HEAD の CLI オプション一覧(cli.py の add_argument)を突き合わせ、 追加・削除されたフラグがすべて素材に現れていることを確認する(パス絞りの漏れをここで検出する)。
4. 仕分け・起草: 規準に従い利用者に見える変更だけを採り、カテゴリへ割り付けて起草する。
5. 提示・確定: 起草した節と、採った変更・落とした変更(コミットとの対応)を提示し、確認・修正を 経て確定する。確定した節を CHANGELOG の先頭へ追加する。

初回リリースでは素材収集・仕分けは不要(ファイルの作成と節の内容は規準のとおり)。

PR案のひな形

PR はリポジトリ所有者しか見ないので、必要最小限にする。

• タイトル: release: <ツール> v<バージョン>(複数ツールは , で連ねる)

• 本文:

  ## 変更点
  
  (CHANGELOG の該当バージョンの節をそのまま転記。複数ツールでは、ツールごとに
  「### <ツール> v<バージョン>」の小見出しを付けて順に並べる)
  
  ## 検証
  
  - 検証(docs/conventions/verification.md): 全検査エラー0件
  - スモーク: <代表入力での end-to-end 実行結果。リリースする各ツールにつき1行>