commitkit

commitkit

現在の変更を、差分そのものから推測した Conventional Commits メッセージを付けて、1つ以上の整理されたコミットにまとめます。メッセージには、推測ではなく実際の変更内容を、適切なタイプとスコープを用いて命令形で記述します。コーディングセッションでは、デフォルトは複数のコミットです。機能グループまたは論理的に関連する変更ごとに1つのコミットを作成し、すべてをまとめた単一のコミットにはしません。

どのようなときに実行するか

ユーザーがコミットを依頼したとき（「これをコミットして」「コミットを作成して」「/commitkit」「変更をコミットして」）。メッセージだけを求める依頼（「コミットメッセージを考えて」「どんなメッセージにすればよいか」）の場合は、メッセージのみの手順に従います。この手順では、ステージング、コミット、プッシュは行いません。プッシュせずにコミットしたい場合は、「プッシュなし」（「コミットだけして、プッシュはしないで」）と指定します。各グループをコミットするを参照してください。

このスキルは、ユーザーが「コミットして」とだけ伝えて作業を引き継ぐ AI コーディングセッション向けに作られています。その場合は自律的に作業することが期待されています。自分でこのセッションのファイルをステージングし、適切な数のコミットに作業をグループ化してコミットし、プッシュしたうえで、各手順で確認を求めることなく、作成した内容を表にして報告します。

対象範囲

実行対象はこのセッションでの変更であり、ツリー内のすべての変更ではありません。1つのブランチやワークツリーに、別のエージェントや別のセッションが作成した複数の修正が含まれていることもよくあります。その場合、その作業には手を加えず、実行前と同じ状態に保ちます。グループ分けを行う前に対象範囲を確定し、最初に該当するルールを適用します。

1. all（/commitkit all、「すべてコミットして」「すべての変更をコミットして」）。対象範囲はツリー内のすべての変更です。
2. 名前で指定された範囲（「認証の修正をコミットして」、パスの一覧）。対象範囲は指定に一致する変更です。
3. セッションの変更一式。 対象範囲は、このセッション中にいずれかのツールで作成、編集、削除、または名前変更したすべてのパスです。作業の一環として実行したコマンドが変更したファイルも含みます。たとえば、依存関係のインストールによるロックファイルや、コードジェネレーターの出力が該当します。
4. セッションの変更一式がない場合。 セッションが新しい場合や、作業の文脈が失われている場合です。そこで停止し、変更されたパスを列挙して、どれをコミットするかユーザーに尋ねます。すべてを対象にする方法として /commitkit all を案内します。

対象範囲外のパスには手を加えません。 それらのパスを対象範囲外リストとして記録します。ステージング、コミット、復元、破棄は一切行いません。別のセッションでステージングされたパスは、作業を複数のコミットにグループ化するのステージング維持セットを使って、ステージングされたままにします。

別のセッションが同じファイルを編集した場合、セッションの対象パスにも自分が書いていないハンクが含まれていることがあります。ファイルの変更量が自分の変更量より多い場合、または別のセッションがそのファイルを編集しているとわかっている場合は、差分を確認してください。各グループをコミットするで混在ファイルを扱う方法と同様に、パッチとしてステージングし、自分のハンクだけをコミットします。ハンクが重なって分割できない場合は、作業を止めてユーザーに確認します。

メッセージのみのルート

ライブセッション中のユーザーが求めているのは、コミットではなくメッセージです。このルートでは読み取りと表示だけを行います。インデックス、参照、リモートには一切変更を加えません。

1. 1 回の呼び出しで開始時の状態を記録します：git status --short && git rev-parse HEAD && git diff --cached --binary | git hash-object --stdin && git for-each-ref | git hash-object --stdin。-w を付けない hash-object は何も書き込みません。
2. 対象を選びます。ステージ済みの変更がある場合は、それが対象なので git diff --cached を読みます。ステージ済みの変更がない場合は、スコープ が対象なので、git diff HEAD -- <scope paths>、または all の場合はパスを指定しない git diff HEAD を読みます。状態を読み取る の読み取り制限が適用されます。
3. 差分からタイプとスコープを決める と メッセージを書く を適用します。対象に対してメッセージを 1 つ書きます。対象が明らかに複数の関心事にまたがる場合は、グループごとにメッセージを 1 つ書き、各グループのパスを示します。
4. 各メッセージをコードブロックで表示します。

このルートで実行できる Git コマンドは読み取り専用です：status、diff、log、rev-parse、for-each-ref、および -w を付けない hash-object。

