How do I install the Validate Changes skill?

Run npx skillmds@latest add gabrielmoreira/validate-changes in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the Validate Changes skill do?

Evaluate staged changes using LLM-as-a-Judge before committing It is listed under AI & ML on SkillMD.

Is Validate Changes safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: makes network calls, reads secrets. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Validate Changes?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Validate Changes free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Validate Changes?

gabrielmoreira (@gabrielmoreira) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Validate Changes by gabrielmoreira — Agent Skill

Name: Validate Changes
Rating: 4.2 (5 reviews)
Author: gabrielmoreira

File contents

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.

---name: validate-changesdescription: Evaluate staged changes using LLM-as-a-Judge before committing--- # 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.

Frequently asked questions

Validate Changes