FloatSoda: Skill for Claude Code

FloatSoda リリース

このスキルが存在する理由

リリースパイプラインは半分しか自動化されていない。.github/workflows/release.yml が引き継ぐのは git push origin vX.Y.Z からで、build → test → pack → NuGet を処理する。その タグより前のすべてと、タグの後の GitHub Release は人間の儀式 — そして儀式は風化する。この リポジトリでの実証: v0.2.0 / v0.3.0 / v0.3.1 はタグが打たれ NuGet に公開されたが、 GitHub Release は一度も作成されず、CHANGELOG の compare リンクは v0.3.0...main を指した まま、[0.3.1] のリンク行は丸ごと欠けていた。それらの手順が記憶に依存しないようにするのが このスキル。

唯一の正典

RELEASING.md がポリシーの正典で、このスキルはその執行者。

• 毎回の実行の最初に RELEASING.md を読み、記憶ではなくそこに書いてあることに従う。
• このスキルと RELEASING.md が食い違ったら RELEASING.md が勝つ — そして食い違いを口に出す。 スキルが直されるように。
• ポリシーの例外をここに書き込まない。 ゲートの動かし方を変えるとオーナーが決めたら(たとえば ジュニアコーダーゲートを Phase 完了まで先送りする、など)、その変更は RELEASING.md に属する。 このスキルに「ただし当面は代わりに X する」という分岐を持たせてはならない。

ハードストップ — オーナーの明示的な承認が要るもの

このワークフローの他のすべては可逆。これらはそうではない。

1. git push origin vX.Y.Z — Trusted Publishing 経由で NuGet に公開される。公開された バージョンは差し替えられず、deprecate / unlist しかできない。
2. gh release create — 公開の、外向きの操作。

準備を整え、diff と計画を提示して、止まる。前の手順が「明らかに」示唆していたからといって、 タグを push しない。

ワークフロー

タスクツールで追跡すること — リリースは手順が多く、1つ抜けるのが既定の失敗モードになる。

0. 事前確認

• 作業ツリーがクリーン(git status --porcelain が空)で main にいて、origin/main と同期 している。リリースをフィーチャーブランチから切ってはならない。
• リリースコミットで CI がグリーン(gh run list --branch main --limit 5)。
• gh auth status が通る(手順1、7、8 で必要)。

1. リリーススコープを確定する

git describe --tags --abbrev=0

そのタグから HEAD までを diff する(git log --oneline <prev>..HEAD、PR 単位の視点には --merges)。3方向でクロスチェックし、不一致は黙って直さず報告する:

• コミット vs [Unreleased] — CHANGELOG エントリの無い利用者可視の変更、またはコミットの 無いエントリ。
• マイルストーン — gh api repos/sumx21t-3310/FloatSoda/milestones で Phase 一覧を取り、 gh issue list --milestone "<title>" --state closed でこのリリースが実際に閉じる Issue を見る。 上のコミットで修正されたのにまだ開いている Issue が、報告すべき発見。
• public API サーフェス — この範囲に public API の追加・変更はあるか? あるなら docs/ が それに合わせて更新済みかを確認する(CONTRIBUTING は新しい public API に docs 先行を要求する)。 手順5のジュニアゲートが読むのはまさにそのページだから。