完了条件：すべてのメッセージを表示し、記録コマンドを最後に実行して、開始時と同じコミットと 2 つのハッシュが出力されること。引き継ぎは 1 行で行います。何も変更されていないことを伝え、次の手順として、これらのメッセージを使ってコミットするには「commit」と入力するよう案内します。

下書きモード

開始条件：両方を満たす必要があります。呼び出し元が下書きモードを指定しており、ステージ済みの差分がプロンプト内の <staged-diff> タグに含まれていて、使用できるツールがないこと。このモードは、lazygit のカスタムコマンドなどの Git ツールによって実行されます。ツールはこのファイルをインラインで挿入し、差分と追加のコンテキストを付け加え、あなたの標準出力を取得して、そのテキストをコミットパネルに直接書き込みます。コミットメッセージ以外の言葉を出力すると、コミットが壊れます。

下書きモードでは、スコープ、状態を読み取る、作業を複数のコミットに分ける、各グループをコミットする、引き継ぐ は適用されません。差分からタイプとスコープを決める と メッセージを書く はそのまま適用されるため、スコープは引き続き必須で、本文も必要です。

• ステージ済みの変更全体に対して、コミットメッセージを正確に 1 つ書きます。 ステージングの管理は呼び出し元が行い、ステージし直すことはできないため、複数コミットを既定とするルールはここでは適用されません。
• メッセージだけをそのまま出力します：件名、空行 1 行、続けて本文です。前置き、コードフェンス、要約表、引き継ぎ、次の手順、Co-authored-by、ツールの宣伝は不要です。出力の最初の文字は件名の最初の文字にしてください。
• リポジトリのコンテキストを把握するため、ペイロード全体を読みます。 git log --oneline の出力が含まれている場合があります。注記 のリポジトリ慣例のルールに従って、その件名のスタイルに合わせます。
• [diff truncated] マーカーが含まれていることがあります。 表示されている差分からメッセージを書きます。コミットには切り詰めを含めません。
• 差分がなければ、何も出力しません。 ペイロードに差分が含まれていない場合は、何も表示せずに終了します。

下書きモードでは、注記 のコードブロックへのフォールバックよりも下書きモードのルールが優先されます。コードフェンスは、メッセージを手作業でコピーする人のためのものです。コミットパネルには、メッセージだけをそのまま入力します。

手順

1. 状態を確認する

単一の呼び出しで、完全な差分ではなく、まずファイル単位で変更の形を確認します。

git status --short && git diff --stat HEAD && git diff --cached --no-renames --name-only   # tree state, one line per file, the staged set

ステージ済みのファイル一覧を記録します。 最後のコマンドには、作業を始める前にステージされていたすべてのパスが表示されます。この一覧は作業全体を通じて保持してください。git add はインデックスに追加するだけなので、以前にステージされたパスは、意図して除外しない限り次のコミットにも含まれます。git status --short で MM と表示されるパスは一部のみステージ済みです。ユーザーが一部のハンクをステージし、残りはステージしていないため、グループに含めるのはステージ済みのハンクです。ユーザーから指示がない限り、そのパス全体を再追加してはいけません。

このスキル内の Git 呼び出しは、すべて同じようにまとめます。 このスキルはセッションの最後に実行され、コンテキストウィンドウが最大になっているため、Bash 呼び出しを1回追加するたびに、そのウィンドウ全体を入力として再び支払うことになります。コマンドの間に判断が必要ない場合は && でつなぎ、2つのコマンドの間で立ち止まって考える必要があるときだけ、別の呼び出しを使います。

次に、変更を書いたのは誰かを考え、実際に必要な差分の量を決めます。

• 同じコンテキスト内であなたが変更した場合（一般的なコーディングセッションからの引き継ぎ）。変更の内容だけでなく、さらに重要な「なぜ」もすでに把握しています。「なぜ」は差分からはわかりません。却下した方法、途中でバグを見つけたテスト、意図的に変更しなかったファイルなどが該当します。stat の情報をもとにグループ分けし、把握している内容を本文に書きます。自分で触っていないファイルや、何が反映されたか本当に思い出せない場合に限り、差分を読みます。
• 自分が変更していない場合。対象範囲が all、または自分の変更を超える名前付きの範囲である場合、サブエージェントとして割り当てられた場合、あるいは作業がかなり前でコンテキストに残っていない場合です。この場合、情報源は差分だけですが、すべてを一度に読むのではなく、グループごとに確認します。まず stat からグループを大まかに分け、その後 git diff HEAD -- <paths> で各グループの差分を読み、グループの種類、範囲、影響が明らかになった時点で止めます。パスを指定しない git diff HEAD は、セッション全体の変更を一度にコンテキストへ取り込みます。グループごとに確認すれば、読み取る内容を実際に記述するグループに限定できます。

