review-staged

Review Git Staged Changes

Review the staged diff (git diff --cached) for potential issues and improvements, then prepare the commit. When the user supplies a proposed commit message, use it as context for the intended change, not as a correctness requirement.

User direction

A direct "commit" or "approved, commit" instruction authorizes the understood scope and takes precedence over this skill's review and approval defaults. Unless the user also requests review first, use stage to verify and commit that scope without starting or resuming a review or asking for approval again. This also applies after findings or a review verdict; a reviewer's recommendation does not overrule the user's commit instruction. When project instructions require review before every commit, a commit instruction for changes that review has not finished on since they last changed runs the review first, and only an explicit instruction to skip review skips it.

Run the review

Size the scope before reading it: git diff --cached --stat. Review all staged content as supplied. The size or coherence of a proposed commit does not affect the review verdict.

With the staged diff as the scope, read and follow ../review/references/single-pass.md.

After the findings, use the shared Commit notes section for optional message or grouping advice. If a split would improve reviewability or make later reverts safer, identify the files or hunks in each independently committable batch and give a complete Conventional Commit message for every batch. State the specific reason for the split; size alone is not enough. These notes never receive a priority and never change the verdict. If they are the only concerns, return Verdict: LAND and No issues found.

Post-review commit flow

If the verdict is DISCARD, explain why the change should not land and stop the review. A later user instruction to commit takes precedence as described in User direction.