【Claude Code】 Gitブランチ名を命名するSkill作ってみた

はじめに

GitHubを用いて開発を行なっている際、「ブランチ名は何にしよう？」と迷った経験はありませんか？
その時間、AIを使えばなくせます！
というわけで、Claude Codeのskill-creatorを使ってさっそくSkill化してみました。

skill-creatorの使い方は、こちらの記事をご参照ください。

リクエスト内容

以下のようにリクエストしてみました。

完成したのがこちら

一部マークダウンの仕様上、[```]の前に#を入れています。

~.claude/skills/suggest-branch/SKILL.md

---
name: suggest-branch
description: 現在のgit作業ディレクトリの状態を分析し、Conventional Branch命名規則に基づいた適切なブランチ名候補を3つ理由付きで提案するスキル。ユーザーが `/suggest-branch` と入力したとき、または「ブランチ名を提案して」「今の変更を別ブランチに切り出したい」「このコミット用のブランチ名は？」「適切なブランチ名を考えて」など、未コミットの変更内容に基づいて新しい作業ブランチを命名したい場面で必ず使用する。コミット前のブランチ分割、未コミット変更の整理、Conventional Branch準拠の命名が必要なすべてのケースで本スキルを優先的に呼び出すこと。
---

# suggest-branch

現在のgitブランチと未コミット差分を分析し、Conventional Branch命名規則に従ったブランチ名を3案提示するスキル。出力はすべて日本語。

## このスキルが目指すこと

ユーザーは作業ディレクトリで何らかの変更を加えた状態で、その変更を切り出すための新しいブランチを作ろうとしている。スキルの役割は次の3点をワンショットで提供すること:

1. 現在のブランチを正確に把握する
2. 全差分を読み解いて変更の本質を要約する
3. 業界で最も普及している命名規則(Conventional Branch)に沿って、観点の異なる3案を理由とともに提示する

ユーザーは出力された `git checkout -b ...` コマンドをコピペするだけで、適切な命名のブランチを作成できる状態を目指す。

## 実行手順

### Step 1: 現在のブランチと差分の状況を一括取得

以下を **並列で** 実行する(Bashツールの並列呼び出しを使う):

#```bash
git branch --show-current
#```

#```bash
git status --short
#```

#```bash
git diff HEAD --stat
#```

#```bash
git diff HEAD
#```

#```bash
git ls-files --others --exclude-standard
#```

これで「ブランチ名 / 変更ファイル一覧 / 変更行数の概要 / 実際の差分本文 / 未追跡ファイル一覧」が一度に揃う。

### Step 2: 未追跡ファイルの内容を確認(必要な場合のみ)

`git ls-files --others --exclude-standard` で未追跡ファイルが返ってきた場合、それらの中身も把握する必要がある。テキストファイルのみ `Read` ツールで読み取る。バイナリ(画像、フォント、PDF等)はファイル名と用途の推測のみで十分。

差分が極端に巨大(数千行超)な場合は `git diff HEAD` の全文を読み込まず、`--stat` の結果と各ファイルの先頭・末尾の差分のみで判断する。

### Step 3: 変更内容を要約する

差分から次を読み取る:

- **主目的**: 機能追加 / バグ修正 / リファクタリング / ドキュメント / 設定変更 / テスト / 性能改善 / 雑務 のどれか
- **影響範囲**: 何ファイル、どのディレクトリ・モジュール
- **核心的な変更**: 新規追加された関数・クラス・画面、修正された箇所のロジックの肝
- **副次的な変更**: 設定ファイル、依存関係、ビルド、テストの追加など

複数の独立した目的が混在している場合(例: 機能追加とリファクタリングが同居)はそのことを後段の出力で必ず明示する。

### Step 4: Conventional Branch命名規則で3案を生成する

#### 命名規則(基準)

書式: `<type>/<kebab-case-description>`

| type | 用途 |
|------|------|
| `feat` | 新機能の追加 |
| `fix` | バグ修正 |
| `hotfix` | 本番環境の緊急修正 |
| `refactor` | 動作を変えないコード整理 |
| `docs` | ドキュメントのみの変更 |
| `style` | フォーマット・空白等(動作変更なし) |
| `test` | テストの追加・修正 |
| `chore` | ビルド・ツール・依存関係などの雑務 |
| `perf` | パフォーマンス改善 |
| `ci` | CI/CD設定の変更 |
| `build` | ビルドシステムの変更 |

description部の作法:

- 英小文字 + ハイフン(kebab-case)
- 50文字以内、簡潔に
- 動詞は省略可。名詞句が一般的(`feat/user-authentication` など)
- IssueIDがあれば `feat/123-user-auth` のように先頭に付与してもよい

#### 3案の出し分け方針

**同じ案を言い換えただけにしない**。観点を変えて3つ出す:

1. **本命**: 変更の核心を最も的確に表す、最推奨の名前
2. **広いスコープ案**: 機能群やモジュール名で抽象度を1段上げた名前
3. **代替typeまたは詳細案**: typeの判断が割れうる場合の別type、または対象を絞り込んだ詳細名

判断の根拠が薄い・無理矢理3つひねり出すような場合は、率直にその旨をコメントしてよい。空虚な選択肢を増やすより誠実さを優先する。

### Step 5: 最終出力

以下のフォーマットで出力する。Markdownのコードブロックや見出しはそのまま使ってよい。

#```
## 現在のブランチ
`<現在のブランチ名>`

## 変更内容の要約
- **目的**: <変更の主目的>
- **変更ファイル数**: <数> 件 (追加 +N / 削除 -M 行)
- **主な変更点**:
  - <変更点1>
  - <変更点2>
  - <変更点3>
- **副次的な変更**: <あれば記載、なければこの行は省略>
- **注意点**: <複数目的が混在している等の警告があれば記載、なければ省略>

## 推奨ブランチ名候補

### 候補1: `<type>/<description>` ⭐ 推奨
**理由**: <なぜこの名前が最も適切か。変更内容のどこに着目したか>

#```bash
git checkout -b <type>/<description>
#```

### 候補2: `<type>/<description>`
**理由**: <この名前を選ぶ場合の観点(例: 機能群でまとめる/Issue連携)>

#```bash
git checkout -b <type>/<description>
#```

### 候補3: `<type>/<description>`
**理由**: <この名前を選ぶ場合の観点(例: 別typeとして解釈/より詳細)>

#```bash
git checkout -b <type>/<description>
#```
#```

## エッジケース

- **変更が一切ない場合**: `git status` の結果が空なら、「現在のブランチに未コミットの変更はありません。提案できる差分がないため終了します。」と伝えて終了する。
- **gitリポジトリでない場合**: `fatal: not a git repository` 等が返ったら、その旨を伝え `git init` を提案する。Step 2以降は実行しない。
- **巨大差分(数千行超)の場合**: `git diff HEAD` 全文の読み込みは避け、`--stat` と代表ファイルの抜粋だけで要約する。要約欄に「差分が大きいため概要ベースで分析」と注記する。
- **複数の独立した目的が混在している場合**: 候補を出す前に「変更内容が複数の独立した目的を含むようです。本来はブランチを分割することを推奨します」と注意を添える。その上で、最も支配的な変更に基づいて候補を出す。
- **typeの判断に迷う場合**: 候補1と候補3で異なるtypeを採用し、それぞれの判断根拠を理由欄で明示する。読み手が選べるようにする。
- **ユーザーが英語名ではなく日本語の説明的なブランチ名を希望する場合**: Conventional Branchに反するため通常は英語kebab-caseを推奨するが、ユーザーが明示的に希望した場合は理由付きで日本語ローマ字版も補助案として提示してよい。

## 参考: なぜConventional Branchか

このスキルは [Conventional Commits](https://www.conventionalcommits.org/) の慣例をブランチ名に拡張した [Conventional Branch](https://conventional-branch.github.io/) 形式を採用している。`feat/`, `fix/`, `chore/` といったプレフィックスは現代のOSS・企業開発で事実上の標準であり、CIフィルタ、自動リリースノート生成、PRレビュー効率化などのツールチェーンとも親和性が高い。Git Flow(`feature/`, `bugfix/`)も併存するが、近年のトレンドとしてはConventional Commits由来の短いプレフィックス(`feat/`, `fix/`)が優勢である。

使ってみた

mainブランチにて、以下のドキュメント(Todoアプリの機能要件)を追加しました。

docs/requirements.md

# Todoアプリ 機能要件

## 概要
タスクを管理するためのシンプルなTodoアプリを作成する。

ユーザーはタスクの作成・編集・削除・完了管理を行える。

---

# 機能要件

## 1. タスク一覧表示

### 内容
- 登録済みのTodoを一覧表示する
- 新しい順で表示する

### 表示項目
- タスク名
- ステータス（未完了 / 完了）
- 作成日時

---

## 2. タスク作成

### 内容
- 新しいTodoを登録できる

### 入力項目
- タスク名（必須）

### バリデーション
- 空文字不可
- 100文字以内

---

## 3. タスク編集

### 内容
- 登録済みTodoを編集できる

### 編集可能項目
- タスク名

### バリデーション
- 空文字不可
- 100文字以内

---

## 4. タスク削除

### 内容
- Todoを削除できる

### 仕様
- 削除前に確認ダイアログを表示する

---

## 5. タスク完了管理

### 内容
- Todoを完了状態に変更できる
- 完了状態を未完了に戻せる

### UI
- チェックボックスで切り替え

---

## 6. フィルター機能

### 内容
以下の条件でTodoを絞り込みできる

- すべて
- 未完了
- 完了済み

---

# 非機能要件

## UI / UX
- スマートフォン対応
- シンプルなデザイン
- レスポンシブ対応

## パフォーマンス
- Todo一覧表示は1秒以内

## セキュリティ
- XSS対策を行う
- 入力値バリデーションを実施する

---

# 今後追加予定

- ログイン機能
- タスク期限設定
- カテゴリ機能
- 検索機能
- ドラッグ&ドロップ並び替え
- 通知機能

Claude Codeにて/suggest-branchスラッシュコマンドを実行すると、

以下のように期待通りの出力が表示されました！

よかったらぜひコピペして使ってみてください。