git-commit-organizer

Git コミットオーガナイザー

雑然とした作業ツリーを、整理されて読みやすい履歴に変えます。良いコミット履歴は、後から関わるすべての人にとって便利なツールです。それぞれ単独で意味が通るアトミックなコミットなら、レビュー、取り消し、チェリーピックが簡単になります。このスキルはまさにそれを実現します。しかも、あなたに無断でコミットやプッシュをすることはありません。必ず事前にあなたの承認を得ます。

指定できる項目（すべて任意）

自然言語での指定は、どの言語でも認識します。特定の単語ではなく、意図に基づいて処理します。

オプション	デフォルト	指定例
gitmoji	オフ	「gitmoji を付けて」「絵文字を追加して」
issue	ブランチから自動検出	「#412」「issue 412 用」「issue なし」
exclude	なし	「docs フォルダーを除外して」「vendor/ をスキップして」

ワークフロー

1. 実際の変更内容を確認する

git status
git diff --stat
git diff --cached --stat

次に、該当するファイルの実際の差分を読みます（git diff <file> と git diff --cached <file>）。ファイル名だけでは、変更が機能追加なのか、修正なのか、リファクタリングなのかは分かりません。差分を確認する必要があります。変更を意図ごとにまとめるため、その意図を把握する必要があります。

2. issue の参照を検出する（任意）

最初に git branch --show-current を実行します。以前の会話で使われたブランチを決めつけないでください。ユーザーがブランチを切り替えている可能性があります。ブランチ名に識別子が明らかに含まれている場合（よくある形式：feature/412、412-add-search、fix/PROJ-42）、#412／PROJ-42 を含めることを提案します。issue を付けるのは、ユーザーが指定した場合、またはブランチ名から明らかに分かる場合だけです。issue 番号を捏造してはいけません。ユーザーが指定した番号を見つけられない場合は、確認してください。

3. 除外を適用する

デフォルトでは、Git がすでに認識しているすべての変更（追跡対象の変更と新規ファイル）をコミットします。無視する対象の判断基準は .gitignore です。ユーザーが要求した場合に限りパスをスキップし、そのファイルは削除したり触れたりせず、ステージングしないでください。

4. 変更をアトミックなコミットにまとめる

1 つのコミットにつき、論理的な変更は 1 つにします。各コミットが単独で成立し、ビルドを壊さない履歴を目指します。まとめ方の例：

• 変更と、それを対象とするテストは一緒にまとめます。
• 関連のないバグ修正と新機能は、別々のコミットにします。
• 設定、ビルド、依存関係の変更は、自然にまとまります。
• 純粋なフォーマット変更（空白、インポート順）は、動作を変更するコミットに含めません。
• 大規模な名前変更や移動は、通常、編集とは別の独立したコミットにします。

すべてが本当に 1 つのまとまった変更であれば、単一のコミットが適切です。分割すること自体を目的に、細かく分けすぎないでください。複数のコミットを計画する場合、またはグループ分けに少しでも曖昧さがある場合は、何も実行する前に、提案するグループ分けを提示して確認を取ります。

5. 種類とスコープを選ぶ

種類	使用する場面
feat	新機能
fix	バグ修正
refactor	動作を変えない構造変更
perf	パフォーマンス改善
test	テストの追加または更新
docs	ドキュメントのみ
style	ロジックを変更しないフォーマット変更のみ
build	ビルドシステムまたは依存関係
ci	CI/CD 設定
chore	他の種類に当てはまらない保守作業
revert	以前のコミットの取り消し

スコープは任意です。変更対象の領域（機能、モジュール、ディレクトリなど）を、短く小文字で記します。

6. メッセージを書く

形式：type(scope): [#issue] short description

• ヘッダー — 命令形を使い（「added」ではなく「add」）、最初の単語は大文字で始め、末尾にピリオドを付けません。可能であれば約 72 文字以内に収めます。
• 本文（任意。ただし、差分から理由が明らかでない場合は記載します） — 空行の後に、変更内容と理由を説明する - の箇条書きを記します。「インポートを更新した」のような情報量のない記述は省きます。
• gitmoji（有効な場合のみ） — 次の対応表に従って、ヘッダーの先頭に付けます：feat ✨ · fix 🐛 · refactor ♻️ · perf ⚡ · test ✅ · docs 📝 · style 🎨 · build 📦 · ci 👷 · chore 🔧 · revert ⏪

7. 提案してから承認を待つ

コミットする前に必ず計画を提示し、明示的な承認を待ってください。 予定しているコミットごとに、コミットメッセージとステージする正確なファイルを提示します。予告なしのコミットは取り消しの手間がかかり、信頼を損なうため、この承認手順は決して省略しないでください。

8. ステージしてコミットする

そのグループのファイルだけをステージしてから、コミットします。複数行のメッセージにはヒアドキュメントを使い、本文の書式がそのまま保持されるようにしてください。

git add <specific files for this commit>
git commit -m "$(cat <<'EOF'
type(scope): #412 Short description

- What changed and why.
- Another meaningful detail.
EOF
)"

各コミットの後に git log -1 を表示し、ユーザーが結果を確認できるようにします。

9. 結果を確認する

すべてのコミットの後に git log --oneline -n <number of commits> を実行し、新しい履歴をひと目で確認できるようにします。

厳守事項

• プッシュしないでください。 プッシュするかどうかは、常にユーザーが決めます。いかなる場合も git push を実行しないでください。
• 明示的な承認なしにコミットしないでください（手順 7 を参照）。
• AI やツールに関する帰属情報を記載しないでください。 コミットはプロジェクトの人間の著者を表します。Co-authored-by、Signed-off-by などのトレーラー、フッター、または AI ツールに言及するテキストを追加しないでください。
• 英語で、命令形にし、単一の目的に絞ってください。

例

ここでのスコープ（search、parser、http、readme）は、意図的に汎用的なものにしています。実際にリポジトリで使われている領域名を使用してください。

例 1 — 単一の機能（ウェブアプリ）、選択肢なし

変更内容：検索コンポーネントとそのテスト。

feat(search): add fuzzy matching to the product search box

- Match results by approximate spelling so small typos still return hits.
- Cover the ranking edge cases with unit tests.

例 2 — 関連のない作業を 2 つのコミットに分ける（CLI ツール）

作業ツリーには、バグ修正と依存関係の更新があります。

fix(parser): stop crashing on an empty config file

- Treat a missing or empty config as the defaults instead of throwing.

chore(deps): upgrade the HTTP client to 4.2.0

例 3 — ブランチ 412-retry-logic から gitmoji と課題番号を自動検出（ライブラリ）

♻️ refactor(http): #412 extract retry handling into its own module

- Move the backoff logic out of the client so it can be unit-tested in isolation.

例 4 — ドキュメントのみ

docs(readme): document the new --watch flag

使用しない場合

• コードの作成や変更（それが作業の本体であり、このスキルはその後にコミットします）。
• マージコンフリクトの解決。
• プルリクエスト／マージリクエストの作成や説明。
• リモート操作全般。特にプッシュは、このスキルの役割ではありません。