create-changeset

Changeset 作成スキル

目的

このスキルは、ブランチの変更を自動的に分析し、このモノレポでのパッケージリリースに適切な changeset を作成します。Git の履歴を調べ、Conventional Commits に基づいてバージョンの更新種別を判断し、適切な形式の changeset ファイルを生成します。

呼び出すタイミング

次の場合に、このスキルを自動的に呼び出します。

• ユーザーがプルリクエストの作成を準備している
• ユーザーが「PR」「pull request」「ready for review」と言及した
• ブランチにレビュー可能なコミットがある
• ユーザーが「changeset」または「version bump」と明示的に言及した

次の場合は呼び出さないでください。

• ユーザーがプルリクエストを作成せずに変更をプッシュするだけの場合
• ドキュメントファイル（README、.md ファイル）のみが変更された場合
• CI/CD 設定（.github/workflows/）のみが変更された場合
• 開発ツールの設定（eslint、prettier など）のみが変更された場合
• パッケージに影響しない docs:、chore:、ci:、test: タイプのコミットのみの場合

実行前の検証

changeset を作成する前に、現在の変更に対する changeset ファイルがすでに存在するか確認します。

• .changeset/*.md ファイル（README.md を除く）を探します
• 存在する場合は、ユーザーに「changeset がすでに存在します。もう 1 つ作成しますか？」と尋ねます

実装手順

1. 現在の状態を確認する

git log main..HEAD（または origin/main..HEAD）を実行して、ブランチにコミット済みの変更があるか確認します。コミットがない場合は、changeset を作成せずに早期終了します。

2. 変更を分析する

git diff main...HEAD（または origin/main...HEAD）を使用して、コミット済みの変更のみを分析します。

packages/*/ 配下のファイルを確認し、影響を受けるパッケージを特定します。git log main..HEAD --oneline（または origin/main..HEAD）を使用してコミットメッセージを確認します。

3. バージョン更新種別を判断する

Conventional Commits 1.0.0 形式に従って、コミットメッセージを分析します。

• major：コミット本文に BREAKING CHANGE が含まれる、またはコードから破壊的変更が検出された場合
  • API シグネチャの変更
  • エクスポートまたは機能の削除
  • 互換性のない動作変更
• minor：feat: または feat(scope): で始まる場合（後方互換性のある新機能）
  • 新しいコンポーネントまたは機能
  • 新しい props またはオプション（デフォルト値あり）
  • 新しいエクスポート
• patch：fix: または fix(scope): で始まる場合（バグ修正および軽微な改善）
  • バグ修正
  • パフォーマンスの改善
  • 軽微なスタイル更新
• skip：その他のタイプ（chore:、docs:、ci:、test:）は、通常、パッケージの機能に影響しない限り changeset は不要です

実際のコード変更を確認し、適切なバージョン更新を判断します。minor と patch のどちらか迷う場合は、安全を優先して patch を選んでください。

バージョン更新が曖昧、または不明確な場合は、次のようにします。

• ユーザーに確認を求めます
• 提案する更新種別の理由を説明します
• ユーザーが提案を上書きできるようにします

すべてのコミットが changeset を必要としないタイプ（docs:、chore:、ci:、test:）の場合は、changeset を作成せずに早期終了します。

4. Changeset を生成する

.changeset/ ディレクトリに、説明的なファイル名で changeset ファイルを作成します。

ファイル名の形式：

• kebab-case を使用し、拡張子は .md にします
• 例：.changeset/add-new-button.md、.changeset/fix-layout-bug.md、.changeset/update-icon-props.md

ファイルの内容形式：

---
"@openameba/package-name": major|minor|patch
---

Clear description of the change

単一パッケージの例：

---
"@openameba/spindle-ui": minor
---

Add new Button variant for secondary actions

複数パッケージの例：

---
"@openameba/spindle-ui": minor
"@openameba/spindle-tokens": patch
---

- spindle-ui: Add new Button variant for secondary actions
- spindle-tokens: Fix color token contrast ratio

重要なガイドライン：

• 説明は CHANGELOG に掲載されるため、ユーザーにわかりやすい表現にします
• **コミットメッセージと同じ言語（日本語または英語）を使用します。**コミットメッセージが混在している場合は、日本語を優先します
• 同じパッケージに異なる目的の変更（例：新機能とバグ修正、破壊的変更と内部リファクタリング）がある場合は、changeset を別々のファイルに分けます
• これによりリリースノートに個別のトップレベル項目が作成され、読者が各変更の目的を把握しやすくなります
• 例：新機能には .changeset/add-secondary-button.md を、バグ修正には .changeset/fix-button-layout.md を作成します。どちらも同じパッケージを対象とする場合でも、別々に作成してください

5. Changeset の Lint

pnpm textlint .changeset/<filename>.md を実行して、changeset ファイルを検証します。

エラー処理：

• Lint エラーが発生した場合は、よくある問題を自動修正してみてください。
  • スペースと句読点
  • よくある文法上の誤り
• 自動修正後、textlint を再実行します
• エラーが解消されない場合：
  • エラーの詳細をユーザーに表示します
  • 修正方法についてユーザーに指示を求めます
  • Lint が通るまでコミットに進まないでください

6. 確認とコミット

生成された changeset を確認用に表示します：

• ファイルパスを表示します
• ファイルの内容を表示します
• 変更内容が正確に反映されていることを確認します

確認できたら、changeset ファイルをコミットします：

git add .changeset/<filename>.md
git commit -m "chore: add changeset"