smart-commitlisted

# 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 語** 程度に収める