迷ったら読みましょう。曖昧なコミットメッセージは、節約したトークンよりも大きな損失になります。一方、数分前に自分が書いたコードを読み直しても意味はありません。stat を見れば変更されたファイルがわかり、何をしたかも把握しているはずです。

どちらの場合も、生成されたファイルの内容は決して読まないでください。ロックファイル（*.lock、package-lock.json、pnpm-lock.yaml、go.sum）、ビルド出力、ベンダーディレクトリ、スナップショット、コンパイル済みアセットが該当します。stat の行だけでコミットメッセージに必要な情報は十分に得られます。ほとんどのリポジトリでは、こうしたファイルの差分が最も大きくなります。

• ユーザーがコミットを委任した場合（一般的なコーディングセッションでの「commit」／「my changes をコミットして」など）、必要なファイルを自分でステージできます。論理グループごとに、そのグループをコミットする際にパスを git add してください。事前に確認を求める必要はありません。グループ分けとステージングはあなたの役目です。
• 意図が本当に曖昧な場合に限り、いったん立ち止まって質問します。たとえば、作業途中の変更、シークレット、ユーザーがコミットするつもりではないと思われる変更がツリーにある場合や、ファイルが一部のみステージ済みで、パス全体をステージすると意図的に未ステージにされているハンクまで含まれる場合です。無関係な変更をまとめて git add -A してはいけません。グループごとにステージしてください（作業を複数のコミットに分けるを参照）。
• ユーザーが特定のコミットを1つだけ依頼した場合は、その指示に従い、自動的に分割しないでください。
• 対象範囲に変更がない場合は、そこで停止してその旨を伝えます。ツリーに範囲外の変更がある場合は、それらの名前を挙げてください。

完了条件：パスの一覧を含む確定済みの対象範囲、変更されたパスの一覧、一部のみステージ済みのパスを明記したステージ済みファイル一覧の記録、そして変更を書いたのが誰かについての回答がそろっていること。

2. 差分からタイプとスコープを決める

変更するファイルではなく、差分が何をするかに基づいて type を選びます。

type	使用する場合
feat	ユーザーが利用できる新機能
fix	バグ修正
hotfix	ベースブランチに直接適用する緊急の修正
docs	ドキュメントのみの変更
refactor	動作を変えないコード変更
perf	パフォーマンスの改善
test	テストの追加または修正
build / ci	ビルドシステム、依存関係、パイプライン
style	ロジックに影響しない書式や空白の変更
chore	上記のいずれにも該当しない日常的な保守作業

hotfix は急ぎの fix であり、重大度ではなくブランチによって決まります。 ベースブランチから切り出して直接修正を適用する、hotfix-<slug> という名前のブランチ上にコミットがある場合に hotfix を使います。それ以外は、どれほど緊急に感じられても fix のままにします。こうすることで、バグの深刻さに関する判断ではなく、ブランチ名からタイプを確認できます。hotfix は Conventional Commits のタイプ一覧への追加なので、リポジトリのツールが標準の一覧に対してタイプを検証する場合は、fix に戻し、その旨を一度だけ伝えてください。

スコープは必須です。 標準の Conventional Commits とは異なり、スコープを省略してはいけません。差分が属するモジュールや機能グループ（パッケージ、モジュール、ディレクトリ、機能領域）を特定し、それをスコープとして使います。例：feat(auth): …。変更が本当に全体に関わる場合や、単一の領域に当てはまらない場合（リポジトリ全体の設定、ツール、横断的な整理）は、スコープに repo を使います。例：chore(repo): …。既存の動作を壊す変更には、!（または BREAKING CHANGE: フッター）を追加します。

完了条件：予定した各コミットに、タイプとスコープがそれぞれ1つだけ設定されていること。

3. メッセージを書く

形式：

type(scope): short imperative summary

one-line summary of why the change was made

- reason/change bullet
- reason/change bullet

Reference issues in a footer.

(scope) は必須です。すべてのメッセージにスコープを含め、全体に関わる変更では (repo) を使います。

ルール：

