vibe-commit

Vibe Commit

概要

コミットの依頼が意味するのは、対象範囲が適切でクリーンなコミットを1つ作成することであり、git add -A && git commit を実行することではありません。ユーザーに見える変更を選び、無関係または安全でないパスを除外し、ステージ済みの差分を読み、メッセージを安全に渡して、保存されたコミットを確認します。コマンドのみ、または表現された状態についての依頼では、実行したと主張せず、該当する手順を示します。ブロックされた依頼では、阻害要因がある時点で停止します。

メッセージの内容とコミットの実行

このスキルが担当するのは、ステージング、検証、メッセージの受け渡し、トレーラー、および履歴の安全性です。メッセージを準備、確認、修正、または修復する際は、必ず references/history-and-trailers.md を使用してください。定例の検証（実行したコマンド、合格したチェックやスイート、テスト件数、レビュアーやモデルへの謝辞）は、コミットメッセージの内容ではありません。別途報告してください。ユーザーまたはリポジトリのルールで検証セクションが求められる場合は、それに従います。返信のみで計画を示す場合は、提示された証拠だけを使用してください。提示された状態に合格した記録がないチェックは、合格ではなく not run です。

権限と安全性の境界

ローカルでのコミットは取り消し可能ですが、公開は取り消し可能ではありません。ユーザーが指示しない限り、その境界を越えず、取り消し可能な範囲にとどめてください。

効果と書き込みの境界

各フェーズで宣言された効果の分類と境界を超えて、何も書き込まないでください。

• フェーズ自身の記述で宣言された効果の分類を適用してください。このパッケージがより狭い制限を定めている場合は、より狭い制限が優先されます。
• 読み取り専用：チャットで報告してください。ファイルを編集したり、状態を変更するコマンドを実行したりせず、ステージング、コミット、タグ付け、プッシュ、バージョン変更、データ削除、サービスの起動を決して行わないでください。ユーザーが保存用の成果物を明示的に依頼した場合に限り、ファイルを書き込めます。
• 成果物のみ：そのフェーズが担当する成果物と、確認済みの計画の反映や意思決定記録など、フェーズの記述で宣言された補助パスだけを作成または更新し、作業ツリーに残してください。
• 成果物のみのフェーズで、実行可能な動作を実装したり、実装としてコードやテストを編集したり、別のフェーズの成果物を作成したり、リリース作業を行ったり、成果物を同じターンの実装権限として扱ったりしてはなりません。
• 状態変更あり：宣言された範囲内でのみ編集とコマンド実行を行い、検証済みの最小単位にとどめてください。ユーザーが対象として選ばない限り、その他のパス、既存の変更、ランタイムまたは外部の状態には触れないでください。
• これらの制限は、ファイルツールだけでなく、リダイレクト、sed -i、tee、mv、cp、rm、git checkout -- などのシェルコマンドにも適用されます。書き込みを拒否した場合は境界による停止として報告し、別のツールを使って再試行してはなりません。
• 取り消し不能な操作や外部に影響する操作は、それぞれ個別に同意を得て行ってください。

このワークフローで宣言される範囲は、実行するコミット（そのインデックス、履歴、メッセージ）であり、ソースは編集しません。

.gitignore と合意した範囲を尊重してください。 無視されている理由と生じるリスクをユーザーに伝えたうえで、ユーザーがその無視対象パスを含めるよう明示的に依頼しない限り、git add -f で無視対象パスを追加してはなりません。コミット対象の変更範囲外のファイルをステージしてはなりません。

永続的な記録

コミットする前に、docs/decisions/README.md を確認してください。インデックスがない状態で docs/decisions/ が存在する場合は、記録そのものを確認し、ステージ済みの差分が paths に該当する承認済み記録がないか調べてください。該当する記録がある場合、ファイル一式に意思決定記録または調査結果レポートが含まれる場合、および意思決定や調査結果を次の担当者に引き継ぐ前には、references/durable-records.md を読んでください。このフェーズでは通常、docs/decisions/ も docs/reports/findings/ も書き込みません。参照資料で定められた引き継ぎパケットとして、それらを次の担当者に渡してください。

