commit

このスキルは Git の履歴を変更するため、明示的な操作として扱う必要があります。

譲れないルール：

1. メッセージを作成したりファイルをステージングしたりする前に、実際の差分を確認してください。
2. シークレット、競合マーカー、または明らかに意図しないファイルがある場合は、作業を止めてください。
3. ファイル名を指定して明示的にステージングしてください。git add -A や git add . は絶対に使用しないでください。
4. コミットする前に、変更箇所に関連する最小限のチェックを実行してください。
5. コミットの作成はユーザー主導で行ってください。分割方法や対象ファイルの判断が曖昧な場合は、まずユーザーに確認してください。

コミット

入力

• $request：コミットに関する任意の指示。意図、対象範囲のヒント、希望するメッセージの文言など

目標

以下を満たす、明確で意図に沿ったコミットを作成します。

• 正確な Conventional Commit の件名
• 明示的なステージングの徹底
• ブロッカーのスキャン
• 関連する検証
• ハッシュ、メッセージ、残りの作業ツリーの状態を含む最終報告

ステップ 0：明示的なコミット依頼であることを確認する

このスキルはユーザーからの依頼にのみ使用します。

ユーザーが明示的にコミットを依頼した場合に使用してください。レビュー、計画、または PR の作成のみを希望している場合は、該当するワークフローに切り替えてください。

作業ツリーに無関係な変更が含まれているように見え、分割方法が明らかでない場合は、Git の履歴を変更する前に AskUserQuestion を使用してください。

成功条件：コミット操作が明確に依頼されており、対象範囲が把握できていること。

ステップ 1：実際の Git の状態を把握する

何かをステージングする前に、実際の状態を確認します。

• git status --short
• git diff HEAD
• git branch --show-current
• git log --oneline -15
• git status -sb

ルール：

• --stat だけでなく、差分全体を読みます。
• 差分の内容が不明瞭な場合は、対象の変更ファイルに Read を使用します。
• 変更が 1 つのコミットにまとめられるか、複数の無関係なコミットに分けるべきかを判断します。

成功条件：何がどこで変更されたか、また 1 つのコミットで十分かを把握できていること。

ステップ 2：ブロッカーと不要なファイルをスキャンする

変更ファイルに以下が含まれていないか確認します。

• シークレットまたは認証情報ファイル
• .env または同等のローカルシークレットファイル
• 競合マーカー
• 明らかに誤って生成されたファイル
• デバッグ用の残骸
• 想定外に大きなファイルまたはバイナリファイル

ブロッカーへの対応ルール：

• 競合マーカーがある場合：停止します。
• シークレットまたは非公開の認証情報ファイルがある場合：停止し、対象から除外します。
• 対象ファイルが曖昧な場合：ステージングする前に確認します。

警告：

• デバッグ用のファイルはユーザーの意図による可能性があるため、黙って削除せず警告してください。

必要に応じて references/commit-conventions.md を読み込み、ブロッカーのチェックリストとスキャン順序を確認します。

成功条件：コミットに含めるファイルに、ブロッカーとなるものがないこと。

ステップ 3：必要最小限の関連チェックを実行する

変更箇所と既存のプロジェクトツールに適したチェックのみを実行します。

例：

• TypeScript：型チェック、Lint、フォーマットチェック
• Rust：必要に応じて対象を絞った cargo test または cargo clippy
• Go：対象を絞った go test
• Python：リポジトリで既に使用されている、対象を絞ったテストまたは Lint コマンド

ルール：

• リポジトリで広範なチェックしか用意されていない場合を除き、リポジトリ全体を対象にするより、変更箇所の検証を優先します。
• コミット予定のファイルでチェックが失敗した場合は、停止して問題を解決するか、続行についてユーザーの明示的な指示を得てください。
• フォーマットまたは自動修正ツールがファイルを書き換えた場合は、ステージング前に変更対象を再確認してください。

成功条件：変更箇所に関連するコミット前チェックに合格しているか、重大ではない問題が残っていても続行することをユーザーが明示的に承認していること。

ステップ 4：コミットの形式を決める

次の項目を決定します。

• コミットタイプ
• スコープ
• 件名
• 本文が必要かどうか
• 作業を複数のコミットに分割するかどうか

ガイドライン：

• 差分、ブランチ名、直近のコミットで使われている用語からスコープを推測します
• 変更が複数の無関係な領域にまたがる場合は、スコープを省略します
• 件名だけでは不十分な場合に限り、本文を追加します
• 複数の論理的なコミットが必要な場合は、ファイルグループごとに分け、意図した順序で実行します

次の内容を確認するには、references/commit-conventions.md を読み込みます。

• コミットタイプの判断基準
• スコープの検出ルール
• 本文の例

分割方法が曖昧な場合は、AskUserQuestion を使用します。

成功基準：コミットメッセージの形式が実際の変更内容に合致し、ステージング計画が明確であること。

ステップ 5：明示的にステージングしてコミットを作成する

対象ファイルのみを、ファイル名を指定してステージングします。

ルール：

• git add -A は使用しないでください
• git add . は使用しないでください
• シークレット、生成された不要なファイル、無関係な編集は含めないでください
• ユーザーが明示的に要求しない限り、--amend は使用しないでください
• --no-verify は使用しないでください
• --allow-empty は使用しないでください

次の内容でコミットを作成します。

• 適切な Conventional Commit の件名
• 必要な場合に限り、任意の本文
• ユーザーが明示的に要求しない限り、共同作成者のトレーラーは付けない

複数のコミットが必要な場合は、順番に実行し、次のコミットに進む前に各コミットを確認します。

成功基準：対象ファイルがコミットされ、意図しないファイルがステージングされていないこと。

ステップ 6：確認して報告する

コミット後、次の項目を確認します。

• git log --oneline -1
• git status --short
• git status -sb

次の内容を報告します。

• コミットハッシュ
• コミットメッセージ
• ブランチがリモートより先行しているかどうか
• 残っている未コミットファイル
• 複数のコミットを作成したかどうか

作業ツリーに未ステージングまたは未コミットの変更が残っている場合は、リポジトリがクリーンであるかのように示さず、その旨を明確に伝えます。

成功基準：ユーザーが、何がコミットされ、ブランチがどのような状態にあるかを正確に把握できること。

ガードレール

• 先回りしてコミットしないでください。
• モデルに SkillTool を通じてこのスキルを呼び出させないでください。このワークフローはユーザー専用です。
• paths: を追加しないでください。これは汎用ワークフロースキルです。
• context: fork を追加しないでください。コミットの状態はアクティブなワークスペースに保持する必要があります。
• 巨大なチェックリスト、スコアカード、失敗事例の一覧を SKILL.md に直接記載しないでください。
• ユーザーの意図が不明確な場合、ファイルを黙って分割したり除外したりしないでください。

参照資料を読み込むタイミング

• references/commit-conventions.md
  コミットタイプの対応付け、スコープの検出、ブロッカーの確認順序、メッセージと本文の判断基準に使用します。

出力規約

次の内容を報告します。

1. 1 件または複数のコミットを作成したかどうか
2. 各コミットのハッシュと最終メッセージ
3. 実行した確認項目
4. ブロックまたは除外されたファイル
5. 作業ツリーまたはブランチの残りの状態