# Smart Commit

> 現在の git 差分を作業内容ごとに適切な単位で分割し、日本語 conventional commits でコミットする。 必要に応じて作業ブランチへの切替・新規作成も提案する（副作用あり）。 「コミットして」「差分をコミット」「変更をまとめて」「作業区切りたい」「一旦コミット」 「今の状態を保存」「ここまでの変更を記録」等で起動する。 コードレビュー（smart-review）や PR 作成（smart-pr）とは別物。

- Skill: `mjcreativelab/smart-commit` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add mjcreativelab/smart-commit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mjcreativelab/smart-commit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: mjcreativelab (https://skillmd.com/u/mjcreativelab)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mjcreativelab/smart-commit

---


# Smart Commit

現在の git 差分（staged + unstaged + untracked）を分析し、作業内容ごとにまとまった単位でコミットを作成する。

## 引数の解析

`$ARGUMENTS` を以下のルールで解析する:

- `-p` がある場合 → `-p` より後の部分を `{プロンプト}` として保持する
- `-p` がない場合 → `{プロンプト}` は空
- `{プロンプト}` はコミット対象の選別やメッセージに関する追加指示として、ブランチ連動フィルタリング（Step 4）より優先される

例: `-p e2e の変更だけ` / `-p docs は後回し` / `-p WIP でまとめて`

## 手順

### 1. 早期終了チェック

変更がなければ「コミットする変更がありません」と報告して終了。

### 2. ブランチ確認

現在のブランチ・ブランチ一覧・変更ファイルを取得し、ブランチの適切性を判定する:

- **main/master にいる場合** → 作業ブランチへの切り替えを提案（stash → checkout → stash pop）。提案は次の 2 択を並べる:
  - 変更内容に合致する**既存ブランチ**が一覧にあれば流用案として提示（名前の一致度・目的の一致度で判定）
  - 合致する既存ブランチがないなら**新規作成案**を提示。Issue 番号が不明なときはユーザーに聞く
- **作業ブランチだが変更がブランチ目的と異なる場合** → 別ブランチへの切り替えを提案（同様に既存流用 / 新規作成の 2 択）
- **適切な場合** → 何も表示せず次へ

ただし `-p` でコミット対象が絞られている場合、対象外ファイルが working tree に残ることをもってブランチ切替提案を出してはならない（`-p` の明示指示はブランチ目的より優先する。Step 4 のフィルタリングと整合）。

切り替え・新規作成前に必ずユーザーに確認を取る。プロジェクト側に独自のブランチ命名規則（CLAUDE.md・AGENTS.md・README 等で明示されている場合）があればそちらを優先し、なければ以下の規則に従う。

**ブランチ命名規則**:

フォーマット: `{type}/issue-{番号}-{簡潔な説明}`

| prefix      | 用途                             |
| ----------- | -------------------------------- |
| `feature/`  | 新機能・機能追加                 |
| `fix/`      | バグ修正                         |
| `refactor/` | リファクタリング（機能変更なし） |
| `docs/`     | ドキュメントのみの変更           |
| `chore/`    | ビルド・CI・依存関係など雑務     |
| `test/`     | テストの追加・修正               |

ルール:
- **kebab-case**（小文字 + ハイフン区切り）を使う
- 日本語は使わない（ASCII 英数字 + ハイフン + スラッシュのみ）
- Issue に紐づく作業は必ず `issue-{番号}` を含める
- 説明部分は **英語・3〜5 語** 程度に収める
- マイルストーン分割がある場合は末尾に `-m{番号}` を付ける
- Issue に紐づかない繰り返し作業（chore/docs/refactor 等）は、末尾にタイムスタンプ `-YYYYMMDD` を付けて一意にする（例: `docs/update-readme-20260326`）

### 3. 差分の収集と分析

`git status`, `git diff`, `git diff --cached`, `git log --oneline -5` を **1 メッセージ内で複数の Bash 呼び出しに分けて並列実行** する。

差分が大きい場合（`git diff --stat` の総変更行数が 500 行を超えるのが目安）は、まず `git diff --stat` でファイル別の増減行数を取得し、変更が大きいファイルや判断に必要なファイルだけ `git diff <path>` で個別に確認する。全ファイルの全行をコンテキストに載せない。

### 4. フィルタリング + コミット単位の分割

**ブランチ連動フィルタリング**（main 以外の場合）:
- ブランチ名から目的を推定。Issue 番号があれば GitHub MCP の `issue_read` ツール（`mcp__plugin_github_github__issue_read` 等。`gh` CLI ではなく MCP に統一）で詳細確認し、タイトル・ラベル・本文冒頭のみ保持する（全フィールドをコンテキストに残さない）
- 目的に合致しない変更は除外（working tree に残す）。除外したファイルはコミット計画の提示で「別ブランチでの対応が望ましい」旨を明示するに留め、**勝手に新ブランチを作らない**
- `-p` の指示はブランチ連動より優先。`-p` で対象が絞られた結果、ブランチ目的外のファイルが working tree に残る場合でも Step 2 のブランチ切替提案は発生させない（`-p` の明示指示を尊重）

**コミット分割基準**:
- 機能単位でまとめる（レイヤー横断 OK）
- 設定・ドキュメントはコードと別コミット
- 同種の大量変更は1コミットにまとめる

### 5. ignore 確認

untracked に以下のいずれかが含まれていれば `.gitignore` 追加を提案する:

- 機密ファイル（`.env`, `.env.local`, `*.pem`, `*.key`, `id_rsa`, `secrets.*`, `credentials.*` 等）
- ビルド成果物（`dist/`, `build/`, `node_modules/`, `*.pyc`, `__pycache__/`, `target/`, `.next/`, `coverage/` 等）
- OS / エディタ生成ファイル（`.DS_Store`, `Thumbs.db`, `.idea/`, `.vscode/`（プロジェクト指定がない限り）等）

機密ファイルが既に staging に含まれている場合は強く警告し、ユーザー承認なしにはコミットしない。

### 6. コミット計画の提示

コミット単位ごとにメッセージとファイル一覧を表示。除外ファイルも明示。ユーザーの承認後に実行。

### 7. コミット実行

ファイル名を明示指定して `git add`（`git add .` は使わない）→ `git commit`。コミットメッセージは HEREDOC で渡す:

```bash
git commit -m "$(cat <<'EOF'
✨ feat(auth): ログイン機能を追加
EOF
)"
```

**pre-commit hook 失敗時**:
- 失敗原因（lint / format / type check 等）を修正してから再 add し、**新規コミットを作成する**
- `git commit --amend` は使わない（hook 失敗時はコミットが作成されていないため、`--amend` は意図せず直前のコミットを書き換える）
- `--no-verify` で hook をスキップしない（hook はプロジェクト側の品質ゲート）

### 8. 結果報告

`git log --oneline -<作成数>` で一覧表示。

## コミットメッセージ形式

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

<body: 任意。空行で区切る>
```

- **subject**: 日本語、50文字以下、末尾ピリオドなし
- **scope**: 英語、CLAUDE.md/rules の定義優先。なければディレクトリ/モジュール名から判断
- **body** を書くケース:
  - 破壊的変更がある（migration 手順や影響範囲を明示）
  - バグ修正で根本原因を記録したい
  - 複数ファイル/モジュールにまたがる構造変更で、subject だけでは意図が伝わらない
  - 関連 Issue / PR への参照。対象 Issue を完全に解決するときは `Closes: #456`（auto-close）、参照のみ・部分対応にとどまるときは `Refs: #123` を使う。本文中で Issue に言及する説明文では close / fix / resolve 系の語を Issue 番号に直接続けない（意図しない auto-close を避ける）。プロジェクト側に独自の closing keyword 運用規則（CLAUDE.md 等）があればそれを優先する

GitMoji と type の対応: [references/gitmoji-types.md](references/gitmoji-types.md)

## 注意事項

- `Co-Authored-By` トレーラーは付けない（Claude Code のデフォルト挙動を上書きする明示ルール。コミット主体は人間として記録する）
- `--no-verify` は使わない（hook 失敗時は原因を修正して再コミット）
- リモートへの push はしない（ユーザーの明示的指示がある場合のみ）