コミットの選択

コミットを選択できるのは、ユーザーからの明示的な依頼、確定済みの計画項目、またはワークフロー自身が検証したチェックポイントのみです。

• コミットする前に、根拠を明示してください。現在のユーザーからの依頼、承認済みの確定計画チェックポイント、またはこのワークフローが検証した独自の作業単位に対するチェックポイントの既定動作のいずれかです。該当する根拠がなければ、コミットせず、変更を作業ツリーに残してその旨を伝えてください。
• ルーティング、呼び出し、編集許可、都合のよい中断地点、追跡対象の変更、利用可能なコミットワークフローを、根拠として扱ってはいけません。コミット実行自体には、独自のチェックポイントの既定動作はありません。
• チェックポイントの既定動作：自己完結した単位の実装、検証、レビューが完了し、重要な調査結果への対応が済んだら、別途指示を待たずに、その単位だけをローカルでコミットしてください。複数の単位を未コミットのまま積み上げてはいけません。
• 調査のみ、ブロック中、変更なし、失敗、未検証、作業中の状態から、コミット対象を選択してはいけません。
• その単位だけをステージしてください。このワークフローが行っていない既存の変更と、単位の範囲外のパスは除外してください。その単位を他の変更から切り分けられない場合は、混在している状態を報告して確認を求めてください。
• 単位が作成し、必要とする新しいファイルは、認証情報や秘密情報を含まない限り、その単位に含めてください。生成物、作業用ファイル、レポートを含めるのは、明示的な追跡の意図がある場合、または必須の依存関係がある場合のみです。
• 選択した各コミットは、対象範囲、テストとレビューの証拠、除外項目、提案するメッセージとともにコミット実行に引き渡してください。ステージング、差分のレビュー、メッセージの受け渡し、コミット後の検証は、そのワークフローが担当します。
• 以前のコミット自体の不具合を修正するために選択した変更は、リモート追跡参照、タグ、別のブランチ、または別のワークツリーにそのコミットが存在しない場合、確認を求めずにそのコミットへまとめてください。それ以外の場合、またはまとめる処理に失敗した場合は、別途コミットし、その理由を伝えてください。
• そのまとめ処理を除き、プッシュ、アメンド、リベース、HEAD を移動するリセット（soft、mixed、hard）、filter-* による書き換え、スクリプトによる複数コミットの再適用には、ユーザーの明示的な許可を得てください。コミットの依頼やチェックポイントが、その許可を与えることはありません。公開済みの履歴は共有されています。
• コミットの依頼やチェックポイントを、リリース、バージョン変更、タグ、stash、上記のまとめ処理を超えるスカッシュ、破壊的なクリーンアップ、強制追加、単位の範囲外にある新しい成果物の追跡、外部への副作用への同意として扱ってはいけません。それぞれに個別の許可が必要です。

例：「ユーザーが今回のターンでコミットを依頼した」は根拠になります。「ここはちょうどよい中断地点だ」は根拠になりません。

例外：現在のコミット禁止指示、コミットを禁止する確定済み計画、またはプロジェクトのポリシーがある場合、既定動作は一時停止されます。検証済みの変更を作業ツリーに残し、その理由を報告してください。

このワークフロー自体がコミット実行です。対象パスを指定したチェックポイントの引き継ぎは、そのパスを対象とするコミット依頼として渡され、以下のすべての条件を満たす必要があります。

履歴の安全性

共有された履歴を書き換えないでください。 このマシンから外に出ていないコミットのみ、修正またはリベースしてください。プッシュ済みの履歴を書き換える許可を求める場合や、共有ブランチに強制プッシュする場合は、同じ回答でその影響も伝えてください。ほかのクローンとの履歴が分岐し、共同作業者がリベース、リセット、または重複したコミットの調整を余儀なくされる可能性があります。また、提示する修正方法を、それぞれ明記してください。後続のコミットで不具合を修正できるかどうかも含めてください。

