commit-message

コミットメッセージ

実際の Git の状態をもとに、コミットメッセージの文案を作成します。デフォルトでは Conventional Commits に従います。動作、影響、必要な追加対応を簡潔に説明する本文を優先します。このスキルで行うのはメッセージの文案作成のみです。ステージング、コミット、修正、プッシュは一連のワークフローの別の手順で行います。

ワークフロー

1. 対象範囲を決めます。

   • ユーザーが対象範囲を明示的に絞っている場合は、その境界に従い、無関係な変更は無視します。
   • ステージ済みの変更がある場合、ユーザーがすべての変更の要約を求めていない限り、デフォルトではステージ済みの変更を対象にします。
   • ステージ済みの変更がない場合は、関連するステージ前の変更、未追跡ファイル、または提供された変更を対象にします。
   • 要約する対象に未追跡ファイルが含まれる場合は、内容を確認します。git diff にはその内容が表示されません。
   • 関連する変更がない場合は、メッセージを作り出さず、その旨を伝えます。
   • 無関係な変更を含めると要約がわかりにくくなる場合は、明確に分けるか、まとめてよいか確認します。

2. 差分とコンテキストを確認します。

   • 利用可能な git status と差分の情報から、選択した対象範囲に含まれるステージ済み、ステージ前、未追跡の変更を特定します。
   • Git のデータを利用できない場合や、リポジトリにコミットがない場合は、その旨を伝え、提供されたコンテキストだけをもとに文案を作成します。
   • 最近のコミットメッセージを確認できる場合は、ユーザーが別途指定しない限り、リポジトリ固有の形式、スコープ、本文の慣例に従います。
   • コード変更の場合は、作成するすべての見出しや箇条書きの記述が具体的な差分に基づくまで、周辺のコンテキストを確認します。
   • ドキュメント、設定、ワークフロー、アセット、ロックファイル、生成ファイルについては、ファイル名を挙げるだけでなく、運用上の影響を説明します。
   • バイナリ、生成物、大容量のファイルについては、内容をそのまま出力するのではなく、ファイル名、メタデータ、マニフェスト、または近接するソースの変更をもとに要約します。
   • マイグレーション、環境変数、設定変更、API やスキーマの変更、データの書き換え、依存関係の変更、手動作業を明記します。機密性の高いキーについては、値を漏らさず言及します。

3. Conventional Commit のヘッダーを選びます。

   • 意味のあるスコープがある場合は、type(scope): summary を使います。
   • 意味のあるスコープがない場合は、type: summary を使います。
   • 破壊的変更の場合は、type(scope)!: summary または type!: summary を使います。
   • よく使われるタイプは、feat、fix、docs、refactor、test、chore、perf、build、ci、style、revert です。
   • ファイル拡張子ではなく、影響を受ける製品領域、パッケージ、モジュール、コマンド、ワークフローを表すスコープを選びます。不正確なスコープを無理に付けるくらいなら、省略します。
   • 変更の種類ではなく、動作上の意図に基づいてタイプを選びます。ユーザーに見える修正や機能追加に chore を使うことはありません。機能を追加または実質的に変える指示文の変更は feat、誤った動作や誤解を招く動作を正す変更は fix、説明のみに関する変更は docs です。
   • 1 行目は簡潔にします。差分から明らかな場合は、主な変更とその理由を反映します。
   • 命令形の現在形を使います。fixed や fixes ではなく、fix auth refresh handling のようにします。
   • 件名のみ、短いメッセージ、または 1 行のメッセージを求められた場合は、このヘッダーだけを返します。

4. 本文を作成します。

   • ヘッダーだけで変更内容を説明できる場合（小規模で単一目的の差分では通常そうなります）、本文は省略します。

   • 複数の要素からなる差分の場合、デフォルトでは次の基本形式を使います。

     type(scope): <主な変更の簡潔な要約>
     
     - <主な動作、機能、修正、または実装の変更。重要な場合は影響も記載>
     - <主な動作、機能、修正、または実装の変更。重要な場合は影響も記載>
     

   • ファイルごとの要約よりも、動作に基づいた箇条書きを優先してください。

   • 変更が重要な理由を明確にする場合は、コードレベルまたはビジネスロジックへの影響を含めてください。差分と周辺の文脈を超えて推測しないでください。

   • 課題への参照は、リクエスト、ブランチ名、差分、またはリポジトリの規約に含まれている場合にのみ記載してください。

   • Required actions: は、移行、環境変数、手動作業、または運用担当者による追加対応がある場合にのみ追加してください。

   • 破壊的変更の場合は、Conventional Commit のツールで検出できるよう、フッター行に BREAKING CHANGE: を追加してください。

5. 完成前に検証してください。

   • ヘッダーの種類が、変更の主な目的に合っていることを確認してください。
   • 各箇条書きの内容が差分によって裏付けられていることを確認してください。
   • コードに影響する箇条書きでは、ユーザーから見える動作、システムの動作、契約、または意味のある実装上の影響を説明してください。
   • 破壊的変更と必要な対応事項が、通常の変更内容に埋もれず、個別に記載されていることを確認してください。
   • 実際に実行した場合にのみ、テストに合格したと記載してください。
   • コミットメッセージの本文を返し、必要に応じて、その内容でコミットすることを簡潔に提案してください。

例

両方のフッターを含む本文：

feat(api)!: require cursor pagination for users

- Replace offset pagination with cursor pagination on the users endpoint
- Add queue configuration for the cursor backfill worker

Required actions:

- Set `CURSOR_BACKFILL_QUEUE` before enabling the worker

BREAKING CHANGE: `GET /users` no longer accepts `page` or `per_page`; clients must send `cursor` and `limit`.