commit-changes

name	commit-changes
description	未コミット差分を確認し、レビューしやすい粒度の論理コミットに分割して作成する。 コミットしてほしいとき、PR 作成前に差分をコミットする必要があるとき、または implement-plan 完了後に open-pr / open-pr-followup へ渡す前に使う。 例: 「コミットして」「変更をコミット」「commit」「PR 前にコミット」。 push / PR 作成 / GitHub への書き戻しは行わない。

commit-changes

検証済みの working tree を、レビューしやすい 1 つ以上の local commit に変えるスキルです。 このスキルが担当するのは commit planning、staging、commit message の作成だけです。

Scope

• local commit を作る。
• レビューしやすくなる場合は複数 commit に分割する。
• push、PR 作成、GitHub への書き戻しは行わない。
• PR が必要な場合は、このスキルの後に open-pr または open-pr-followup を使う。

Hard constraints

• default branch では commit しない。
• staging 前に git status --short、git diff、git diff --staged を確認する。
• 無関係なユーザー変更が混在していて安全に分離できない場合は、停止して確認する。
• secrets、debug print、生成物の noise、無関係な file を commit に含めない。
• repository の commit message 言語、prefix、Conventional Commit ルールに従う。
• ユーザーがこの turn で commit を明示的に許可していない場合は、実行前に commit plan を提示する。

Workflow

Step 1: Inspect pending state

• 現在の branch を確認する。
• pending diff の全体を読む。
• staged diff がある場合はそれも読む。
• standalone invocation で lint / test コマンドが明らかな場合は、commit 前に実行する。
• pending diff がなければ、commit するものがない旨を報告して停止する。

git branch --show-current
git status --short
git diff
git diff --staged

Step 2: Plan logical commits

• レビューの流れが明確に保てる範囲で、最小の commit 数にする。
• 各 commit を、目的・影響・検証ポイントを含めて単独で理解できるようにする。
• reviewer が diff を自然に追える順序にする。
• 実装と docs、production code と test 専用の cleanup、意味のある生成物など、関心事が別なら分割する。
• semantic な変更と、機械的な移動・formatting・生成物更新は、分けたほうが review noise が減る場合に分割する。
• 密結合な code と test は同じ commit にまとめる。
• 1 つの挙動変更を理解するために reviewer が複数 commit をまたぐ必要が出る分割は避ける。
• file 単位、task checkbox 単位、小さな edit 単位での機械的な分割はしない。
• 1 つの commit は 1 つの一貫した関心事にする。

Step 3: Stage and commit intentionally

各 commit ごとに staged diff を確認してください。

git add -p
git diff --staged
git commit

• git add -p、pathspec、またはその両方で意図的に stage する。
• git add -A は、残り diff 全体が明らかに次の commit に属する場合だけ使う。
• staged diff を空でない状態にし、それ単独で理解できるようにする。
• reviewer の視点で staged diff を読み直し、他の commit の context なしにレビューできることを確認する。
• 何が変わったかだけでなく、なぜその変更が必要かが伝わる message を書く。
• commit message はすべて日本語で書き、該当する場合は Conventional Commit 形式を使う（例: feat: 新機能説明、fix: バグ修正説明、refactor: リファクタリング説明、docs: ドキュメント更新、test: テスト追加）。
• 現実的な範囲で、各 commit を build / test 可能な状態に保つ。

Step 4: Report

日本語で次を報告してください。

• 作成した commit hash と subject。
• working tree が clean か dirty か。
• PR に進む場合は、次の step が open-pr または open-pr-followup であること。