Validate changes before commit

Evaluate staged git changes using the output-evaluator agent to catch issues before committing.

Process

Step 1: Check for staged changes

Run git diff --cached --stat to see what's staged. If nothing is staged, inform the user and exit.

Step 2: Get the full diff

Run git diff --cached to get the complete diff of all staged changes.

Step 3: Invoke the evaluator

Use the Task tool to launch the output-evaluator agent with the diff:

Evaluate these staged changes for correctness, completeness, and safety.
Return a JSON verdict with scores and issues.

Changes:
[paste the git diff here]

Step 4: Parse and act on verdict

Based on the evaluation result:

If APPROVE:

• Tell the user the changes passed evaluation
• Show the summary and scores
• Ask if they want to proceed with commit

If NEEDS_REVIEW:

• Show all issues found (grouped by severity)
• Show the suggestion from the evaluator
• Ask the user how to proceed:
  • Fix issues and re-evaluate
  • Commit anyway (acknowledge risks)
  • Abort

If REJECT:

• Clearly state the changes were rejected
• Show critical issues that caused rejection
• Do NOT offer to commit anyway
• Suggest specific fixes

Step 5: Commit (if approved)

If user confirms, create the commit using the standard commit flow.

Usage examples

/validate-changes

Output:

Evaluating 3 staged files...

VERDICT: NEEDS_REVIEW

Scores:
  Correctness:  8/10
  Completeness: 6/10
  Safety:       9/10

Issues Found:
  [MEDIUM] src/api/handler.ts:45
    Missing error handling for network failures

  [LOW] src/utils/format.ts:12
    Consider adding input validation

Suggestion: Add try-catch around the fetch call in handler.ts

How would you like to proceed?
  1. Fix issues and re-evaluate
  2. Commit anyway (1 medium issue)
  3. Abort

Cost awareness

This command invokes an LLM evaluation, which uses API tokens:

• Typical cost: $0.01-0.05 per evaluation (using Haiku)
• Larger diffs: May cost more due to increased token usage

When to use

• After significant code changes before committing
• When working on unfamiliar parts of the codebase
• For changes that affect security-sensitive code
• Before pushing to shared branches

When to skip

• Trivial changes (typos, formatting)
• Documentation-only changes
• When you've already manually reviewed thoroughly
• When iterating quickly on a feature branch

Integration with git hooks

For automatic evaluation on every commit, see pre-commit-evaluator.sh hook. This command is the manual alternative when you want control over when evaluation runs.