• 件名は命令形で、すべて小文字にします。固有名詞と頭字語を除き、タイトル内の最初の単語も含め、どの単語も大文字で始めないでください。末尾にピリオドを付けず、50文字以内を目安にします。
• 要約には変更の効果（「fetch クライアントにリトライを追加する」）を書き、作業内容（「fetch クライアントを変更する」）は書きません。
• 本文の各行は72文字以内にします。長い箇条書きは2つに分けるか、インデントした次の行に続けてください。commitlint の body-max-line-length などのコミットフックは長い行を拒否します。72文字以内であれば、一般的な72／80／100文字の制限を満たせます。
• 本文は必須です。 冒頭に「なぜ」を簡潔に示す1行の要約を書き、その後に理由と具体的な変更を箇条書きで記載します。レビュー担当者に必要な内容に絞ってください。些細なコミットに内容を水増しする必要はありませんが、要約の1行と箇条書き1つ以上は必ず含めます。
• ユーザーから求められない限り、Co-authored-by やツールの宣伝を追加しないでください。

完了条件：すべてのメッセージに、スコープ付きの小文字の命令形の件名、「なぜ」を示す1行、箇条書きが1つ以上含まれ、本文の各行が72文字以内であること。

4. 作業を複数のコミットにまとめる

何かをコミットする前に、変更を論理的なグループに分けてください。各機能グループまたは関連する作業単位（機能とそのテスト、バグ修正、ドキュメント更新、リファクタリング、設定の更新）は、それぞれ独自のコミットにします。これは例外ではなく、基本方針です。3つの事項に手を加えたセッションでは、それぞれ独自の範囲を持つ3つのコミットを作成します。

ファイルの種類やディレクトリではなく、変更によって実現することを基準にグループ分けしてください。機能と、それに属するテストやドキュメントは、別々のコミットに分けず、一緒にまとめます。細分化しすぎないようにしてください。複数のファイルにまたがっていても、まとまりのある変更なら1つのコミットにします。

依存関係の順にグループを並べ、依存されるものを先に反映してください（例：機能が使用する共通ヘルパーを先に反映する）。1つのファイルに複数のグループの変更箇所がある場合は、そのファイル全体を1つのグループに割り当てず、対話的にステージするよう計画してください。

記録されたステージ済みセットのすべてのパスを割り当ててください。 事前にステージされているパスが範囲内にある場合は、該当するグループに含めます。範囲外の事前にステージされているパスは、どのグループにも含めず、実行後もステージ済みのままにします。それらのパスをステージ済み維持セットとして列挙してください。

完了条件： 範囲内の変更済みパスがすべて、ちょうど1つのグループまたは明記されたスキップリストに含まれ、範囲外のパスがすべて範囲外リストに含まれ、記録されたステージ済みパスがすべてグループまたはステージ済み維持セットに含まれていること。

5. 各グループをコミットする

各グループとコミットメッセージをすべて計画したら、1回の Bash 呼び出しで && をつないで、すべてステージしてコミットしてください。最後にプッシュと、引き継ぎに必要な git status -sb をつないでください。各コミットの前に、ステージ済みセットがそのグループのパスだけで構成されていることを確認し、別のグループに属するパスがコミットに含まれないようにしてください。

git add -- <group 1 paths> && \
test "$(git diff --cached --no-renames --name-only | sort)" = "$(printf '%s\n' <group 1 paths> | sort)" && \
git commit -m "type(scope): summary" -m "why in one line

- reason/change bullet
- reason/change bullet" && \
git add -- <group 2 paths> && \
test "$(git diff --cached --no-renames --name-only | sort)" = "$(printf '%s\n' <group 2 paths> | sort)" && \
git commit -m "type(scope): summary" -m "why in one line

- reason/change bullet" && \
git push -u origin HEAD && git status -sb && \
gh pr view --json number,url,state 2>/dev/null || true

各 git add、git diff、git restore、printf の呼び出しでは、すべてのパスをそのまま記述してください。g2="a b c" のように、パスの一覧をシェル変数に格納してはいけません。デフォルトの macOS シェルである zsh は、引用符で囲まれていない変数を単語に分割しないため、git add -- $g2 は a b c という名前の1つのパスとして扱われ、失敗します。空白を含むパスは引用符で囲んでください。

最後のコミットの後に && でプッシュをつなぎます。 いずれかのグループで add、確認、またはコミットに失敗すると、チェーンが停止し、部分的な変更は公開されません。以下の退避パターンにある ; だけが例外です。退避したグループではプッシュを行わず、すべてのコミットが反映された後に、別の呼び出しでプッシュしてください。

