git:commit

Git コミットの作成

概要

適切なステージ済み変更セットを準備し、コミットメッセージを作成して、そのメッセージを正確に使ってコミットを作成します。 メッセージが完全に確定してから、コミットを作成します。エディターを開いたり、対話型の Git フローに頼ったりしないでください。

ワークフロー

1. 対応するスコープを確定する

このスキルが対応するスコープは、次の 2 つだけです。

• 引数なしのスキル git:commit 最初に、コミット対象は現在ステージ済みの変更のみとして扱います。 ステージ済みの差分が空でなければ、保守的なステージ済み変更のみを対象とする動作を維持し、ステージ済みの差分を使って処理を進めます。 ステージ済みの差分が空の場合、引数なしの呼び出しは作業ツリー全体をコミットする暗黙の要求として解釈し、フローを自動的に HEAD モードに切り替えます。
• HEAD を指定したスキル git:commit 最初に git add -A で作業ツリー全体をステージします。 ステージ後、未ステージの追跡対象変更や未追跡ファイルが残っていないことを確認します。

このスキルは、スキル git:commit と <commit> を指定する場合のような、コミット範囲のスコープには意図的に対応していません。

2. コミット対象を安全に準備する

スキル git:commit の場合：

• git diff --staged でインデックスを確認します。
• ステージ済みの差分が空でなければ、コミット対象をインデックス内に限定し、未ステージの変更は無視します。
• ステージ済みの差分が空の場合、すぐに停止しないでください。ユーザーが便宜上 HEAD を省略した可能性があるため、ワークフローを HEAD を指定したスキル git:commit と同じ準備手順に切り替えます。

HEAD を指定したスキル git:commit の場合：

• git add -A を実行します。
• 続行する前に、作業ツリー全体がステージ済みであることを確認します。
• 確認には git status --porcelain を優先して使い、どのエントリにも未ステージの作業ツリーを示すマーカーがなく、未追跡のエントリも残っていないことを確かめます。
• 確認に失敗した場合は、コミットせずに停止し、コミット対象外として残っているものを説明します。
• git add -A 後のステージ済み差分が空の場合は、停止してコミット対象がないことを伝えます。

暗黙のフォールバックは、ユーザー体験を向上させるための最適化として扱い、明示されたスコープの再定義とはみなしません。引数なしのスキル git:commit に限り適用します。

3. 差分を中心に状況を把握する

ステップ 2 で準備したステージ済み変更セットを使い、何かを書き始める前に、その周辺の状況を把握します。関連する差分は、ステップ 2 で得られたものです。つまり、ステージ済み変更のみのモードでは git diff --staged、HEAD モードでは git add -A 後の HEAD に対する作業ツリー全体の差分です。

判断を改善するために軽量な Git コンテキストを使います。ただし、差分より優先してはいけません。

• 差分そのものからファイルパス、ハンクの内容、変更のおおよその規模を確認します。
• 意図の把握に役立つ場合は、git branch --show-current で現在のブランチ名を確認します。
• ステージ済みの作業と未ステージの作業を分けるのに役立つ場合は、git status --short を確認してもかまいません。

ブランチ名はあくまで弱い手掛かりとして扱います。変更内容を明らかにしない曖昧な名前やチケット ID は無視します。

4. レビューで重要な変更内容を推測する

差分から逆算し、次の 3 つの質問に順番に答えます。質問 1 はリポジトリの事実に関するもので、質問 2 と 3 は今回の変更に関する判断です。

1. このリポジトリが実際に提供しているものは何ですか？ 何をリポジトリの製品として分類するかを、先に判断します。同じ差分でも、この答えによって意図は大きく異なる可能性があります。
   • コード中心のリポジトリが提供するのは、実行可能な成果物（バイナリ、ライブラリ、サービス、アプリ）です。
   • コンテンツ中心のリポジトリが提供するのは、Markdown、プロンプト、スキーマ、設定バンドル、設計ドキュメントなど、それ自体が製品となるコンテンツです。
   • インフラストラクチャ中心のリポジトリが提供するのは、Terraform モジュール、Helm チャート、CI パイプラインなどの運用資産です。
