aif-commit

Conventional Commit ジェネレーター

Conventional Commits の仕様に従ってコミットメッセージを生成します。

ワークフロー

最初に： .ai-factory/config.yaml が存在する場合は読み込み、以下を確認します。

• パス： paths.description、paths.architecture、paths.rules_file、paths.roadmap、paths.rules、paths.plan、paths.plans
• 言語： プロンプトとコミットメッセージの規約に使用する language.ui
• ワークフロー： 読み取り専用のアクティブな計画の検出に使用する workflow.plan_id_format（既定値は slug、sequential の場合は番号付きの完全な計画を検索します）
• Git の設定： アクティブな計画の検出とコミット後のプッシュ動作に使用する git.enabled、git.create_branches、git.skip_push_after_commit
• ルールの階層： rules.base と、名前付きの rules.<area> エントリ

config.yaml が存在しない場合は、既定値を使用します。

• パス：コンテキストアーティファクトには .ai-factory/、paths.plan には .ai-factory/PLAN.md、paths.plans には .ai-factory/plans/
• 言語：en（英語）
• ワークフロー：workflow.plan_id_format: slug
• Git：git.enabled: true、git.create_branches: true
• Git の設定：skip_push_after_commit: false

.ai-factory/skill-context/aif-commit/SKILL.md を読み込んでください — ファイルが存在する場合は必須です。

このファイルには、パッチ、コードベースの規約、技術スタックの分析に基づき、/aif-evolve が蓄積したプロジェクト固有のルールが記載されています。これらのルールは、現在のプロジェクトに合わせて調整されています。

skill-context のルールの適用方法：

• このスキルの一般的な指示に対するプロジェクトレベルの上書きとして扱います
• skill-context のルールがこの SKILL.md に記載された一般的なルールと矛盾する場合は、skill-context のルールを優先します（より具体的なコンテキストが優先されます。同じ原則がネストされた CLAUDE.md ファイルにも適用されます）
• 矛盾がない場合は、SKILL.md の一般ルールと skill-context のプロジェクトルールの両方を適用します
• skill-context のルールがこのスキルの既定値と矛盾しているように見えても、無視しないでください。プロジェクトでの経験により、既定値では不十分であることが判明したために設定されています
• 重要： skill-context のルールは、コミットメッセージの形式や規約を含め、このスキルのすべての出力に適用されます。skill-context のルールに「コミットは必ず形式 X に従うこと」や「メッセージに必ず Y を含めること」とある場合は、必ず従ってください。skill-context のルールに違反するコミットメッセージを生成するのはバグです。

適用の確認： 出力アーティファクトを生成した後は、すべての skill-context のルールに照らして検証してください。違反がある場合は、ユーザーに提示する前に出力を修正してください。

1. 変更を分析する

   • git status を実行し、ステージング済みのファイルを確認します
   • git diff --cached を実行し、ステージング済みの変更を確認します
   • ステージング済みのファイルがない場合は、警告を表示してステージングするよう提案します

