name	self-review-before-commit
description	Before committing, launch a code-review agent over the staged + unstaged diff and report findings; only proceed to commit after the review (and any fixes it surfaces).

Self-review before commit

When this skill is invoked, do NOT commit yet. Run a self-review first.

Steps

Gather the diff to review. In parallel:
- git status — full list of changed files (including untracked).
- git diff HEAD — combined staged + unstaged changes since the last commit.
- git log -1 --format="%H %s" — base commit for context.
If the diff is empty, stop and tell the user there is nothing to review.
Launch a review agent. Use the Agent tool with subagent_type: general-purpose (or code-reviewer if available in this environment). Hand it a self-contained prompt — the agent has none of this conversation's context. Include:
- The exact files changed and their paths.
- What the user is trying to accomplish in this set of changes (1-2 sentences, synthesized from the conversation — do not delegate this understanding).
- The diff itself, or instruction to git diff HEAD -- <paths> themselves.
- Ask for: correctness bugs, security issues, concurrency/race risks, obvious style violations per project conventions in CLAUDE.md, and any dead/unused code introduced. Explicitly ask the agent to flag findings by severity (blocker / nit) and to skip praise.
- Also require these three passes (they catch the bugs diff-local reading misses):
  - Caller-impact — for any method whose signature OR behavior changed, enumerate ALL callers and check the new behavior against each caller's intent. A regression often only manifests at a call site outside the diff.
  - Project conventions beyond CLAUDE.md — .csproj global usings / type aliases (e.g. Range → SDGraphics.Range, so System.Range slice syntax is off-convention), analyzer rules, and the codebase's preferred patterns.
  - Exception paths — for new IO / external-API / callback code, what can throw, and is failure swallowed where it must be (telemetry/attachments are best-effort)?
- For sensitive subsystems (telemetry/logging, save/load, threading, serialization), run a deeper pass and lift the word cap. Otherwise cap: "Report under 300 words, bullet form."
Read the agent's report. Categorize findings:
- Blockers — correctness/security/concurrency issues. Fix before committing.
- Nits — style/clarity. Surface to the user; let them decide.
- False positives — note briefly why dismissed.
Present the review to the user in a short summary. If there are blockers, propose fixes and ask the user before applying. If there are only nits, list them and ask whether to address or commit as-is. If the review is clean, say so and proceed to the normal commit flow.
After the user confirms (and any fixes are applied), perform the commit exactly as the standard "create a git commit" flow does — drafted commit message via HEREDOC, Co-Authored-By trailer, etc.

Notes

The review agent should run in the foreground — you need its findings before you can decide whether to commit.
Do not skip step 2 when the diff is "obviously small." A trivial-looking diff is exactly where a fresh pair of eyes catches the missed null guard or the accidentally-removed branch.
If the user explicitly says "skip review" or "just commit," honor that and skip directly to the commit flow.

Self-review before commit

When this skill is invoked, do NOT commit yet. Run a self-review first.

Steps

Gather the diff to review. In parallel:

git status — full list of changed files (including untracked).
git diff HEAD — combined staged + unstaged changes since the last commit.
git log -1 --format="%H %s" — base commit for context.

If the diff is empty, stop and tell the user there is nothing to review.

Launch a review agent. Use the Agent tool with subagent_type: general-purpose (or code-reviewer if available in this environment). Hand it a self-contained prompt — the agent has none of this conversation's context. Include:

The exact files changed and their paths.
What the user is trying to accomplish in this set of changes (1-2 sentences, synthesized from the conversation — do not delegate this understanding).
The diff itself, or instruction to git diff HEAD -- <paths> themselves.
Ask for: correctness bugs, security issues, concurrency/race risks, obvious style violations per project conventions in CLAUDE.md, and any dead/unused code introduced. Explicitly ask the agent to flag findings by severity (blocker / nit) and to skip praise.
Also require these three passes (they catch the bugs diff-local reading misses):
- Caller-impact — for any method whose signature OR behavior changed, enumerate ALL callers and check the new behavior against each caller's intent. A regression often only manifests at a call site outside the diff.
- Project conventions beyond CLAUDE.md — .csproj global usings / type aliases (e.g. Range → SDGraphics.Range, so System.Range slice syntax is off-convention), analyzer rules, and the codebase's preferred patterns.
- Exception paths — for new IO / external-API / callback code, what can throw, and is failure swallowed where it must be (telemetry/attachments are best-effort)?
For sensitive subsystems (telemetry/logging, save/load, threading, serialization), run a deeper pass and lift the word cap. Otherwise cap: "Report under 300 words, bullet form."

Read the agent's report. Categorize findings:

Blockers — correctness/security/concurrency issues. Fix before committing.
Nits — style/clarity. Surface to the user; let them decide.
False positives — note briefly why dismissed.

Present the review to the user in a short summary. If there are blockers, propose fixes and ask the user before applying. If there are only nits, list them and ask whether to address or commit as-is. If the review is clean, say so and proceed to the normal commit flow.

After the user confirms (and any fixes are applied), perform the commit exactly as the standard "create a git commit" flow does — drafted commit message via HEREDOC, Co-Authored-By trailer, etc.

Notes

The review agent should run in the foreground — you need its findings before you can decide whether to commit.

Do not skip step 2 when the diff is "obviously small." A trivial-looking diff is exactly where a fresh pair of eyes catches the missed null guard or the accidentally-removed branch.

If the user explicitly says "skip review" or "just commit," honor that and skip directly to the commit flow.

self-review-before-commit