メニュー
Gitコミットを適切な粒度に分割し、有用なメッセージを付けて作成するスキル。「コミットして」「commitして」「変更をコミット」「まとめてコミット」など、コミット操作を依頼されたら必ず使う。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
指定したスキルを3回繰り返し適用します。レビュー・計画・実装など、ファイルを変更するスキルに使います。「iterateで<スキル名>して」「<スキル名>を繰り返し適用して」のように使います。
既存テストをレビューして改善するスキル。「テストをレビューして」「テストを改善して」「テスト名を直して」のように頼まれたら使う。新規にテストを書くのではなく、`.claude/docs/test-implementation.md` のルール（テスト名・AAA構造・アサーション設計・テストダブル・非決定性制御・テスト間独立性・Testing Library 等のフロントエンド固有ルールまで全観点）に既存テストが沿っているかを見直す。対象は `.test.ts` / `.test.tsx` / `.spec.ts` ファイルと、テストコードブロックを含む `.md` ドキュメントファイル。
作った成果物について、ユーザーがその振る舞いと目的を確実に理解できているかを問いかけで確認します。細かな実装ではなく、何をするものか・目的にかなうかに焦点を当て、あらゆる可能性を踏まえてエージェントが判断して問いを立てます。「理解できているか確認して」「振る舞いを確認して」「目的にかなっているか見て」「作ったあとのすり合わせをして」と要望された際に必ず使用します。実装や変更が一段落したとき、作ったものの理解をすり合わせたいと感じたら積極的に提案してください。
`/compact`で要約する前に、残したい情報をユーザーに選んでもらい`/compact`の引数を組み立てます。 「compact前に整理したい」「コンテキストを圧縮したい」「/compactの引数を作って」 「会話が長くなってきたので整理したい」「重要な情報を引き継ぎたい」のように使います。
マージ済みのローカル・リモートブランチを整理するスキル。「ブランチ掃除」「マージ済みブランチを削除」「ブランチ整理」「gh poiを実行」「不要なブランチを片付けて」「リモートのブランチも消したい」「mainだけ残して」のような依頼で必ず使う。gh-poi拡張がインストール済みであることを前提とする。mainなどベースブランチは絶対に削除しない。
大きな計画や実装タスクを、依存関係順に並んだ最小単位のステップに分解します。各ステップは単独でレビュー・コミットできる粒度にします。「分解して」「ステップに割って」「細かく割り当てたい」「着手前に整理したい」「段階的に進めたい」「タスクを整理して」と要望された際に使用します。
SOC 職業分類に基づく
| name | x-commit |
| description | Gitコミットを適切な粒度に分割し、有用なメッセージを付けて作成するスキル。「コミットして」「commitして」「変更をコミット」「まとめてコミット」など、コミット操作を依頼されたら必ず使う。 |
| allowed-tools | ["Bash","TaskCreate","TaskUpdate","TaskList"] |
Gitコミットを論理単位の粒度で「人とAIに有用なメッセージ」を付けて作成するスキルです。履歴を読む人（自分・他人・AI）にとって価値のある情報だけを残します。
メッセージ作成（現状把握・規約確定・「なぜ」収集・計画提案）はcommit-message-writerサブエージェントに委譲し、このスキルは承認受領と実行（副作用）だけを担当します。
フローを開始する前に、全ステップをTaskCreateで登録します。各ステップを開始するときTaskUpdateでin_progressへ、完了したときcompletedへ更新します。
| # | subject | blockedBy |
|---|---|---|
| 1 | Step 1: commit-message-writerでコミット計画を作成する | — |
| 2 | Step 2: 計画を提示して承認を得る | 1 |
| 3 | Step 3: 承認後、計画通りに実行する | 2 |
Task toolでcommit-message-writerサブエージェントを起動し、「コミット計画を作成してください」と伝えます。ユーザーの元の依頼に追加の文脈（特定のscope指定・分割方針・関連issue番号など）があれば、その部分を添えます。
返却物は、対象ファイルとメッセージ全文を含む構造化されたコミット計画です。
サブエージェントから返ってきた計画をそのままユーザーへ提示し、末尾に以下の確認文を付けます。
この計画でコミットしてよいですか？修正点があれば指示してください。
ユーザーから修正指示があれば、サブエージェントへ再依頼します。
承認を得たら、全コミットを一括実行します。途中でコミットごとに確認は取りません。各コミットの手順は以下の通りです。
git reset（ワーキングツリーには影響しないunstageのみ）で既存のステージング状態を一度クリアし、git add -A -- <files>で計画通りのファイルだけをステージングします
-Aを使うのはgit mvによるリネームが含まれる場合でも削除側を取りこぼさないためですgit commit -m "..."またはgit commit -F <tmpfile>で実行します完了後はgit log -n <作成したコミット数> --onelineの結果を提示します。エラーで中断した場合は、完了済み・失敗・未着手を区別して報告します。
| 状況 | 対応 |
|---|---|
| pre-commit hookによる自動修正 | 変更をgit addで再ステージし、再コミットします。確認は不要です |
| commitlint違反 | エラー出力を読んでメッセージを修正し、1回だけ再試行します。2回目も失敗したらエラー内容とメッセージ案をユーザーに伝え、判断を仰ぎます |
| その他のエラー（hook失敗、テスト失敗など） | 止まります。状況を報告してユーザーの判断を仰ぎます |
--no-verifyを付けてhookをスキップしませんgit pushしませんgit commit --amend / git rebaseで履歴を書き換えません