2. アクティブな計画のコンテキストを解決する（読み取り専用、任意）

   • 次の優先順位で、読み取り専用でアクティブな計画を解決します。
     1. @ で始まる引数の場合は、@<plan-file-or-directory> 引数
     2. paths.plans にあるブランチベースのフルプランまたはウルトラバンドル
     3. paths.plans にある単一のフルプラン、または単一のウルトラバンドル
     4. paths.plan にある高速プラン
   • 引数が @ で始まらない場合は、引き続きコミット範囲／コンテキストとして扱います。
   • 従来の @<plan-file> 構文も引き続き有効です。拡張形式では、ウルトラディレクトリまたはその index.md も使用できます。
   • ブランチベースのフルプランを検索する場合：
     • git.enabled = true の場合、git branch --show-current で現在のブランチを取得します。
     • / をすべて - に置換して、<branch-stem> を取得します。
     • workflow.plan_id_format = sequential の場合、Glob を使って次の両方を検索します。 paths.plans/[0-9][0-9][0-9][0-9]_<branch-stem>.md と paths.plans/[0-9][0-9][0-9][0-9]_<branch-stem>/index.md
     • ディレクトリ候補をすべて読み込み、index.md に `` が正確に1つ含まれる場合にのみ候補として残します。
     • 有効な成果物のうち番号が最も大きいものを使用し、有効な候補が複数ある場合は WARN [aif-commit] を出力します。両方の形式で最も大きい番号が同じ場合は、ウルトラを優先します。
     • 有効な連番形式の一致がない場合は、 paths.plans/<branch-stem>/index.md、次に paths.plans/<branch-stem>.md を確認します。選択前にディレクトリのエントリポイントを読み込み、ウルトラマーカーが正確に1つ含まれていない場合は無視します。有効な形式が両方ある場合は警告を出し、ウルトラを優先します。
   • Git モードがオフの場合、ブランチを特定できない場合、またはブランチベースの計画が存在しない場合は、ルート直下の *.md フルプランと、`` を含む直下の子ディレクトリにある */index.md エントリポイントの数を数えます。解決済みの高速プランのパスは除外し、フェーズファイルは数えません。
   • 明示的に指定されたウルトラディレクトリを正規化する前、または明示的に指定された index.md をウルトラとして扱う前に読み込み、`` が正確に1つ含まれていることを確認します。そうでない場合は、計画の整合性エラーで処理を停止します。
   • 自動検出されたディレクトリのエントリポイントは、`` を含む場合にのみ対象とします。無関係な */index.md ファイルは無視します。
   • アクティブな計画を解決できない場合、またはアクティブな計画のエントリポイントに ## Commit Plan がない場合は、現在のステージ済み差分の動作を変更しません。
   • このコマンドからアクティブな計画を変更してはいけません。

3. 利用可能な場合はコミット計画によるグループ分けを使用する

   • アクティブな計画に ## Commit Plan が含まれている場合は、次の項目を解析します。

     • コミットグループ番号／名前
     • タスク範囲（例：after tasks 1-3 または tasks 4-6）
     • 推奨される Conventional Commit メッセージ

   • 計画の ## Tasks または ## Implementation Tasks セクションを読み、タスク範囲をタスクの説明および Files: のヒントに対応付けます。

   • ultra プランの場合は、現在のコミットグループ内の各タスクについて Phase Index／詳細リンクを特定し、対応する各フェーズファイルを読み、その ## Files to Change テーブルと完全な ## Task N の仕様からステージ対象パスの対応付けを作成します。index.md だけを読むのでは不十分です。

   • 1つのフェーズに複数のコミットグループのタスクが含まれている場合は、個々の ## Task N セクションを使ってファイル／差分の所有範囲を区別します。タスクレベルの根拠なしに、そのフェーズのファイルテーブル全体をすべてのグループに割り当てないでください。

   • ステージングを変更する前に、ステージ済みのファイル／差分と計画されたグループを比較します。

     • git diff --cached --name-only でステージ済みファイルのパスを確認します
     • 1つのファイルが複数のグループにまたがる可能性がある場合は、git diff --cached でステージ済み差分の根拠を確認します
     • タスク範囲と Files: のヒントは参考情報であり、実行指示ではありません

   • ファイルをグループに対応付けられない場合は、停止してグループ分けを調整するようユーザーに依頼します。

   • ファイル全体をステージングする前に、グループ対象ファイルと git diff --name-only による未ステージのワークツリーパスを比較します。

   • 計画された各グループのファイルセットが互いに重複せず、グループ対象ファイルが git diff --name-only に含まれていない場合に限り、git add <files> を使用します。

   • 1つのファイルが複数の計画グループにまたがる場合は、各グループに対して差分単位のステージング（git add -p または git apply --cached）を使用します。

   • グループ対象ファイルが未ステージのワークツリーパスと重複する場合は、グループごとに元のキャッシュ済みパッチを保持して適用（git diff --cached + git apply --cached）するか、差分単位のステージングを使用するか、ステージングを変更する前に停止します。

   • 差分単位のステージングを確信を持って適用できない場合は、ステージングを変更する前に停止し、グループ分けの調整またはすべてをまとめてコミットするようユーザーに依頼します。

   • 使用可能なグループ分けがある場合は、次のように尋ねます。

     AskUserQuestion: アクティブな計画に Commit Plan が含まれています。ステージ済みの変更をどのようにコミットしますか？
     
     Options:
     1. Commit Plan に従う
     2. すべてをまとめてコミットする
     3. グループ分けを調整する
     

   • Commit Plan に従う → 計画されたグループとメッセージを確認してから、ユーザー確認済みの複数コミットのステージング／コミット手順に進みます。

   • すべてをまとめてコミットする → 今回は計画のグループ分けを無視し、現在の単一メッセージの手順を続行します。

   • グループ分けを調整する → ユーザーに調整後のグループ分けを尋ね、コミット前にステージ済みファイルと照合します。

