Evaluate staged Git changes before committing using an LLM, a language model acting as a reviewer. Receive correctness, completeness, and safety scores, plus issues by severity, to decide whether to fix, commit, or stop.
Evaluate staged changes using LLM-as-a-Judge before committing
Review the instructions the agent will receive before you install.
Evaluate staged git changes using the output-evaluator agent to catch issues before committing.
Run git diff --cached --stat to see what's staged. If nothing is staged, inform the user and exit.
Run git diff --cached to get the complete diff of all staged changes.
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]
Based on the evaluation result:
If APPROVE:
If NEEDS_REVIEW:
If REJECT:
If user confirms, create the commit using the standard commit flow.
/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
This command invokes an LLM evaluation, which uses API tokens:
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.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Evaluate Claude Code agents, skills, and commands with weighted quality criteria. Get scores, readiness grades, template comparisons, and practical improvement suggestions in Markdown or JSON reports to guide reviews before release.
Assess a codebase across seven areas, including exposed credentials, security, dependencies, structure, and tests. Receive category scores, findings tied to file locations, and a prioritized improvement plan with smaller tasks that can be completed quickly.
Measure code patterns such as casts to any or disabled lint rules, then run repeated, targeted edits. Keep changes that improve the chosen metric, revert unsuccessful changes, and track results for each improvement loop.
Generate several separate solutions, compare them against criteria fixed in advance, and verify the selected result through executable checks or an independent reviewer. Keep a proof log documenting candidates, evidence, failures, and remaining limits.
Monitor a live application after deployment and compare it with a saved baseline, a record of its earlier state. Check page responses, loading times, and new errors, flag persistent changes, and produce a per-page health report.
Rebuild project context after clearing a conversation or returning to work. Review recent Git history, uncommitted changes, and TODO markers to get a structured summary of project status and suggested next steps.