| name | sanctify |
| description | Run the project's checks (typecheck, tests, lint, build) and report results. |
Run this project's own quality checks (or the subset named in $ARGUMENTS) and report
exactly what passed, what failed, and the single most useful thing to do next.
1. Detect the toolchain
Find the checks this project actually defines; never invent commands:
- Node: read
package.json scripts for typecheck/tsc, test, lint, build.
Pick the runner from the lockfile present: pnpm-lock.yaml → pnpm, yarn.lock →
yarn, otherwise package-lock.json → npm.
- Make: a
Makefile with targets like test, lint, check.
- Other languages:
cargo test/cargo clippy/cargo build, go test ./.../go vet,
pytest plus ruff/mypy, or the equivalent the repo is set up for.
If $ARGUMENTS names a subset (e.g. "just tests", "lint"), run only that. Otherwise run
the full relevant set. State which checks you found in one line before running.
2. Run each available check
Run them in cheap-to-expensive order (typecheck, lint, tests, then build only if it is
quick). For each:
- Capture exit code and output.
- A non-zero exit (or a runner's own failure summary) is a FAIL.
- If a check isn't defined in the project, skip it and say so; don't substitute your own.
3. Report results
One clear line per check:
PASS: typecheck (tsc)FAIL: tests (3 failing)
For each failure, excerpt the actual failing output (the assertion, the error, the
offending lines), not the whole log. Point to the path:line involved as a clickable
reference so the user can jump straight there.
4. Verdict and next step
End with a one-line verdict (all green, or N checks failing) and the single most useful
next action (e.g. "fix the type error in src/api.ts:42, then re-run", or "all checks
pass, ready to commit").
This command is read-only apart from running the checks. Do not fix, edit, or commit
anything unless the user explicitly asks; report the failures and stop.