4. コンテキストゲートを実行する（読み取り専用）

   • 解決済みのアーキテクチャおよび説明アーティファクト（設定のパスを使用）を確認し、明らかなスコープ／境界の逸脱を検出します
   • 解決済みの RULES.md およびロードマップのアーティファクト（設定のパスを使用）を確認し、ルールおよびマイルストーンとの整合性に問題がないか確認します
   • コミット規約について、ルール階層（解決済みの paths.rules_file + rules.base + 名前付きの rules.<area>）を確認します
   • 任意のファイル（ROADMAP.md、RULES.md）が存在しない場合は、ブロッカーではなく WARN とします
   • このコマンドからコンテキストアーティファクトを変更しないでください
   • ユーザーがルールのみの単独チェックを希望する場合は、/aif-rules-check を提案します。/aif-commit のゲートラベルは WARN／ERROR のままにしてください

5. コミット種別を決定する

   • feat：新機能
   • fix：バグ修正
   • docs：ドキュメントのみ
   • style：コードスタイル（フォーマット、セミコロン）
   • refactor：バグ修正でも機能追加でもないコード変更
   • perf：パフォーマンス改善
   • test：テストの追加または変更
   • build：ビルドシステムまたは依存関係
   • ci：CI 設定
   • chore：保守作業

6. スコープを特定する

   • ファイルパスから（例：src/auth/ → auth）
   • 指定されていれば引数から
   • 任意：変更が複数の領域にまたがる場合は省略します

7. メッセージを生成する

   • 件名は72文字未満にします
   • 命令形を使います（「added」ではなく「add」）
   • タイプの後の最初の文字は大文字にしません
   • 件名の末尾にピリオドを付けません

フォーマット

<type>(<scope>): <subject>

<body>

<footer>

例

シンプルな機能追加：

feat(auth): add password reset functionality

本文付きのバグ修正：

fix(api): handle null response from payment gateway

The payment API can return null when the gateway times out.
Added null check and retry logic.

Fixes #123

破壊的変更：

feat(api)!: change response format for user endpoint

BREAKING CHANGE: user endpoint now returns nested profile object

動作

呼び出されると、次の処理を行います。

1. ステージされた変更を確認します

2. 差分の内容を分析します

3. オプションのアクティブな計画のコンテキストを解決し、利用可能な場合は ## Commit Plan によるグループ化を使用します

4. 読み取り専用のコンテキストゲートを実行し、結果を WARN／ERROR として要約します

5. コミットタイプが feat／fix／perf で、ロードマップが存在する場合は、マイルストーンとの関連付けを確認します。関連付けがない場合は警告し、コミット本文またはフッターへの追記を提案します

6. コミットメッセージを提案します

7. コミットする前に、ユーザーに確認します。

   AskUserQuestion: Proposed commit message:
   
   <type>(<scope>): <subject>
   
   Options:
   1. Commit as is
   2. Edit message
   3. Cancel
   

8. ユーザーの応答に応じて処理します。

   • そのままコミット → 手順9に進みます
   • メッセージを編集 → AskUserQuestion を使って修正後のメッセージをユーザーに確認し、新しいメッセージで手順7に戻ります
   • キャンセル → 停止し、コミットしません。ワークフローを終了します

