--- name: create-branch description: 現在の変更内容を確認し、適切なブランチ名を提案してブランチを作成するときに使う。ユーザーが「ブランチ作って」「作業用ブランチ切りたい」「変更に合わせてブランチ名を決めて」と言ったとき、または新規作業を始める前にブランチを作りたいときに適用する。git status / diff を確認し、プレフィックス規則(feat/fix/release/epic)に従ってブランチ名を提案し、ユーザー確認後に git checkout -b で作成する。 compatibility: git が使えること。カレントディレクトリが git リポジトリであること。 --- # ブランチ作成(変更内容に基づく提案) 現在の変更内容を分析し、プレフィックス規則に沿ったブランチ名を提案してからブランチを作成する。 ## 前提条件 - カレントディレクトリが git リポジトリであること。 - この skill 内で示す相対パスは、SKILL.md がある skill ディレクトリ基準で解決する。 ## ブランチ名のプレフィックス規則 | 種類 | プレフィックス | 用途 | |------|----------------|------| | 新機能 | `feat/` | 新機能の追加 | | 修正 | `fix/` | バグ修正・不具合対応 | | リリース用 PR | `release/` | リリース準備用ブランチ | | 大きい epic 系 | `epic/` | 複数機能を含む大きな変更 | ブランチ名は**小文字・ハイフン区切り**を推奨する。 ## ワークフロー ### 1. Git の状態を確認 以下を実行する。 ```bash git status git branch --show-current ``` - 変更されたファイルとステージング状態を把握する。 - 変更内容の種類を判定するために、必要なら次も実行する。 - `git diff`(未ステージの変更) - `git diff --cached`(ステージ済みの変更) ### 2. 変更内容の分析とブランチ種類の判定 変更内容からプレフィックスを決める。 - **新規ファイルの追加や新機能の実装** → `feat/` - **既存コードのバグ修正・不具合対応** → `fix/` - **複数機能にまたがる大きな変更・複数コミット** → `epic/` - **バージョン番号・リリースノート・リリース関連** → `release/` 変更内容が不明確な場合は、ユーザーに確認してからブランチ名を決める。 ### 3. ブランチ名の提案 - 変更されたファイル名・ディレクトリ名・機能名から**プレフィックス + スラッシュ区切りの名前**を提案する。 - 例: - `feat/add-user-authentication` - `fix/resolve-payment-error` - `release/v1.2.0` - `epic/mobile-order-system` ### 4. 注意事項の確認とユーザーへの確認 以下のチェックを行う。 - **既存ブランチ**: 提案したブランチ名が既に存在する場合 → エラーとして表示し、別名を提案するかユーザーに確認する。 - **メインブランチ**: 現在が `main` や `master` の場合 → 「現在 main/master にいます」と警告してから続行する。 - **未コミットの変更**: 未コミットの変更がある場合 → その旨を伝えつつ、ブランチ作成は続行してよい(ブランチ切り替えで変更は引き継がれる)。 提案したブランチ名を提示し、ユーザーが承認するか別の名前を指定するか確認する。ユーザーへの質問ツール(AskQuestion / AskUserQuestion 等)が使える場合は優先して使う。 ### 5. ブランチの作成 ユーザーが承認したら、次で作成する。 ```bash git checkout -b <ブランチ名> ``` 特定のベースブランチから分岐する場合は: ```bash git checkout -b <ブランチ名> <ベースブランチ> ``` 作成後、現在のブランチ名を `git branch --show-current` で確認してユーザーに伝える。 ## 作業時のルール - ブランチ名の決定は**ユーザー確認を必須**とする。一方的に実行しない。 - 既存ブランチとの衝突は必ず検出し、上書きせずに別名を提案する。 - 変更がほぼない(空の diff)状態でも、ユーザーが「ブランチを作りたい」と言っていれば、名前の提案と作成まで行ってよい。