commitlisted

# Conventional Commit Skill 変更を関心事ごとに分離し、それぞれ Conventional Commits 形式でコミットする。 ## 手順 1. `git branch --show-current` で現在のブランチを確認する - `main` または `master` の場合は「mainブランチへの直接コミットは禁止されています。`/start-dev` スキルを使って worktree を作成してください。」と伝えて**終了する** 2. `git status` と `git diff`（ステージ済み＋未ステージ）を確認する 3. 変更がない場合はその旨を伝えて終了する 4. 変更内容を分析し、**関心事（concern）ごとにグループ分け**する 5. グループ分けの結果をユーザーに提示した後、**確認を待たずにそのままコミットを実行する** 6. グループごとに以下を繰り返す： a. 該当ファイルのみを `git add` でステージする b. Conventional Commits 形式のメッセージを生成する c. コミットを実行する 7. 全コミット完了後、結果一覧をユーザーに通知する ## 関心事の分離ルール - **機能単位**: 同じ機能に関わるファイル群を1コミットにまとめる - **レイヤー分離**: プロダクションコードとテストコードが同じ機能なら同一コミットでよい - **設定変更**: ビルド設定・依存追加など基盤的な変更は独立コミットにする - **ドキュメント**: ドキュメントのみの変更は独立コミットにする - **リファクタ**: 機能変更を伴わないリファクタは独立コミットにする ### 判断に迷う場合 - 1ファイルの変更が複数の関心事にまたがる場合 → 最も主要な関心事に含める（hunk 分割はしない） - 関心���が1つしかない場合 → 確認ステップをスキップしてそのままコミットする ## Conventional Commits 形式 ``` <type>(<scope>): <subject> [body] [footer] ``` ### type の選択基準 | type | 使う場面 | | ---------- | ---------------------------------------------- | | `feat` | 新機能の追加 | | `fix` | バグ修正 | | `docs` | ドキュメントのみの変更 | | `style` | コードの意味に影響しない変更（フォーマット等） | | `refactor` | バグ修正でも機能追加でもないコード変更 | | `test` | テストの追加・修正 | | `chore` | ビルドプロセス・補助ツール・設定の変更 | | `perf` | パフォーマンス改善 | |