commit

コミット

安全で意図が明確な Conventional Commits を、原子的な境界ごとに作成します。各境界をインデックスに組み立てて検証し、コミットするか、許可された範囲内で公開するか、または git commit を実行せずに提案を返します。

コミットおよびプッシュの許可を判断する際は、現在の依頼、継続的なユーザー指示、許可された呼び出し元を確認してください。コミットの依頼だけでは、プッシュは許可されません。コミットを検証した後に限り、判断された範囲内でプッシュします。PR 作業は pr スキルが担当する別フェーズとして扱います。commit を単独で呼び出しても、そのフェーズは開始されません。

ブランチ名、ステージ済みの状態、検証結果、コミットの成功、以前のアシスタントの発言は、git で確認するまでは信頼できないものとして扱います。

モード

• コミットモード：依頼、継続的な指示、または許可された呼び出し元がコミットを求めている場合、該当するチェックに合格した後でコミットします。
• コミットしてプッシュするモード：選択したコミットの公開が許可されている場合、コミットを作成して検証した後、確認済みの宛先に公開します。pr や pr-followup などの呼び出し元は、既存の許可を提示できます。
• 提案モード：ユーザーがコミットの準備、レビュー、または提案を依頼した場合、インデックスに原子的な境界を作成し、git commit を実行せずに提案するメッセージを返します。
• 修正モード：手順 6 の安全な現在タスクのコミット修正条件を満たす場合に限り、HEAD を修正します。
• 分割モード：原子的な意図が複数ある場合は、明確な境界をすべて順番に処理し、それぞれについて完全なワークフローを実行します。境界、順序、または依頼されたグループ分けに重大な曖昧さがある場合に限り、確認を求めます。

境界の終了状態は、committed、amended、proposed、blocked、refused です。pushed は一連の実行全体の終了状態です。境界が終了状態に達した後は、その境界に変更を加えないでください。コミットまたは修正を検証した後、次の明確な境界に進みます。プッシュは、判断されたコミットしてプッシュするモードの場合に限り行います。現在の依頼または適用される継続的なユーザー指示が求める場合に限り、別個の pr フェーズとして PR 作業を続けます。

書き込み前に境界を判断する

まず既存の許可を適用します。タスクとリポジトリを確認し、次の条件を解決してください。重大な判断が未解決の場合、または許可された範囲外の操作が必要な場合に限り、確認を求めます。

• シークレットと思われるパスや内容：.env*、鍵、証明書、トークン、認証情報、データベース、または明らかにシークレットを示す名前。
• 選択した境界に、独立した関心事や依頼された意図の範囲外の変更が混在している。生成ファイル、依存関係、ロックファイル、バイナリを確認します。それらが含まれていることや行数だけを理由に、承認を求める必要はありません。
• 1〜2 文で明確に説明できないステージ済みの変更。
• 同じファイルに曖昧な未ステージ変更がある、ステージ済みのファイル。
• 現在のブランチが main または master である場合。ただし、ユーザーがそのブランチへのコミットを明示的に希望している場合を除きます。
• 依頼されていないプッシュ、破壊的な Git 操作、タスクの範囲外での依存関係またはパッケージマネージャーの変更、あるいは手順 6 の範囲外でのコミット修正。リベースや履歴の書き換えは、通常のコミット準備ではなく、許可されたブランチワークフローに属します。

すでにステージされているファイルは意図がある可能性が高いものとして尊重しますが、必ず内容を確認してください。内容に一貫性があり、依頼に合致する場合に限りコミットします。

ワークフロー