スクリプトによる書き換えで、別途確認を得ることなく現存ファイルを削除してはいけません。 スクリプトやループを使った複数コミットの書き換えで履歴からパスを削除する場合、各コミットの対象リストは、そのコミット自身のツリーから取得してください（ディレクトリのリテラルなプレフィックスを指定した git ls-tree -r を使います）。git status や別のワークツリーのスナップショットから取得してはいけません。そうすると、そのコミットとは無関係なファイルまで削除されます。範囲とツリーの照会が成功したことを確認してから、空の結果を信頼してください。解決済みのリスト全体を表示し、削除の前に明示的な確認を求めてください。スクリプトがそのまま通過できるプレビューは確認の代わりにはなりません。また、バックアップがあっても削除の許可にはなりません。references/history-and-trailers.md に従ってください。

スクリプトによるトレーラー修正とパス削除のリプレイが対象とするのは、単純な未プッシュの直線的な範囲のみです。マージコミットには別途計画が必要です。トレーラー修正では、競合、メタデータ保持の欠落、トレーラーの重複、またはブランチの移動が発生した場合、元のブランチを付け替えずに停止します。

基本ワークフロー：「commit please」→クリーンなコミット1つ

この流れに沿ってください。各手順では重要なコマンドを示し、判断が必要な点については参考資料で詳しく説明しています。

