mcpField
P
piv-validate

piv-validate

github.com/coleam00Testing & quality722249 installsUpdated 3w ago
Repository

About piv-validate

piv-validate is a customizable skill template for running a project's checks and reporting one PASS/FAIL verdict. Teams replace its placeholder commands with their own tests, type checks, and lint or formatting checks.

Key features

  1. 01Run checks in sequence
  2. 02Continue after individual failures
  3. 03Report each check and overall verdict
  4. 04Include failed commands and relevant output
  5. 05Account for working directories and platforms

Use cases

  1. 01Check a project before a commit
  2. 02Create a single report for multiple code surfaces
  3. 03Identify failures across tests, types, and lint

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/coleam00/skills --skill piv-validate

After installing, type/piv-validatein Claude Code to confirm it loaded.

Details

From the project README

Validate

Run every check this project has and report a single PASS/FAIL verdict.

⚠️ Make this yours first

This skill is a template. The command list below is a placeholder — replace it with the commands your project actually uses. That is the entire point of a custom checker: it is the one skill that cannot be generic, because it wraps your stack's CLIs.

Find your real commands in package.json scripts, pyproject.toml, Makefile, justfile, docker-compose.yml, your CI workflow, or the README — then delete these and paste yours in.

Two things to get right, because they are the usual reason a checker silently lies:

  1. Working directory. Many tools only discover their config from the current directory. If your config lives in backend/pyproject.toml, the command is cd backend && uv run pytest, not uv run pytest from the repo root.
  2. Cross-platform. Avoid POSIX-only idioms if anyone on the team is on Windows — lsof, python3, and background-then-kill are the common offenders.

Run the checks in order. Keep going after a failure so the report covers everything, and capture the output of any command that fails.

1. Tests

# REPLACE: your test command, run from the right directory
<your test command>

Expected: all tests pass.

2. Type check

# REPLACE: e.g. mypy, tsc --noEmit, go vet
<your type-check command>

Expected: no type errors.

3. Lint / format check

# REPLACE: e.g. ruff check, biome check, eslint
<your lint command>

Expected: clean.

4. Repeat per surface

A full-stack project has more than one of each. Add a section per surface — backend tests, backend types, backend lint, frontend tests, frontend types, frontend lint — so a single command covers the whole repo.

5. Optional — live smoke test

Only when the change touches routing, middleware, or startup; skip it when your test suite already exercises the app in-process.

# REPLACE: start your app, hit one endpoint, confirm the status code, stop it
<your run command>

Prefer starting the server in a second shell over backgrounding and killing it from inside this skill — the background-and-kill idiom is not portable.

6. Summary report

Report each check with a ✅ or ❌, then an overall verdict:

  • One line per check
  • Overall: PASS or FAIL

For every ❌, include the failing command and the relevant output. Do not fix anything here — this skill reports; fixing is a separate step.

Notes

  • Keep this skill fast. It runs before every commit; if a step gets slow, that is a signal to fix the slow step, not to drop it from the checker.
  • A checker that cannot fail is worthless. Once your commands are wired in, break something on purpose and confirm this skill reports ❌.

Comments

Markdown supported