部分的にステージされたパスは git add の対象から外し、確認リストには残してください。これにより、そのグループではステージ済みの変更箇所だけが対象になります。リネームでは、--no-renames によって旧パスと新パスの両方が表示されるため、グループには両方のパスを記載してください。

現在のグループに属さないステージ済みパスは退避してください。 記録されたステージ済みセットに、現在のグループ以外のパス（ステージ済み維持パスまたは後のグループのパス）が含まれている場合、インデックスから取り除くまで確認は失敗します。パッチとして退避し、グループをコミットしてから、元に戻してください。

park="$(git rev-parse --git-path commitkit-park.patch)"
git diff --cached --binary --no-renames -- <other staged paths> > "$park" && \
git restore --staged -- <other staged paths> && \
git add -- <group paths> && \
test "$(git diff --cached --no-renames --name-only | sort)" = "$(printf '%s\n' <group paths> | sort)" && \
git commit -m "type(scope): summary" -m "…"; \
git apply --cached "$park"

パッチにはステージ済みの変更箇所がそのまま保持されるため、部分的にステージされたファイルは部分的にステージされた状態で戻り、新規ファイルや削除済みファイルもステージ済みの状態で戻ります。git commit -- <paths> のほうが短く書けますが、各パスの作業ツリー上のコピーをコミットするため、部分的にステージされたファイルの未ステージの変更箇所までコミットに取り込まれてしまいます。確認やコミットに失敗した場合でも退避したパスを復元できるよう、git apply の前の ; はそのままにしてください。; を使うとコミットに失敗してもチェーンが続くため、退避するグループはそれぞれ別の呼び出しで実行し、そのコミットが反映されてから次のグループを開始してください。git apply --cached が失敗した場合は、退避した変更箇所がそのファイルに含まれているため、停止してパッチのパスを報告してください。

最後の gh pr view によって、このブランチにすでにプルリクエストがあるかどうかを引き継ぎ時に確認できます。同じ呼び出しで実行できるため、追加のコストはかかりません。結果が空の場合や gh が失敗した場合はプルリクエストがないことを意味しますが、これは通常の結果であり、エラーではありません。 プッシュが origin への通常のファストフォワードである場合は、デフォルトでプッシュします。 このマシンにしかないコミットは、ディスクが故障すれば失われてしまいます。公開することは、ユーザーがほとんどの場合に行う操作です。リポジトリに origin リモートがあり、ブランチが origin を追跡しているか、上流ブランチが設定されていない場合はプッシュします。ブランチ名は条件になりません。トピックブランチもベースブランチも同じようにプッシュします。個人用リポジトリではベースブランチに直接コミットすることが多く、そこで毎回確認を求めることになるためです。

次の場合はプッシュを保留し、確認してください。

• リモートに拒否された場合。 拒否されたことを報告して停止します。ここで --force や --force-with-lease を使ってはいけません。プッシュが拒否されたということは、リモートでブランチが進んだということです。その書き換えは commitkit ではなく、gitkit と prkit の担当です。
• origin がない場合、またはブランチが別のリモートを追跡している場合。コミットを報告し、ユーザーが実行するプッシュコマンドを示します。

ユーザーまたは呼び出し元のスキルが no-push（「コミットのみ。プッシュしない」「コミットする。プッシュはしない」「まだ公開しない」）を指定した場合は、プッシュをスキップします。チェーンから git push -u origin HEAD を除き、git status -sb は実行して、コミットはローカルにあると伝えます。no-push を渡す呼び出し元のスキルがプッシュを担当します。たとえば afkkit は、prkit が PR を作成するときに一度だけブランチを公開します。

複数のファイルが混在するファイルを対話的にステージングする手順（作業を複数のコミットに分割するを参照）だけは、チェーンに含められません。そのグループまでを一度の呼び出しでコミットし、分割を処理してから、残りをチェーンで実行します。

ユーザーがコミットを委任した場合（「コミットして」「変更をコミットして」）、グループごとの確認を求めず、すべてのグループについてこの手順を実行します。メッセージだけを求めるリクエストでは、この手順には進まず、メッセージのみのルートで終了します。コミットが失敗した場合（たとえば、pre-commit フックに拒否された場合）、&& チェーンは失敗したグループで停止し、それ以降のグループはコミットされません。フックの出力を提示し、修正するか確認を求めてから、そのグループからチェーンを再開します。指示がない限り、やみくもに再試行したり、--no-verify でフックを回避したりしないでください。