1. すべてを把握します。 git status --short --branch --untracked-files=all と git status --ignored を実行すると、変更済み、ステージ済み、未追跡、無視対象のすべてのパスを一度に確認できます。git log -1 --oneline と git branch --show-current も実行し、現在のブランチと、変更を加える可能性のあるコミットを把握します。
2. 意図を確認します。 実際の変更内容を読みます。まず git diff --stat を実行し、次に対象ファイルには git diff -- <file>、未追跡ファイルには git diff -- <newfile>（またはファイルを開く）を使います。含めるかどうかを決める前に、各パスが何であるかを判断します。
3. 分類して選定します。 変更されたすべてのパスを、（a）実装とそのテスト、およびそれが満たすドキュメント／CHANGELOG／仕様からなる、一つの論理的な変更としての中心的な成果物と、（b）対象外の編集または生成物に分類します。新たに選定する未追跡の成果物には、明示的な追跡意図、またはリポジトリや所有ワークフローとの必須の結び付きが必要です。関連性、配置、同じセッションで作成されたこと、あるいはコミットの許可があることだけでは、候補となるにすぎません。その単位の変更によって新たに作成され、必要とされるソース、テスト、フィクスチャのファイルは、その単位との結び付きがあるため、認証情報やシークレットを含まない限り、その単位に含めます。生成物、一時ファイル、レポートにも、明示的な追跡意図または別の必須の結び付きが必要です。無関係な懸案事項は別々のコミットに分けます。一つの誠実な共通契約ではパッチ全体をカバーできない場合に限り、分割します。references/file-selection.md を参照してください。
4. 意図的に除外します。 生成物、一時ファイル、所有者のいない計画／仕様、ビルド成果物、無関係なロックファイル、エージェントの状態（.agents/、.claude/、.codex/）、シークレットに該当するパスはステージせず、それぞれを除外する理由を伝えます。所有ワークフローのスコープ付きチェックポイント引き継ぎで指定された、要件または計画に関する確認済みの成果物は、一般的な一時ファイルではなく、所有されたコンテンツです。 選定したコミットに必要な依存関係の変更を記録するロックファイルは、マニフェストとともに対象に含めます。ロックファイルという理由だけで除外してはいけません。あるパスが無視対象かどうか不明な場合は、git check-ignore -v <path> を実行します。references/file-selection.md を参照してください。
5. 明示的にステージします。 完全なパス名を使って git add -- <path1> <path2> … を実行します。ダーティな作業ツリーで git add .／-A／グロブを使うと、無関係なファイルまで気付かずに取り込んでしまうため、避けてください。対象内と対象外のハンクが混在するファイルには、git add -p <file> を使います。
6. ステージ内容を再確認します（必須ゲート）。 コミット前に、コミットしようとしている内容を確認します。git diff --cached --name-only（正確なファイル一覧）、git diff --cached --stat（変更量の妥当性）、git diff --cached（ハンクの確認）、git diff --cached --check（空白／改行コードのエラー確認）を実行します。対象ファイルが含まれ、対象外／無視対象のファイルが含まれず、差分が意図と一致していることを確認します。明示された検証の前提条件は、候補となるバイト列を対象にする必要があります。付随的なテストレポートによって、新たな前提条件が生じることはありません。このターンでファイルのパッチ全体を自分で読み、同じベースに対するステージ済みパッチがメタデータも含めて完全に一致すると証明できる場合に限り、そのパスのハンクの再読を省略できます（たとえば、git diff --cached -- <path> のハッシュと、その読み取り時に保存したハッシュを比較します）。ファイル数、別のパッチや不完全なパッチのハッシュ、レビュー担当者による確認、テスト、未変更パスについての主張は、いずれも証明にはなりません。コミットを実行する前にゲートの出力を読みます。フックや終了ステータスの確認で、その確認を代替することはできません。
7. メッセージを実際の対象差分と整合させます（必須の内部ゲート）。 最終的にステージされたパッチ全体を読み、すべての重要な懸案事項を、提案する種別、スコープ、結果、本文での説明、一つのコミットにまとめるか分割するかの判断に対応付けます（手順6で証明したパスについては、その証明を代用できます）。ソースに変更があれば、再度整合性を確認します。変更されたパスが承認済みの決定記録で指定されている場合は、作業を止め、適合していない点をユーザーに報告して解決を求めます。
8. 既存コミットにまとめるか、新たに追加します。 以前のコミット自身の不具合を修正する場合、条件を満たしていればそのコミットにまとめます。HEADの場合は amend し、それより前の場合は git commit --fixup=<sha> を実行してから、GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash <sha>^ を実行します。これには、作業ツリーがクリーンであること、autostashを使わないこと、対象範囲にマージコミットがないこと、修正が後続コミットに依存しないことが必要です。それ以外の場合は新しいコミットを追加し、その理由を伝えます。まとめる条件を満たしている場合、ユーザーの許可は不要です。復旧用に変更前のHEADを記録して報告し、修正によって対象コミットの説明内容が変わらない限り、対象のメッセージを維持します。また、手順9～10に置き換えます。適用条件と手順については、references/history-and-trailers.md を参照してください。
9. メッセージを作成します。 Conventional Commits の形式 type(scope): summary（命令形、72文字以内）で結果を表す件名を付け、空行を挟みます。件名と差分だけでは変更の理由が伝わらない場合は、本文を記載し、まず理由を説明します。件名のみを認めるルールがある場合も同様です。上記のとおり、通常の検証内容は含めません。本文に記載できる検証結果については、references/history-and-trailers.md の「Compact message rules」を参照してください。まず git log -5 --format='%H%n%B' を実行して、リポジトリのトレーラー規約を確認します。
10. メッセージを安全に渡します。 複数行の本文がある場合は、ヒアドキュメント（git commit -F - <<'EOF' … EOF、区切り文字はシングルクォートで囲みます）または git commit -F <file> を使います。作成者情報のトレーラーを追加または修正する場合は、本文や合成したメッセージのペイロードに直接入力せず、git commit ... --trailer 'Key: value' を使います。これには、ローカルでの書き換えにおける git commit --amend ... --trailer や git commit -C <ref> --trailer ... も含まれます。単一の -m に生の改行を含めてはいけません。references/history-and-trailers.md を参照してください。
11. 保存されたコミットを検証します。 git show -s --format=%B HEAD とコミット済みのパッチを読みます。まとめ直した場合は、新しいSHAの対象コミットのメッセージと統合済みパッチを読み、後続コミットと最終的な作業ツリーが検証済みの状態と一致していることを確認します。git status --short を使い、意図したファイルだけが残っていることを確認します。不一致を修正する場合は、そのコミットをまとめる条件を満たしている間に限ります。それ以外の場合は作業を止め、問題を報告します。
12. 誤りがあれば、元に戻せる方法で復旧します。 破壊の少ない方法を優先します。ステージを解除するには git restore --staged <file>、変更を保持したままコミットを取り消すには git reset --soft HEAD~1、作成直後のローカルコミットを修正するには git commit --amend --no-edit --trailer … を使います。HEADを移動するリセットには、事前にユーザーの明示的な許可が必要です。まとめる条件を満たすコミットへの amend には不要で、git restore --staged にも不要です。references/staging-and-recovery.md を参照してください。