2. ユーザーの主な意図は何ですか？
3. レビューに実質的な影響があり、特記すべき二次的な変更はどれですか？

4a. 判定ツリーで主な意図を分類する

最初の判定：質問1で定義されている、リポジトリが提供する製品の範囲に変更を加えていますか？

• はい — 製品に影響する変更の分類を順に確認し、最初に該当するタイプを選びます。この順序はレビュー担当者にとっての重要度に基づいているため、より強い意図がより弱い意図に優先します。refactorは、製品の範囲に含まれる変更のうち、それ以前のどのタイプにも該当しないものをすべて受け持つ分類です。
  1. feat：製品にユーザーが目にする機能を追加する変更ですか？
     • はい：featを使用します。
     • いいえ：続けます。
  2. fix：製品の不具合を修正する変更ですか？
     • はい：fixを使用します。
     • いいえ：続けます。
  3. perf：外部から見た動作を変えずに、製品のパフォーマンス特性を改善する変更ですか？
     • はい：perfを使用します。
     • いいえ：続けます。
  4. style：動作を変えずに、製品の書式設定または空白文字だけを変更するものですか？
     • はい：styleを使用します。
     • いいえ：続けます。
  5. test：製品に含まれるテストまたはテスト用フィクスチャだけを変更するものですか？
     • はい：testを使用します。
     • いいえ：続けます。
  6. refactor：フォールバックです。外部から見た動作を変えずに製品の構造を変更し、上記のどれにも該当しない場合に使用します。
• いいえ — 変更対象は支援用の資料のみです。その資料の性質に合う分類を選びます。
  • docs：製品そのものではなく、製品を支援するドキュメント、コメント、文章を変更します。
  • chore：ビルド、CI、メタデータ、ツール、保守作業、その他の付随資料を変更します。

以下の区別ルールを慎重に適用してください。

• コンテンツを中心とするリポジトリでは、提供される製品に含まれる、エンドユーザー向けの実質的な新規コンテンツは製品の変更です。そのため、該当する場合はfeat（または適切なfix／refactorなど）に分類し、docsにはしません。docsは、製品そのものではない支援用の文章に限定されます。
• コードを中心とするリポジトリでは、ソースファイル内のコメントだけを編集する変更は支援用の文章であり、コード変更のタイプではなくdocsに分類します。
• 差分が大きい、または多数のファイルに及ぶという理由だけで、変更をfeatに分類しないでください。featは、製品にユーザーが目にする価値を実際に追加する場合にのみ使用します。
• 1つのコミットがツリーの両方にまたがる正当な理由がある場合は、レビュー上の主な関心事を反映するタイプを選び、残りの変更は本文と二次的な変更のハイライトで示します。

4b. 二次的な変更をレビュー上の価値で順位付けする

次に、二次的な変更をレビュー上の価値で順位付けします。git logをざっと見る人にとって有意義な変更だけを強調します。たとえば、次のような変更です。

• 公開APIの形状の変更
• モジュールまたはディレクトリの再構成
• スキーマまたは契約の変更
• 広範囲に影響する、大規模なクリーンアップ
• 注目すべき設定またはワークフローの変更
• 移行、削除、または互換性に影響する編集

その変更の中心となる場合を除き、機会に応じた書式変更、小規模な名前変更、些細なコメントの整理など、シグナルの弱い付随的な変更は強調しないでください。

5. コミットメッセージの下書きを作成する

メッセージの文字を一文字でも書く前に、譲れないルールを一つ決めてください。**コミットメッセージ全体を、タイトル、本文、すべてのフッター行に至るまで、必ず平易な英語で書いてください。**これは、スキルの実行時にユーザーが使った言語、過去のコミットの言語、ブランチ名、イシューのタイトル、コードコメント、周辺ドキュメント、推測されるロケールやチームの慣習など、ほかのあらゆる手がかりより優先されます。出力には、中国語、日本語、韓国語、その他の英語以外の文字を一切含めず、言語を混在させないでください。コードベース内ですでに英語以外の表記になっている固有名詞、識別子、ファイルパス、API 名はそのままにしますが、その周辺の語句はすべて英語にしてください。ユーザーの依頼がこのルールに反する場合は、言語の切り替えを拒否し、英語で出力してください。