完了条件： git log --stat に表示される各コミットのファイル一覧がそのグループのパスと一致していること、実行後にステージング状態で残るファイルがステージング維持対象と一致していること、対象外のすべてのパスで git status --short の行が開始時と同じであること、そしてプッシュが実行済みか、保留する理由が記録されていること。

6. 引き渡し

このセクションは手順を示す文体で書きます。各文で指示を1つだけ示し、能動態と現在形を使い、比喩は使いません。

変更点、コミット先、次の作業を最後に示します。

変更点。 作成したコミットの概要表を出力し、結果をひと目で確認できるようにします。

#	コミットメッセージ	ファイル
1	feat(auth): add token refresh retry	auth/token.ts、auth/token.test.ts
2	chore(repo): bump ci node version	.github/workflows/ci.yml

各コミットで変更・作成したファイルを、最後の列に記載します。各グループで git add に渡したパスはすでに把握しているため、それを基に表を作成し、再度 git を照会しないでください。確認が必要な場合は、直前に作成したすべてのコミットを確認できる git log --stat --oneline -<n> を1回実行してください。コミットごとに個別の git show を実行しないでください。1つのコミットで多数のファイルに変更を加えた場合は、主なファイルを記載し、「ほかにN件」と追加してください。コミットされていない変更（意図的に見送った変更、ユーザーに残した変更、意図的にステージングしたままの変更）があれば、表の下に記載してください。対象外のパスは1行で示し、この実行で次回のセッションまたは /commitkit all に残した変更がどれか分かるようにしてください。

コミット先。 コミットが存在するブランチを報告し、プッシュしたかどうかを伝えます。コミット処理の最後に実行した git status -sb は、ブランチと追跡先を1行で出力します。再実行せず、その出力を基に報告してください。プッシュしていない場合は、その旨と理由を示してください。このマシンにしか存在しないコミットは、報告の中でも特に重要です。

次の作業。 次の作業を1つだけ示して終えます。すでに確認した状態を基に、次の順序で選んでください。

1. 呼び出し元のスキルが no-push を指定した場合。 コミットを報告し、呼び出し元に戻ります。呼び出し元が次の作業を決めるため、次の作業は提示しません。
2. プッシュしていない場合。 プッシュを次の作業として示し、コマンドを記載します。
3. ブランチにすでにオープン中のプルリクエストがある場合（末尾に出力された gh pr view の結果に表示されています）。コミットはすでにそのプルリクエストに含まれているため、新しいプルリクエストの作成ではなく、レビューを次の作業として示します。プルリクエストが更新されたこと、番号、URLを伝え、コミットした理由に合った作業を示します。レビューで修正が必要になった場合は、mergekit でレビュアーに返信し、レビューを再依頼します。それ以外の場合は gh pr comment <number> を使います。プルリクエストがあるブランチで、新たなプルリクエストの作成を次の作業として示さないでください。
4. プルリクエストがマージ済みまたはクローズ済みの場合。 その旨を伝え、gitkit でこの作業用の新しいブランチを作成することを次の作業として示します。それ以外の場合は git switch -c <name> <base> を使います。
5. ブランチにプルリクエストがない場合。 今回のコミットのみを含むプルリクエストの作成を次の作業として示します。prkit がインストールされている場合は prkit、そうでない場合は gh pr create を使います。
6. 機能が明らかに未完成の場合。 その旨を伝え、作業を続けることを次の作業として示します。その後、次のグループに対して commitkit を再実行します。

自分でプルリクエストを作成しないでください。commitkit の役割はプッシュまでです。

完了条件：表にすべてのコミットが記載され、ブランチの行にプッシュしたかどうかが示され、次の作業がちょうど1つだけ示されているか、呼び出し元のスキルに処理が戻されていること。

メモ

• ユーザーが明示的に求めない限り、git commit --amend、git rebase、git reset、その他の履歴を書き換えるコマンドを絶対に実行しないでください。早送りプッシュで公開した作業は revert で復元できますが、公開済みブランチの履歴を書き換えることはできません。そのため、このガードはプッシュではなく「各グループをコミットする」（#5）にあります。
• リポジトリ独自のコミット規約（CONTRIBUTING.md、コミットテンプレート、または git log で明らかに異なるスタイル）がある場合は、ここに記載した既定値よりもそちらを優先し、その旨を伝えてください。
• ファイルシステムやシェルを使えない場合は、git を実行できません。その場合は、ユーザーが提示した差分を読み、実行してもらうための完成したコミットメッセージをコードブロックで出力してください。