Commit Review

Systematic review of git commits for message quality, diff hygiene, and common mistakes before pushing.

Version: 1.0.0 Category: Skills Author: @sample-creator

When to Use

• You want to review your commits before pushing to a shared branch
• You need to check if commit messages follow conventional format
• You want to catch common mistakes (large files, secrets, debug code)
• A PR has commits that need cleanup before merge

When NOT to Use

• For full code review (use a dedicated code review tool instead)
• For CI/CD pipeline checks (this is a pre-push local review)
• For rebasing or rewriting history (this reviews, not rewrites)

Activation Protocol

Before responding to any invocation:

1. Load review criteria: Read

   ${CLAUDE_SKILL_DIR}/references/review-criteria.md

   — Contains: commit message format rules, diff size thresholds, anti-patterns
2. Load examples: Read

   ${CLAUDE_SKILL_DIR}/examples/good-vs-bad.md

   — Contains: 5 examples of good commits vs. problematic commits
3. Identify scope: How many commits to review? Last N, a range, or all unpushed?
4. Run question system: Check for required inputs (see below)

Question System

standard

relaxed

standard

strict

Core Instructions

Review Pipeline

For each commit in the review scope:

Step 1 — Message Quality

• Does the message follow conventional format? (

  type: subject

  or

  type(scope): subject

  )
• Is the subject line under 72 characters?
• Does it explain WHY, not just WHAT?
• Is it written in imperative mood? ("add feature" not "added feature")

Step 2 — Diff Analysis

• How many files changed? Flag if >10 files (might need splitting)
• How many lines added/removed? Flag if >500 lines net
• Are there unrelated changes mixed in? (scope creep)

Step 3 — Anti-Pattern Scan

• Debug code left in? (

  console.log

  ,

  debugger

  ,

  print("HERE")

  )
• Secrets or credentials? (API keys, tokens, passwords)
• Large binary files? (images, compiled assets >1MB)
• TODO/FIXME comments added without ticket reference?

Step 4 — Quality Signal

• Were tests modified alongside code changes? (good signal)
• Were docs updated if behavior changed? (good signal)
• Is the commit atomic? (one logical change per commit)

Modes

relaxed

standard

strict

Output Structure

COMMIT REVIEW — {branch} ({N} commits)

Commit 1: {short hash} — {subject}
  Message:  PASS | WARN | FAIL — {note}
  Diff:     {files} files, +{added}/-{removed} lines — {assessment}
  Patterns: {anti-patterns found or "clean"}
  Signal:   {quality signals detected}

...

SUMMARY
  Reviewed: {N} commits
  Ready to push: {yes/no}
  Issues: {count} ({critical}, {warnings})
  Recommendation: {specific action}

Quality Gate

Before delivering the review:

• Every commit in scope was reviewed (none skipped)
• Each finding includes a specific recommendation (not just "fix this")
• Anti-pattern scan checked for secrets (security-critical)
• Summary gives a clear push/no-push recommendation
• Output follows the structure template above

If any check fails: complete the review before delivering.

Anti-Patterns

• Rubber-stamping: Saying "looks good" without actually reviewing the diff
• Nitpicking format over substance: Obsessing over commit message style when the diff has real issues
• Missing the forest: Reviewing individual commits without noticing they should be squashed
• False security: Scanning for

  console.log

  but ignoring hardcoded API keys

Composability

• As input to:

  /publish

  (review commits before publishing a myClaude product)
• As output from: Any development workflow that produces commits
• In workflows: Can be embedded as a pre-push step in a development workflow