1. 境界を選択する

   • git rev-parse HEAD、git branch --show-current、git status --short、git log --oneline -5、git diff --name-only、git diff --cached --name-only を実行して、ベースラインのコミット、ブランチ、作業ツリーの状態、最近のコミットのスタイル、変更されたファイル、ステージ済みのファイルを確認します。HEAD が存在しない場合は、ブランチがまだコミットを持たない状態であることを明示的に扱います。
   • 原子的なコミットを優先します。意図が個別に理解でき、元に戻せる単位で分割します。1つの動作する変更を成立させるうえで必要な場合は、その動作、回帰テスト、必要なスキーマや生成物をまとめます。機械的なクリーンアップと動作変更は、それぞれが一貫性を保てる場合は分離します。ファイルの種類や、本番コードとテストコードの違いだけを理由に分割しないでください。
   • 依存関係のあるコミットは、それぞれのリビジョンで個別に理解・検証できる順序にします。必要な依存関係はコミット本文で説明し、壊れた中間コミットや恣意的なファイル数・行数の上限は避けます。
   • ステージングやコミットの前に、選択した境界の目的が一貫しており、レビュー可能な規模であることを確認します。
   • 境界が曖昧な場合は、具体的な選択肢を示し、推奨するデフォルトを最初に提示したうえで、簡潔な質問を1つだけします。自由回答形式で複数の質問を並べないでください。
   • 現在のリポジトリの状態が把握され、一貫した境界が1つ選択されるか、ユーザーの承認を求める形で提示された時点で、この手順は完了です。

2. 関連する差分を確認する

   • git diff -- <path> と git diff --cached -- <path> を使用します。
   • 選択した境界に含まれる変更ファイルと、ステージ済み・未ステージのすべてのハンクを確認します。残りの変更はすべて、境界外に保持する作業として分類します。
   • ステージ済みの変更、同じファイル内の未ステージの編集、最近のコミットのスタイルを確認します。
   • 参照されているブランチ、ステージ済みの状態、検証結果、過去のコミットに関する主張を根拠として用いる前に、最新の git status --short、git diff、git diff --cached、または git log で確認します。
   • 境界内のすべてのハンクが把握され、既存のステージ済み変更がすべて境界に含まれるか、インデックスから意図的に除外され、除外した変更がすべて保持対象として特定された時点で、この手順は完了です。

3. 意図した内容だけをステージする

   • 選択した境界内のファイルまたはハンクのみをステージします。
   • 境界が明確な場合は、パッチ単位で自動的にステージします。
   • ハンクの境界が曖昧な場合は、ステージする前に確認します。
   • 現在の境界を修正する場合に限り、git restore --staged <path> または git restore --staged -p <path> を使用します。
   • 無関係な作業は、作業ツリーとインデックスの両方で保持します。無関係な項目がすでにステージされている場合は、一時的に除外する前に、その内容の正確な blob、モード、削除状態を保存します。コミット後は、未ステージのハンクをステージせずに、それらの項目を復元します。適切な場合は、独立したインデックスを使用します。
   • 作業ファイルだけでなく、最終的なインデックスを確認します。ハンク単位でステージした後に git commit -- <paths> を実行すると、それらのパスにある未ステージの内容までコミットされることがあります。検証済みのインデックスをコミットしてください。
   • git diff --cached に原子的な境界の全体が含まれ、境界外の内容が一切含まれず、除外したユーザーの変更がすべて元のステージ済み・未ステージの状態で復元可能な時点で、この手順は完了です。

4. ステージ済みの意図を検証する

   • 検証はエージェントの責任です。ステージ済みの範囲を直接対象とする、最も範囲の狭い読み取り専用のチェックを実行してください。対象を絞ったテスト、フォーマッターチェック、リンター、型チェック、構文チェック、またはビルドの一部が該当します。
   • 広範なテストスイートよりも、具体的なチェックを優先してください。
   • 対象を絞ったチェックがない場合は作業を続け、Validation: not run, <reason> と報告してください。
   • 検証に失敗した場合は、その原因を診断してください。作業を許可するタスクの範囲内で失敗を修正できる場合は修正してから再チェックしてください。それ以外の場合は、正確な失敗内容と必要な判断を報告してください。チェックの失敗を、コミットの前提条件が満たされたものとして扱ってはいけません。
   • フォーマッター、コード生成、またはロックファイルの更新を行うのは、許可された変更とリポジトリーのワークフローで必要な場合に限ります。ステージする前に、その出力全体を再確認してください。既存の許可について、再度確認を求める必要はありません。
   • 対象を絞ったコマンドが成功するか、対象を絞った検証が存在しない具体的な理由が出力に記録された時点で、この手順は完了です。