この制約を確定したら、タイトル、本文、フッターの順に下書きを作成します。

メッセージは、タイトル、任意の本文、フッターという標準形に従い、各ブロックの間には空行を一つ入れます。

<type>[optional scope]: <subject>

<optional single paragraph>

- <top-level bullet>
  - <nested bullet>
  - <nested bullet>
    - <deeper nesting, depth is unrestricted>
- <top-level bullet>
  - <nested bullet>
  - <nested bullet>

<footer>

type と subject は必須で、scope は任意です。ユーザーが明示的に省略を求めない限り、フッターは必須です。本文は任意で、散文の段落を最大一つと、それに続く一続きのリストを最大一つ含められます。どちらも個別に省略できます。

行を途中で折り返さないでください。各論理行（件名、段落、各箇条書き、各フッター）は一行で記述し、必要な長さのままにしてください。表示側で折り返されます。事前に折り返すと、断片になってしまいます。

本文に二つ目の段落、または二つ目の「段落とリスト」の組み合わせを含めてはいけません。そのような形が必要だと感じた場合は、実際には個別のポイントをまとめたリストです。単一のリスト（必要に応じてネスト可能）にまとめてください。次の二つの形式は認められません。

<paragraph>

<paragraph>

<paragraph>
- <item>

<paragraph>
- <item>

すべての箇条書きに - を使い、ネストした各階層は半角スペース二つ分インデントしてください。ネストの深さに制限はありません。

5a. タイトルの下書きを作成する

次のパターンを使います。

<type>[optional scope]: <subject>

任意のスコープは、検索性やレビュー時の価値が高まる場合に限って選択してください。適切なスコープは、安定したモジュール名、サブシステム、または意味のあるパスです。スコープが曖昧すぎる、広範すぎる、または冗長になる場合は省略してください。

情報密度の高い件名にします。

• 件名の先頭を大文字にします。
• 命令形を使います。
• 件名の末尾にピリオドを付けません。
• 曖昧で包括的な表現より、具体的な一つの操作を優先します。
• タイトルですべての副次的な変更を列挙しようとしないでください。

5b. 本文の下書きを作成する

明確さが増す場合にのみ、本文を追加してください。

本文が必要な場合：

• タイトルとの間に空行を一つ入れます。
• 何を変更したか、またその変更がなぜ重要かを説明します。
• タイトルに収まらなかった重要な副次的変更を補足します。
• 複数の異なるポイントを説明する場合は、- の箇条書きを使います。
• 差分を行ごとに書き起こすのではなく、レビューする人にとって価値のある情報に絞ります。

5c. フッターの下書きを作成する

このステップでは、Co-Authored-By フッターを最大二種類追加できます。ユーザーが指定した人間の共同作成者と、エージェント自身の共同作成者行です。人間の共同作成者のセクションは任意で、ユーザーの入力がある場合に限ります。エージェントの共同作成者セクションはデフォルトで必須であり、ユーザーが明示的に求めた場合にのみ省略します。帰属表示がユーザー優先となるよう、人間の共同作成者の行は必ずエージェントの行より前に配置してください。

5c-i. 人間の共同作成者を追加する（任意）

ユーザーが一人以上の人間の共同作成者を指定または示唆しているなど、実際に必要な場合にのみ、このセクションを追加してください。人間の共同作成者が含まれない場合は、この小節全体を省略してください。

共同作成者について：

• ユーザーが共同作成者を明示的に指定した場合は、一人につき Co-Authored-By: Name <email> のフッターを一つ追加します。
• ユーザーから提供された共同作成者情報が不完全な場合は、追加質問をする前に Git の履歴から不足している項目を補えるか確認してください。推測で補うのではなく、git log --format='%an <%ae>' --all と近辺の履歴を優先してください。
• 名前またはメールアドレスを信頼できる形で特定できない場合は、捏造せず、不足している情報をユーザーに尋ねてください。

