kairyou/agent-tools

コミットメッセージジェネレーター

ワークフロー

1. git diff --staged を実行してステージングされた変更を確認します。空の場合は、ユーザーに git add を実行するよう伝えて停止します。
2. 以下の言語ポリシーに従って説明文の言語を決定します。
3. メッセージを生成して確認用に表示します。すぐにコミットは実行しません。複数の表現が妥当な場合は、短い番号付きリスト（1)、2)、…）で表示し、ユーザーが番号だけで選択できるようにします。明確なメッセージが1つだけの場合は単独で表示します。ユーザーは編集や独自の文言で返信することもできます。
4. ユーザーが番号を選択するか、「commit」や「ok」と明示的に確認した場合のみ git commit -m を実行します。ユーザーが明示的に要求しない限り git push は実行しません。

言語ポリシー

type(scope): の後の人間が読む説明文には、以下の優先順位を使用します。

1. 現在のターンでユーザーが明示的に要求した言語を使用します。
2. そうでない場合、リポジトリ内の .agent-tools/config.jsonc で at-commit.language が定義されていればそれを使用します。
3. そうでない場合、グローバル設定 ~/.agent-tools/config.jsonc で at-commit.language が定義されていればそれを使用します。
4. そうでない場合、ユーザーの実際の呼び出しテキストに明確で独立した自然言語リクエストが含まれている場合は、その言語を使用します。注入されたスキル指示、引用または貼り付けられたコンテンツ、コードブロック、差分、ツール出力は無視します。
5. そうでない場合、リポジトリの最近のコミット件名の主流言語に合わせます。
6. 主流言語が明確でない場合は、デフォルトで英語を使用します。

この順序を文字通り適用し、最初に一致した項目で停止します。項目2と3は項目4よりも前にチェックします。スラッシュコマンドやスキルの呼び出しだけでは言語はありません。項目5に進みます。最新20件のコミット件名のみを調査します。

Conventional Commits の構文トークン（type、オプションの scope、!、BREAKING CHANGE）は翻訳せずにそのまま保持します。識別子、ファイル名、パッケージ名、コマンド、API名、スコープは元の言語のままにします。

永続的な言語設定

通常のコミット生成中は設定を書き込みません。ユーザーがコミット説明文の言語を記憶するよう明示的に要求した場合のみ、永続化することを提案します。スコープが曖昧な場合は、リポジトリ設定かグローバル設定かを尋ねます。

リポジトリ設定の場合は .agent-tools/config.jsonc を作成または更新し、グローバル設定の場合は ~/.agent-tools/config.jsonc を使用します。

{
  "at-commit.language": "zh-CN"
}

可能な限り無関係なキーやコメントは保持します。事前のインストーラー設定は必要ありません。

ルール

git diff --staged を読み取り、何が変更されたか（WHAT）、および有用な場合はその理由（WHY）を説明する Conventional Commits のタイトルを生成します。

• タイトル: type(scope): description、74文字以内、末尾にピリオドなし、プレフィックスなし、引用符なし、コードブロックなし。
• type: 以下のうち正確に1つを選択:
  • feat 機能追加、fix バグ修正
  • refactor 振る舞いを変えないリファクタリング、perf パフォーマンス改善
  • docs ドキュメントのみの変更、style フォーマットのみの変更
  • test テストの追加/修正、build ビルドシステム/依存関係、ci CI設定/スクリプト
  • chore src/test に影響しない雑多な変更、revert 元に戻す
• scope: 影響を受けるモジュール名（オプション）。このリポジトリの慣習に従います。モノレポの場合はアプリ/パッケージのディレクトリ名を使用します。横断的な変更や不明な場合は省略します。
• description: 選択された自然言語での簡潔な動詞-目的語のフレーズ。「ファイルを更新」「このコミット」「雑多な変更」「複数の変更」に相当するような冗長な表現は避けます。識別子、関数名、ファイル名、パッケージ名、コマンド、APIはそのまま保持します。
• 1行のみ: コミットメッセージは常にタイトル行のみです。ボディやフッターは書きません。必要なWHYはタイトルに詰め込みます。
• 破壊的変更: type(scope)!: description でマークし、依然として1行です。BREAKING CHANGE フッターは使用しません。
• 句読点: ASCII 句読点を使用します。

生成戦略

記述する前に、ステージングされた変更の一貫した筋道を特定します。

• メインライン: このコミットを理解するために必要な情報のみを含めます。変更のポイントでない限り、名前を列挙しません。
• 重要な変更: ロジック、契約、ビルド、品質ゲート、またはユーザーに見える振る舞いの変更をスキャンします。それを使用して type を選択し、! が必要かどうかを判断します。

コンテンツの規律

メッセージは確認されたコード上の事実を述べるものであり、推測された意図ではありません。

• src と test の振る舞いの変更を優先: ドキュメントは補足的なコンテキストに過ぎません。ドキュメントのみからWHATを推測しないでください。
• ユーザーのコンテキストはドキュメントより優先: 明示的なユーザーの目標はWHYや文言の選択に役立ちますが、WHATとスコープはステージングされた差分から取得します。差分に現れていないコンテキストのみの変更を含めないでください。コンテキストと差分が矛盾する場合は、差分に従い確認を求めます。
• 削除とリネーム: コードの関係性から目的が確認できない場合は、差分が証明する内容のみを述べます（例：「Xを削除」「XをYにリネーム」）。コードが証明しない限り、置き換え、移行、因果関係を主張しないでください。
• 同じ目標の複数の変更: 変更が明らかに同じ目標（品質やビルド修正など）に貢献している場合は、1つの要約メッセージを提供します。レビューやロールバックに実質的に役立つ場合にのみ、分割を提案します。
• 無関係なステージング変更: それぞれの一貫した単位に対して分割メッセージと、保守的な要約メッセージ1つを提供します。ユーザーに分割か要約かを選択させ、要約を別のターンに先送りしないでください。
• 所有権や意図が不明瞭な場合: 曖昧なメッセージを強制する代わりに、確認が必要なファイルをリストアップします。意図が不明瞭な場合に「更新」「調整」「微調整」のような弱い言葉を使うよりも、確認や分割を優先します。