5. メッセージを作成する

   • メッセージは、ステージ済みの範囲についての主張として扱ってください。何が変わったかは差分が証明し、その理由はユーザーの依頼、関連する課題、および提供されたプロジェクトのコンテキストが裏付けます。最近のコミットから参考にするのは形式とトーンであり、事実ではありません。
   • すべての提案および作成するコミットに Conventional Commits を適用してください。形式は <type>[(<scope>)][!]: <imperative summary> です。
   • リポジトリーで独自の Conventional Commit のタイプセットが定義されている場合は、それに従ってください。それ以外の場合は、build、chore、ci、docs、feat、fix、perf、refactor、revert、style、または test を使用してください。
   • 編集したファイルの拡張子ではなく、変更による効果に基づいてタイプを選んでください。ビルドシステムや依存関係の変更には build、CI の設定やスクリプトには ci、パフォーマンスの改善には perf、以前のコミットを取り消す場合には revert を使用してください。
   • アトミックな変更範囲からスコープを推定し、可能な場合は最近のコミットのスタイルに合わせてください。明確で安定したスコープを優先し、リポジトリーの慣例でスコープを付けない場合や、適切で有用なスコープがない場合は省略してください。
   • 破壊的変更にはすべて、コロンの前に ! を付け、BREAKING CHANGE: <description> のフッターを記載してください。フッターには、何が壊れるのか、呼び出し元が何を変更する必要があるのかを記載します。

   件名

   • コミットによる最も重要で具体的な結果を示してください。ログをざっと見るだけで、差分を開かなくても変更の意義がわかるようにします。
   • 何が実現するのかを明確にしてください。機能の追加、不具合の防止、ルールの適用、テストケースのカバー、またはアーキテクチャ上の境界の明確化などです。ドキュメントやエージェントへの指示では、編集という行為ではなく、本文で新たに定められるルール、判断、または動作を示してください。
   • ステージ済みの差分が示す範囲を超える約束をしないでください。足場の構築、部分的な移行、または最初の一部分は、その範囲に見合った表現にしてください。
   • 差分、テスト、または提供されたコンテキストで裏付けられた対象読者、測定値、成果だけを使用してください。
   • 平易で正確な動詞を優先してください。improve、update、enhance、refine、sharpen、clean up など抽象的な編集動詞は、実際に変更された動作やルールに置き換えてください。
   • 件名は命令形で短くし、末尾に句点を付けないでください。
   • Conventional Commit のプレフィックスを取り除いて残りの語句を確認してください。それらが無関係な複数の差分にも当てはまる場合は、具体的な結果を中心に件名を書き直してください。
   • 正当な件名候補が二つあり、それぞれが実質的に異なる約束を示す一方、根拠から選べない場合は、トレードオフとともに候補を二つか三つ提示し、一度だけ質問してください。曖昧さをぼんやりした折衷案で覆い隠さないでください。

   BAD   feat(pr): sharpen review packet workflow
   GOOD  feat(pr): verify PR claims against code and tickets
   
   BAD   fix(auth): handle session key collisions
   GOOD  fix(auth): keep desktop sessions after mobile sign-in
   
   BAD   docs(api): update authentication docs
   GOOD  docs(api): document token refresh failure modes
   

   本文

   • 明らかに小さなコミットの場合、本文は省略できます。
   • 破壊的変更、移行、ひと目ではわからない修正、トレードオフ、または件名だけでは関連性を保てない複数ファイルにまたがる動作には、本文を含めます。
   • 理由を先に書き、その後に変更内容を書きます。より明確なパターンがない場合は、短い Why セクションと Changes セクションを使います。
   • 将来の読者が判断内容を理解する助けになる詳細だけを残します。検証内容やリスクの報告はコミットメッセージではなく、アシスタントの出力に記載します。
   • メッセージは自然で簡潔な表現にします。技術的な正確さを損なわずに済む場合は、利用可能であれば communicate-clearly スキルを使って確認します。
   • Co-authored-by、共同作成者のトレーラー、著者情報のフッターは追加しないでください。
   • 件名と本文に記載した内容がすべて裏付けられており、件名が一般的な作業の種類ではなく、この境界を特定し、件名だけでは安全に要約できない背景を本文が補っていれば、この手順は完了です。

