Commit

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	パフォーマンス改善
ci	CI 設定の変更
build	ビルドシステムや外部依存の変更
revert	過去のコミットの取り消し

ルール

• subject は命令形・現在形で、先頭を小文字に、末尾にピリオドを付けない
• scope はオプション。変更対象のモジュール・パッケージ名（例: parser, build, api）
• 破壊的変更は ! を type の後に付ける（例: feat!:）か、footer に BREAKING CHANGE: を記載
• subject は英語で記述する（body/footer は日本語可）
• 複数の独立した変更が混在する場合は、関心事ごとにコミットを分離する

コミット実行

グループごとに以下の形式でコミットする：

# 1. 該当ファイルのみステージ
git add <file1> <file2> ...

# 2. コミット
git commit -m "$(cat <<'EOF'
<type>(<scope>): <subject>

<body（必要な場合）>
EOF
)"

提示フォーマット

グループ分け結果をユーザーに提示する際の形式：

### コミット計画

1. `feat(parser): add token position tracking`
   - src/lexer.ts
   - src/parser.ts
   - tests/lexer.test.ts

2. `chore(build): update bundler config`
   - build.config.ts

計画を提示した後、ユーザーの返答を待たず即座にコミットを実行する。