いつ使うか
このスキルは、各コミットやPRに何を含めるべきかを判断する際に読み込んでください。
以下の場合に使用します。
- 機能をレビュー可能な作業単位に分割する
- PRを開く前にコミットを準備する
- 大きな変更をチェーンPRまたはスタックPRに分割する
- レビュアーの認知負荷を健全に保つ
- SDDタスクを適用し、誤って400行を超えるPRを作成しないようにする
重要なルール
| ルール | 要件 |
|---|---|
| 作業単位でコミット | コミットは、提供可能な動作、修正、マイグレーション、またはドキュメントの単位を表すこと。 |
| ファイル種別でコミットしない | 単独で動作しない models, services, tests などを避ける。 |
| テストはコードと一緒に | テストは、検証する動作と同じコミットに含める。 |
| ドキュメントはユーザーに見える変更と一緒に | ドキュメントは、説明する機能やワークフローと同じコミットに含める。 |
| ストーリーを伝える | レビュアーが差分とメッセージから各コミットの存在理由を理解できるようにする。 |
| 将来のPR対応 | 各コミットは、変更が大きくなった場合にチェーンPRの候補となるようにする。 |
| SDDワークロードガード | SDDタスクが400行を超える変更を予測する場合、実装前にコミットをチェーンPRスライスにグループ化する。 |
| 予算はコードゴルフではない | レビュー予算（デフォルト400行、またはセッションの review_budget_lines）に収めるために、コメント、空行、ドキュメント、テストを削除したり、コードを圧縮して差分を小さくしないこと。作業単位でスライスするか、超過を報告すること。 |
作業単位チェックリスト
コミットする前に、以下を確認します。
- コミットにひとつの明確な目的がある。
- このコミットだけを適用してもリポジトリが意味をなす。
- 該当する場合、この単位のテストまたはドキュメントが含まれている。
- ロールバックしても、無関係な作業を取り消さずに済む。
- コミットメッセージがファイルリストではなく結果を説明している。
分割例
| 弱い分割 | より良い作業単位分割 |
|---|---|
add models | feat(auth): add token validation domain model and tests |
add services | feat(auth): wire token validation into login flow |
add tests | テストは各動作コミットに含める |
update docs | ドキュメントは説明するユーザー向け変更に含める |
PRとの関係
作業単位コミットをチェーンPRの基盤として使用します。
- 最小の独立した作業単位を構築する。
- その単位の検証を含める。
- Conventional Commitメッセージでコミットする。
- PRが400行に近づいた場合、コミットまたはコミットグループをチェーンPRに昇格させる。
SDDとの関係
sdd-tasks がレビュー負荷予測を生成した場合：
- 低リスク：作業単位コミットを1つのPR内に維持する。
- 中リスク：作業単位でコミットし、PR作成前に変更行数を監視する。
- 高リスク：SDDの
delivery_strategyに従う —ask-on-riskでは質問、auto-chainでは自動スライス、予算超過のsingle-prではsize:exceptionを要求、exception-okでは受け入れられたsize:exceptionを記録する。 - 分割には限界がある：正直に一度スライスを試みた後、予算内に収まる一貫した作業単位分割が見つからない場合は、分割をやめ、最小の正直なコミット数を
size:exception推奨とともに報告する。コードを縮小して目標数に到達するための反復は行わない。
各SDD作業単位は、以下の要素を備えたコミットまたはPRに明確にマッピングされる必要があります。
- 明確な開始状態
- 明確な完了状態
- 同じ単位での検証
- 無関係な作業を削除しないロールバック
コマンド
# コミット前にストーリーを確認
git diff --stat
git diff --cached --stat
# 最近のコミットスタイルを確認
git log --oneline -5