依頼の範囲がより限定されている場合

すべての呼び出しが「コミットしてください」という全般的な依頼とは限りません。該当するリファレンスを参照してください。

• 応答のみを求めるタスクで、リポジトリの状態が提示され、現在のチェックアウトを調査または変更しないよう指示されている → 提示されたステージ済み、未コミット、検証、権限、履歴に関する事実を対象の状態として扱います。実行せずに、適用される判断とコマンドのゲートをすべて示してください。提示された変更を空の評価用サンドボックスに置き換えたり、提示されたコマンドが実際に実行されたと主張したりしてはいけません。
• 「正しいものをステージしましたか？」「ステージ済みの内容を確認して」「コミットを分けて」「紛れ込んだファイルを除外して」 → references/staging-and-recovery.md
• 「これをコミットしたが、コミットすべきではなかった」、取り消し／ステージ解除、誤ったファイルの組み合わせの修正、失われた作業の復元 → references/staging-and-recovery.md
• 直近のコミットを修正、amend、メッセージを書き換え、Co-Authored-By を追加／修正、複数行メッセージの破損を修復 → references/history-and-trailers.md
• 書き換えで複数のコミットにわたるパスを除外または削除する必要がある（トレーラーの修正だけではない） → references/history-and-trailers.md
• 「何をコミットし、何を含めないべきか？」、生成ファイルやシークレットファイルの除外 → references/file-selection.md
• 「ステージ済みの変更をコミットして」 → 追加のステージングを勝手に行わず、コミット前に必須のステージ済みセットのゲートを実行し、コミット後に保存されたコミットを検証してください。
• 「正確なコミットコマンドを見せて」または「コミットコマンドだけ」 → 正確な git commit ... の実行を含めますが、回答をその1行だけに絞ってはいけません。安全な成果物はコマンドシーケンスです。ステージ済みセットの検証、コミットコマンド、保存されたメッセージとファイルセットの検証をこの順に示してください。単純なドキュメントのコミットやトレーラーだけのコミットも例外ではありません。
• ユーザーが git status、git diff、git log の抜粋を提示している → それらを証拠として扱いますが、シーケンス内で対応する調査コマンドも実行するか提示してください。提示された抜粋から、ステージング、コミット、amend、分割へ直接進んではいけません。
• コミットの件名に根拠が必要 → 実行可能な git commit を示す前に、具体的な Conventional Commit 形式の件名を選ぶか、コミットコマンドの前で止めてください。ユーザーの意図が大まかでも、提示された意図を使ってください。機能、バグ修正、モジュール、動作変更のいずれかが明示されていれば、控えめな件名を付けるには十分です。より具体的にするためだけに、diff の結果が出るまで使える大まかな件名を先送りしてはいけません。パスやステータスだけが根拠で、動作や修正の種類が提示されていない場合は、先に git diff または git diff --cached を調べてください。応答のみのコマンド計画では、その調査手順を示し、具体的な件名を書けるまで git commit を省いてください。件名に山括弧のテキスト、未解決であることを示す語、後で件名を埋めるよう指示する文言が含まれるコミットコマンドブロックは、説明文で実行しないよう書いてあっても、提示するコマンドとして無効です。
• 部分的なステージングが必要 → ファイルを指定した diff で両方を検証してください。コミットするハンクには git diff --cached <file>、意図的にローカルに残すハンクには git diff <file> を使います。コミット前に、両方の明示的な検証コマンドを示してください。説明文の注記や git status で代用することはできません。
• ユーザーが指定したパスが git status にない → 判断する前に git check-ignore -v <path> を確認してください。特にローカル設定やシークレットのようなデータが無視されている場合は、パスが指定されたという理由だけで強制追加してはいけません。無視ルールを把握したうえで明示的な上書きが行われない限り、依頼された範囲を完全にはコミットできないと伝えてください。