リリース準備

意図

前回リリースからの変更を整理し、品質を確認し、バージョンを上げて公開可能な状態にする。 「漏れなく、しかし過剰にならない」リリースフローを目指す。

前提

• •changeset は PR ごとではなくリリース時にまとめて作成する運用
• •全パッケージは fixed グループ（常に同一バージョン）
• •タグ形式: @ydant/<pkg>@<version>

フェーズ 1: 変更の俯瞰

基準点の特定

全パッケージのタグから最新のリリースポイントを自動検出する:

git tag -l '@ydant/*' --sort=-creatordate | head -1

fixed グループでも個別パッチリリースなどでタグがずれることがある。 検出されたタグをユーザーに提示し、正しいか確認してから進める。 必要に応じて複数のタグやコミットを比較し、適切な基準点を判断する。

変更の把握

git log --oneline <base-tag>..HEAD
git diff --stat <base-tag>..HEAD

変更の分類

コミットを以下のカテゴリに分類する:

分類結果をユーザーに提示し、バージョンバンプの種別（patch / minor / major）を合意する。

フェーズ 2: 品質ゲート

以下を順に実行する。すべてパスしなければリリースしない。

パッケージ

pnpm -r run build       # 全パッケージビルド
pnpm test:run           # テスト
pnpm typecheck:packages # パッケージ型チェック
pnpm lint               # lint
pnpm format:check       # フォーマット

Examples（showcase）

examples はドキュメントとしての性質を持つ。 リリースされるパッケージの API を実際に使用するコードであり、利用者が参考にする。 パッケージの API 変更が examples で正しく動作するか確認する。

pnpm typecheck:examples # showcase 型チェック

失敗した場合

• •原因を特定し、修正するか、リリースを中断するか判断する
• •パッケージ側の修正ならフェーズ 1 に戻って変更に含める
• •examples 側の修正なら、API 変更に追従できているかを確認する（ドキュメント整合性の問題）

フェーズ 3: ドキュメント整合性

リリースに必要な最低限のチェック

1. •

   API 変更のあるパッケージ README が更新されているか

   • •フェーズ 1 で feat / fix / BREAKING に分類された変更を対象に確認
   • •packages/*/src/ の公開 API と packages/*/README.md を突き合わせる
2. •

   examples（showcase）がリリース内容と整合しているか

   • •API の追加・変更・削除を反映した使用例になっているか
   • •新機能があれば、それを示す showcase の追加・更新を検討する
   • •showcase README の「実装のポイント」が最新の API を反映しているか
3. •

   ルート README の日英同期

   • •機能一覧やパッケージ構成に変更があれば、README.md と README.ja.md の両方が更新されているか
4. •

   JSDoc が英語で記述されているか

   • •「利用者インターフェースは英語」原則に基づく（DOCUMENTATION.md 参照）
   • •新規・変更された公開 API の JSDoc を確認
   • •既存の日本語 JSDoc が残っていれば英語化する
5. •

   CLAUDE.md の整合性

   • •コマンドやパッケージ構成に変更があれば反映されているか

より詳細なレビューが必要な場合

/doc-review skill を使用して体系的なドキュメントレビューを行う。 特に以下の場合は doc-review を推奨:

• •新パッケージの追加があった場合
• •API の大幅な変更があった場合
• •初回リリースまたはメジャーバージョンアップの場合

フェーズ 4: changeset 作成

変更概要の作成

フェーズ 1 の分類をもとに、changeset の内容を作成する。

pnpm changeset

changeset の記述ガイド:

• •ユーザー視点 で書く（「〜を修正した」ではなく「〜が正しく動作するようになった」）
• •影響範囲 を明記する（特定のパッケージ、特定の機能）
• •破壊的変更 がある場合は移行方法も記載する

例

---
"@ydant/base": minor
---

keyed() がジェネリック型に対応し、Component でも使用可能になった。
Element.key プロパティによる明示的なキー指定に移行。

※ fixed グループのため、1つのパッケージを指定すれば全パッケージに適用される。

フェーズ 5: バージョン適用

pnpm version    # changeset version

適用後の確認:

• •各パッケージの package.json のバージョンが期待通りか
• •CHANGELOG.md が生成/更新されているか
• •内部依存のバージョンが更新されているか

フェーズ 6: 最終確認とコミット

リリースコミット

git add -A
git commit -m "chore: v<version> リリース準備"

公開

公開の判断と実行はユーザーに委ねる。skill はここまでで完了。

pnpm release    # build + changeset publish

changeset publish は npm 公開とタグ付けを自動で行う。

現時点の方針

• •フェーズは順番に進めるが、問題が見つかったら前のフェーズに戻る のは正常な流れ
• •品質ゲートは省略しない。ドキュメントチェックは変更の規模に応じて深さを調整する
• •changeset の記述は ユーザーと一緒に推敲 する。自動生成で済ませない
• •この skill 自体もリリースを重ねるごとに改善する

今後の検討事項

• •CHANGELOG の書き方のガイドライン（changeset の summary をどこまで詳細にするか）
• •リリース後の作業（GitHub Release の作成、アナウンスなど）
• •プレリリース（alpha, beta, rc）のフロー
• •CI/CD との連携（品質ゲートの自動化）