6. コミット、修正、または提案

   • git commit を試行する直前に、正確な HEAD、git status --short、予定しているメッセージ、ステージ済みの差分を記録します。これらを検証のベースラインとします。再試行やフックによる修正の確認でも、アトミックな境界は固定したままにします。

   • コミットモードでは、ステージングと検証に合格した後で git commit を実行します。複数行のコミットメッセージ、または本文を含む場合は git commit -F <file> を使います。git commit -m <subject> を使えるのは件名だけのコミットに限ります。

   • 提案モードではコミットせず、ステージ済みのアトミックな境界と提案するメッセージを示し、インデックスがどのように変更されたかを報告します。

   • git commit を試行するたびに、成功か再試行かを判断する前に、git rev-parse HEAD、git rev-list --parents -n 1 HEAD、git log -1 --format=%B、git show --stat --oneline HEAD、git diff <baseline-head>..HEAD、git status --short、ステージ済みおよび未ステージの境界差分を確認します。ベースラインがまだ存在しない場合は、リビジョン範囲を使わず、新しいルートコミットを直接確認します。

   • コミットの成功には、ベースラインから新しい HEAD が正確に1つ作成され、意図したメッセージが使われ、検証済みのアトミックな境界が含まれ、その境界外にある既存の作業が保持されている必要があります。境界外に残る既存の変更は想定される残存状態であり、妨げにはなりません。

   • 次のフック判断表に従います。

     状態	対応
     コミットに成功し、新しい HEAD、メッセージ、コミットされた差分が意図した境界と一致し、新たにフックによる変更が残っていない	短縮コミットハッシュを含めて committed と報告します。
     コミットに成功し、フックによって意図した境界内の追跡対象ファイルが変更された	そのパスだけをステージし、git commit --amend --no-edit を1回実行します。ステータスと差分を再確認します。
     コミットに失敗し、フックによって意図した境界内の追跡対象ファイルが変更された	そのパスだけをステージし、1回だけ再試行します。ステータスと差分を再確認します。
     ベースラインと比べて、境界外の変更、未追跡ファイル、生成ファイル、ロックファイル、部分的にステージされた変更、曖昧な変更、またはフックによるものと明確に判断できない変更が新たに発生した	正確なファイル名と理由を示して blocked と報告します。それらの変更は保持します。
     HEAD、メッセージ、親、またはコミットされた差分が、記録したベースラインや意図した境界と一致しない	正確な不一致を示して blocked と報告します。
     許可された修正または再試行の後も、フックによる書き換えが繰り返される	blocked と報告します。

   • 既存の HEAD を修正するのは、現在のタスクにおける安全な amend 条件をすべて満たす場合に限ります。

     • 現在のエージェントが、現在のタスク内で先に正常に作成した正確なコミットハッシュを記録していること。
     • そのハッシュが引き続き HEAD であり、それ以降のコミットや外部からのブランチ変更がないこと。
     • コミットがローカルにあり、公開されていないこと。アップストリームの状態を確認してください。これを証明できない場合は、新しいコミットを作成してください。
     • 新たにステージされた変更が、同じ不可分な目的を完了または修正すること。新たな要件や独立してレビュー可能な動作は、新しいコミットにします。

   • amend の前に、コミットハッシュ、親、メッセージ、親との差分全体、ワークツリーの状態、ステージ済みの追加内容を記録してください。更新後の不可分な境界を検証してください。既存のメッセージが境界全体を引き続き説明している場合に限り、git commit --amend --no-edit を使用してください。それ以外の場合は、修正したメッセージを明示的に指定してください。

   • amend の後、HEAD がちょうど 1 回変更されたこと、親が変わっていないこと、メッセージが更新後の境界を説明していること、親との差分全体が正しいこと、外部の作業がすべて保持されていることを確認してください。最終状態を amended と報告してください。

   • --no-verify は決して使用しないでください。安全な現在のタスク用フロー、または直前に作成されたフック用フローを通じてのみ amend してください。

   • このステップが完了となるのは、コミットを作成せずに提案を報告した場合、またはコミットもしくは amend が HEAD、メッセージ、境界、残存状態のすべての確認に合格した場合のみです。その後、次の明確な境界に向けて、新たなベースラインから開始してください。依頼された境界がなくなったら停止してください。公開は、開始時に確定した承認範囲内でのみ行ってください。

