work-unit-commits

使用するタイミング

各コミットや PR に何を含めるか決めるときに、このスキルを読み込みます。

次の用途で使用します。

• 機能をレビュー可能な作業に分割する。
• PR を作成する前にコミットを準備する。
• 大規模な変更を、連鎖型または積み上げ型の PR に分割する。
• レビュアーの認知負荷を適切に保つ。
• 変更行数が 400 行を超える PR を誤って作成することなく、SDD タスクを適用する。

重要なルール

ルール	要件
作業単位ごとにコミットする	コミットは、成果物として提供できる動作、修正、移行、またはドキュメントの単位を表します。
ファイルの種類ごとにコミットしない	それぞれ単独で機能しない場合は、models、次に services、次に tests のような分け方を避けます。
テストをコードとまとめる	テスト対象の動作と同じコミットにテストを含めます。
ドキュメントをユーザー向けの変更とまとめる	ドキュメントは、説明対象の機能やワークフローと一緒に含めます。
一連の流れを伝える	レビュアーが差分とメッセージから各コミットの目的を理解できるようにします。
将来の PR に適した形にする	変更が大きくなる場合、各コミットを連鎖型 PR の候補にできるようにします。
SDD の作業量を管理する	SDD タスクで 400 行を超える変更が予測される場合、実装前にコミットを連鎖型 PR の単位にまとめます。

作業単位チェックリスト

コミットする前に、次の項目を確認します。

• コミットの目的が 1 つに明確に定まっている。
• このコミットだけを適用しても、リポジトリの整合性が保たれる。
• 該当する場合、この単位のテストやドキュメントが含まれている。
• 無関係な作業を元に戻すことなく、妥当な範囲でロールバックできる。
• 対象を絞ったテストコマンドと正確な結果が記録されている。
• ランタイムのハーネスコマンド／シナリオと正確な結果が記録されている。または、ランタイム境界が存在しない理由を明示した N/A が記載されている。
• ロールバックの境界に、無関係な作業を含めずに削除できる正確なファイル／動作が示されている。
• コミットメッセージがファイル一覧ではなく、得られる成果を説明している。

分割例

適切でない分割	より適切な作業単位の分割
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 の基礎として使用します。

1. 独立して成立する、最小の作業単位を作成します。
2. その単位の検証を含めます。
3. Conventional Commits 形式のメッセージでコミットします。
4. PR の変更行数が 400 行に近づいたら、コミットまたはコミットのグループを連鎖型 PR にします。

ODD との関係

Organic Driven Development（ODD）では、実質的なタスクを完了するたびに、機能ブランチ上で作業単位のコミットを作成します。

• すべての ODD タスクは、少なくとも 1 つの作業単位コミットで完了します。デフォルトブランチ上にいる場合は、まずブランチを作成し、動作とともにテストおよびドキュメントを追加し、Conventional Commit メッセージを使用します。
• 標準のレビュー対象はそのコミットです。レビューを延期する場合は、前回レビュー済みの境界を基準とした、そのコミットが属する PR の範囲です。TODO のチェックボックスでも、機能ブランチに蓄積された全変更でもありません。
• 作業単位コミットによる、実行中の作成者の変更行数が、デリバリー戦略の用語である ask-on-risk、auto-chain、single-pr、exception-ok の決定に用いられます。
• >400 のしきい値には、作成者による追加行数と削除行数の合計を数えます。作成者による変更行数から生成されたゴールデンファイルは除外しますが、完全なスナップショットの同一性確認とレシート検証には、生成されたすべてのファイルを含めます。
• ODD の機能ドキュメントには、証拠としてコミットの識別情報を記録します。デリバリー戦略が適用される場合は、選択したチェーン戦略とスライスの境界（各 PR に含まれるコミット）も記録します。

各 ODD 作業単位は、次の内容が明確なコミットまたは PR に対応させる必要があります。

• 明確な開始状態
• 明確な完了状態
• 同じ作業単位内での検証
• 無関係な作業を取り除かないロールバック

実装の証拠には、必ず以下を含める必要があります。

• 対象を絞ったテストコマンドと正確な結果。
• ランタイムハーネスのコマンド／シナリオと正確な結果。該当しない場合は、理由を添えて明示的に N/A と記載します。
• コミットの作成とは独立して示したロールバックの境界。未コミットの作業単位にも必要です。
• 範囲が限定されたレビュー台帳を修正する場合は、単一の修正トランザクション内に原子的な作業単位をまとめます。作業単位の数によって、修正の予算が増えることはありません。

コマンド

# Review the story before committing
git diff --stat
git diff --cached --stat

# Check recent commit style
git log --oneline -5