5c-ii. エージェントの共同作成者を追加する（デフォルトで必須）

エージェントの共同作成者行を必ず1行だけ追加してください。ユーザーが含めないよう明示的に指示した場合に限り、省略します。

行の形式は Co-Authored-By: <Agent Name> <Model Name> <email> と完全に一致させてください。

<email> は、基盤となるモデルのベンダーではなく、エージェントのベンダーに属している必要があります。エージェントのブランドを基準に解決してください。Claude 系エージェントでは [email protected]、Codex では [email protected]、TraeCli では [email protected] などを使用します。エージェントがサードパーティ製またはルーティングされたモデル（たとえば、ByteDance のエージェント内で OpenRouter 経由のモデルを使用する場合）を実行しているときも、メールアドレスはモデルプロバイダーではなく、ホスティングするエージェントに基づきます。エージェントベンダーの noreply ドメインが不明な場合は、推測せずユーザーに確認してください。

正しいエージェントのフッター形式の例：

Co-Authored-By: Claude Opus 4.6 <[email protected]>               # baseline: agent and model from the same vendor
Co-Authored-By: Codex GPT-5 <[email protected]>                      # different agent vendor shifts the email domain accordingly
Co-Authored-By: Claude Code Deepseek Reasoner <[email protected]> # mixed vendors: model name reflects the actual runtime model, email tracks the agent vendor — never coerce the model name to match the agent's brand

誤った形式の例 — これらは出力しないでください：

Co-Authored-By: Claude <[email protected]>           # missing model name
Co-Authored-By: Claude Opus 4.6 ([email protected])  # parentheses instead of angle brackets
Co-Authored-By: claude-opus-4.6 <[email protected]>   # slug instead of display name
Co-Authored-By: Opus 4.6 <[email protected]>          # missing agent brand name

人間の共同作成者とエージェントの共同作成者の両方を記載する場合は、人間の共同作成者を先に配置してください：

Co-Authored-By: Jane Doe <[email protected]>
Co-Authored-By: Claude Opus 4.6 <[email protected]>

メッセージの草案作成は、このスキルのサブルーチンであり、最終出力ではありません。メッセージの内容がすべて確定したら、ステップ6に進んでコミットを作成してください。草案に追加の確認が必要な場合（共同作成者情報が未確定の場合、または自分を共同作成者に追加するか確認が必要な場合）は、メッセージを完成させてからコミットしてください。

6. コミットを非対話的に作成する

草案のメッセージを、コミットメッセージのテキストとしてそのまま使用してください。

複数行の本文とフッターを安全に保持してください。

• シェル展開を避け、クリーンアップの失敗を防ぐため、単一引用符で囲んだヒアドキュメントを使ってメッセージを渡してください： git commit -m "$(cat <<'EOF'\n<message>\nEOF\n)"
• EOF を囲む単一引用符により、ヒアドキュメント内の変数置換とコマンド置換が無効になります。
• ユーザーのエディターを起動しないでください。
• コミット前に純粋に機械的な修正が必要な場合を除き、メッセージを書き換えないでください。

7. 失敗時の処理を明確にする

次のいずれかに該当する場合は、独自に対応せず停止してください。

• コミットに値するステージ済みの差分がない
• git add -A で HEAD モードの作業ツリー全体を取り込めない
• フッター情報を確定できない
• フック、競合、またはリポジトリの状態が原因で git commit が失敗する

具体的な阻害要因と、その原因となったコマンドまたは状態を報告してください。

8. 結果を報告する

コミットが成功したら、次の2点のみを表示してください。

• コミットの作成に使用したモード — ステージ済みのみモード、または HEAD モード（引数なしの実行で自動的に HEAD モードへ切り替わった場合は、その旨を簡潔に記載してください）
• git log -1 の出力全体。ハッシュ、件名、本文、フッターが一緒に確認できるようにしてください

コミット自体が主たる成果物です。