home / skills / vishalsachdev / claude-skills / agentic-validators

agentic-validators skill

/agentic-validators

This skill helps ensure AI-generated code is automatically validated with per-file and repo-wide hooks, improving safety and determinism.

npx playbooks add skill vishalsachdev/claude-skills --skill agentic-validators

Review the files below or copy the command above to add this skill to your agents.

Files (3)
SKILL.md
3.5 KB
---
name: agentic-validators
description: Design and install validation hooks for coding agents (e.g., Claude Code) to make AI changes safer and more deterministic. Use when you want post-tool-use or stop hooks, automated tests/linters/formatters, parallel subagents with per-file validation, or a repeatable “agent pipeline” with audit logs.
license: MIT
metadata:
  author: Vishal Sachdev + Pip
  version: "0.1.0"
  tags: "agents hooks validation testing linting formatting ci"
compatibility: Works in repos on macOS/Linux with bash. Assumes a CLI coding agent that supports hooks (Claude Code-style) and common tooling (git, ripgrep, node/python toolchains).
---

# Agentic Validators

## Goal
Turn “agent wrote code” into “agent wrote code **and** the change is validated automatically.”

This skill helps you:
- choose the right validation strategy (per-file vs repo-wide)
- implement **post-tool-use** and **stop** hooks
- create **narrow validators** (fast, deterministic checks)
- structure work so multiple agents can run in parallel without losing correctness

## Mental model
- **Agents are non-deterministic; validators are deterministic.**
- **Context is fragile; validation + logs are durable.**
- Prefer **small, fast checks close to the change** (per-file) + a final **global gate** (repo-wide).

## When to use which hook
### Post-tool-use hook (best default)
Use when:
- you want immediate feedback after edits
- you can validate the specific file(s) that were touched
- you want high signal without running the full test suite

Typical checks:
- formatting (prettier/black)
- linting (eslint/ruff)
- typecheck for that file/module (tsc --noEmit with project config)

### Stop hook (end-of-run gate)
Use when:
- you need repo-wide invariants
- you want one last “exit criteria” check

Typical checks:
- unit tests
- build
- integration tests

## Step-by-step: add validators to a repo
1) Identify file types and fast checks
   - JS/TS: prettier + eslint + typecheck
   - Python: ruff + pytest (optional)
   - Go: gofmt + go test (optional)

2) Implement per-file validator(s)
   - A validator should be:
     - fast (<5–30s)
     - deterministic
     - clear output
     - safe to run repeatedly

3) Wire into hooks
   - Implement post-tool-use hook calling validator with the file path.

4) Add logs
   - Write to a predictable location (e.g., .agent-logs/validators.log)

5) Add a stop-hook “final gate”
   - Run the broader checks once.

## Example validator patterns
### Pattern A: “format + lint” for a touched file
- Format file
- Lint file
- If any change was made by formatter, fail and ask agent to re-run with formatter changes committed

### Pattern B: “contract test”
- For touched module, run a focused unit test subset

### Pattern C: “readme/docs invariant”
- If docs changed, run markdown lint + link checker

## Parallelism pattern
If you have many similar files (CSV, configs, docs):
- spawn one subagent per file
- each subagent runs its own post-tool-use validator
- aggregator agent only accepts results where validators passed

## Common failure modes & fixes
- **Validator too slow** → split into fast per-file checks + slower stop hook.
- **Validator flaky** → remove network calls, pin versions, add retries only where safe.
- **Agent ignores tool docs** → write a short “constitution” section and point to reference files.

## References
- See [Hook recipes](references/HOOK_RECIPES.md)
- See [Validator design checklist](references/VALIDATOR_CHECKLIST.md)

Overview

This skill designs and installs validation hooks for coding agents to make automated code changes safer and more deterministic. It helps you pick per-file vs repo-wide strategies, add post-tool-use and stop hooks, and structure parallel subagents with per-file validation and audit logs. The goal is to turn “agent wrote code” into “agent wrote code and the change is validated automatically.”

How this skill works

The skill implements small, deterministic validators that run immediately after an agent edits files (post-tool-use hooks) and a broader final gate (stop hook) that enforces repo-wide invariants. Validators are fast checks like formatters, linters, or focused tests; results are written to predictable logs and aggregated when many subagents run in parallel. Slow or flaky work is moved to the final gate while keeping per-file checks quick and repeatable.

When to use it

  • When you need immediate feedback on specific edited files
  • When you want deterministic, repeatable checks for agent-produced changes
  • When running parallel subagents that each validate their own file set
  • When you need a final repo-wide gate before merging or deploying
  • When you want audit logs of validator outcomes for traceability

Best practices

  • Prefer small, fast per-file validators (<5–30s) and reserve slow tasks for a stop hook
  • Make validators deterministic: avoid network calls and pin tool versions
  • Fail fast on formatter changes and require the agent to commit formatted output
  • Write clear, machine-parseable validator output and store logs in a predictable path (e.g., .agent-logs/)
  • Use a final global gate for unit tests, build, and integration tests only after per-file validators pass

Example use cases

  • Post-tool-use hook that runs black/ruff and typecheck on modified Python modules
  • Per-file format+lint pattern: auto-format, lint the file, and fail if formatting altered code
  • Parallel subagents: one subagent per CSV/config file, each validating its changes, with an aggregator accepting only passing results
  • Stop-hook final gate that runs the full test suite and build before accepting changes
  • Docs invariant validator: markdown lint and link checker for changed documentation files

FAQ

What should a per-file validator include?

Keep it minimal: formatter, linter, and a focused typecheck or unit test targeting the module changed.

How do I avoid flaky validators?

Remove network dependencies, pin tool versions, run tests in hermetic environments, and isolate unstable checks to the stop hook.