9. 確認済みのメッセージで git commit を実行します

10. コミット後のプッシュ処理：

• 解決済みの設定で git.skip_push_after_commit = true の場合：

  • プッシュの確認を完全にスキップします
  • ローカルでのコミットが成功したらワークフローを終了します

• それ以外の場合（デフォルトの動作）は、プッシュするかどうかを確認します。

  • ブランチと先行状況を表示します：git status -sb
  • ブランチにアップストリームがない場合は、git push -u origin <branch> を使います
  • それ以外の場合は、git push を使います

  AskUserQuestion: リモートにプッシュしますか？
  
  Options:
  1. 今すぐプッシュ
  2. プッシュをスキップ
  

  • 今すぐプッシュ → アップストリームの状態に応じたプッシュコマンドを実行します。
    • ブランチにアップストリームがない場合 → git push -u origin <branch>
    • それ以外の場合 → git push
  • プッシュをスキップ → ワークフローを終了します

引数が指定された場合（例：/aif-commit auth）：

• 引数をスコープとして使います
• または、コミットメッセージのコンテキストとして使います

重要

• シークレットや認証情報を決してコミットしないでください
• 大規模な差分は、コミット前に慎重に確認してください
• /aif-commit には暗黙の strict mode はありません。ユーザーが明示的にブロック動作を要求しない限り、コンテキストゲートは警告を優先します
• このコマンドでは、解決されたアーキテクチャ、ロードマップ、RULES.md、説明、計画のアーティファクトを読み取り専用のコンテキストとして扱ってください
• 有効な計画が解決されない場合、または有効な計画に ## Commit Plan がない場合は、現在のステージ済み差分の動作を変更しないでください。
• ステージ済みの変更に無関係な作業（例：機能追加とバグ修正、または独立したモジュールへの変更）が含まれている場合は、コミットを分割するよう提案してください：

  1. どのファイル／ハンクがどのコミットに属するかを示す

  2. 分割計画をユーザーに確認する：

     AskUserQuestion: Split into separate commits?
     
     Options:
     1. Yes, split as suggested
     2. No, commit everything together
     3. Let me adjust the grouping
     

  3. ユーザーの回答に対応する：

     • Yes, split as suggested → ステップ 4 に進む
     • No, commit everything together → ステップ 5 に進む（単一のコミットメッセージを提案する）
     • Let me adjust the grouping → AskUserQuestion でユーザーにグループ分けの調整を求め、新しい計画でステップ 2 に戻る

  4. ステージングを変更する前に、計画された各グループのファイルセットが互いに重複していないか、複数のグループにまたがるファイルがないか、グループ分けされたファイルが git diff --name-only の未ステージ作業ツリーのパスと重複していないかを確認する。

  5. すべてのグループのファイルセットが互いに重複せず、グループ分けされたファイルが git diff --name-only に含まれていない場合は、git reset HEAD ですべての変更をステージング解除し、その後、各グループを git add <files> + git commit で個別にステージングしてコミットする。

  6. グループ分けされたファイルが未ステージの作業ツリーパスと重複する場合は、ステージングを解除する前に各グループの元のキャッシュ済みパッチを保持し、git apply --cached でそのパッチだけを再適用してください。それ以外の場合は、ハンク単位でステージングするか、ステージングを変更する前に中止してください。

  7. 1 つのファイルが複数のグループにまたがる場合は、各グループについてハンク単位でステージングしてください。git add -p または git apply --cached でそのグループのハンクだけをステージングしてコミットし、次のグループについて繰り返します。

  8. ハンク単位のステージングまたはキャッシュ済みパッチの適用を確実に行えない場合は、ステージングを変更する前に中止し、グループ分けを調整するか、すべてをまとめてコミットするようユーザーに依頼してください。

  9. すべてのコミットが完了した後にのみ、プッシュを提案する

• AI に著者資格を帰属させる Co-Authored-By やその他のトレーラーを決して追加しないでください。コミットに AI の共同著者行を含めてはいけません