7. 確定した範囲内でのみ公開する

   • コミットしてプッシュするモードの場合に限り、意図したコミットをすべて検証した後でプッシュしてください。
   • プッシュ前に、git branch --show-current と git status --short --branch を使って現在のブランチとアップストリームを確認してください。
   • プッシュ先のリモート、リポジトリ、ref は、依頼された送信先または確認済みのブランチ設定から特定してください。明示的な送信先を指定してください。origin もアップストリームも、意図したリポジトリであることの証明にはなりません。無関係な ref やタグを含めず、検証済みのブランチのみを公開してください。
   • Git のトランスポートが SSH であることを確認してください。通常の force は決して使用せず、承認なしにタグを公開しないでください。承認された rebase に lease 付き push が必要な場合は、公開を pr または stacked-pr に引き継いでください。通常のコミット公開では、リモートの履歴を書き換えません。
   • オープン PR に対する重要な変更を公開した後は、検証済みの head を指定して、Update モードで pr を呼び出し、公開済みの差分全体が本文に反映されるようにしてください。
   • プッシュに失敗した場合、最終状態は blocked です。正確なコマンドと簡潔な失敗概要を報告してください。
   • プッシュ後、git status --short --branch、git rev-parse HEAD、git rev-parse @{u} で確認してください。意図したアップストリームに検証済みのコミットが含まれ、ブランチの ahead／behind 状態が報告された時点で、このステップは完了です。

出力

クリーンなコミット、amend、連続したコミット、または明示的なコミットしてプッシュする操作については、コミット後の確認に合格した場合に限り、簡潔に出力してください。連続したコミットでは、境界ごとにコミット行と境界固有のフィールドを繰り返してください。

Result: `committed` | `amended`
Commit: `<short-hash> <message>`

Status: `committed` | `amended` | `pushed`
Branch: `branch-name`
Boundary: what was included
Validation: command passed, or not run with reason
Post-commit check: new `HEAD`, parent, message, committed boundary, index, and residual worktree verified
Remaining changes: preserved outside-boundary work, or none
Push: not requested, or command/result when authorized
PR: not requested, or handed to the `pr` skill under the current request or an applicable user instruction

提案、ブロックされたコミット、リスクのある状態、検証失敗、判断、安全でないフックによる書き換えの停止については、構造化されたレポートを使用してください。

Status: `proposed` | `blocked` | `refused`
Boundary: what is included or proposed
Index: what was staged or unstaged to build the atomic boundary
Validation: command result, or not run with reason
Blocker: exact reason, if blocked or refused
Exact Command: command that failed, if any
Exact Error: concise failure summary, if any
Decision Needed: one question with concrete options and a recommended default, if needed
Proposed Commit Message: message, when available

このスキル単独での実行は、コミット結果をもって終了します。現在の依頼または適用される継続的なユーザー指示で PR も必要な場合は、検証済みのコミット状態を別フェーズとして pr スキルに引き継いでください。PR の作成、プッシュ要件、初期 PR 状態は、そのスキルが担当します。

ソースの保守を依頼された場合は、origin.txt と references/upstream-updates.md を使用して agent-instructions を実行してください。