Validate

⚠️ 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.

1. Tests

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

2. Type check

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

3. Lint / format check

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

4. Repeat per surface

5. Optional — live smoke test

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

6. Summary report

• One line per check
• Overall: PASS or FAIL

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 ❌.