commit

Topics in the source

• Conventional Commit Skill
• 手順
• 関心事の分離ルール
• 判断に迷う場合
• Conventional Commits 形式
• type の選択基準
• ルール
• コミット実行

変更を関心事ごとに分離し、それぞれ 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つしかない場合 → 確認ステップをスキップしてそのままコミットする | type | 使う場面 | | ---------- | ---------------------------------------------- | | feat | 新機能の追加 | | fix | バグ修正 | | docs | ドキュメントのみの変更 | | style | コードの意味に影響しない変更（フォーマット等） | | refactor | バグ修正でも機能追加でもないコード変更 | | test | テストの追加・修正 | | chore | ビルドプロセス・補助ツール・設定の変更 | | perf | パフォーマンス改善 | | ci | CI 設定の変更 | | build | ビルドシステムや外部依存の変更 | | revert | 過去のコミットの取り消し | subject は命令形・現在形で、先頭を小文字に、末尾にピリオドを付けない scope はオプション。変更対象のモジュール・パッケージ名（例: parser, build, api） 破壊的変更は ! を type の後に付ける（例: feat!:

This is an excerpt. Refer to the complete source and its current requirements.