run-checks
Run Checks
Build the gate by combining every source below that the project declares (sources 1-3); run the baseline (source 4) only when the project declares none of them. Passing the gate must mean the project's own checks (and CI, where it exists) pass.
- CI config — where present, it is the authoritative gate; run the checks it enforces.
- Check scripts — package-manager scripts (
check,verify,lint,typecheck,build), Makefile, Taskfile, or justfile targets, or a combined format+lint script. - Configured tools — any tool with a config committed to the repo, such as a dead-code or unused-dependency gate. A committed config means the project treats the tool as a gate; run it even when no script or CI invokes it. Do not run such a tool when the project has not configured it.
- Baseline — when the project declares nothing more, run the formatter, then the linter, then the build where the project produces one, then the test suite.
Run the formatter first so later checks see formatted code, then the rest. When a check fails on a sandbox denial, re-run it via the Bash tool (dangerouslyDisableSandbox: true) before diagnosing it or reporting it as not run. A check passes only when its command exits 0. Judge each run by its exit status and the runner's full summary, never by filtering the output for selected summary lines. Fix any failure the tools do not auto-resolve, then re-run each failed check and judge it by the re-run. For test failures, run the /investigate skill to diagnose the root cause, apply the suggested fix, and re-run; if investigation finds no root cause, stop and report with its findings.
State which sources the project declared, which checks ran, and each check's final exit status, so a narrower-than-intended gate or a failing check stays visible.
Then use the TaskList tool and proceed to any remaining task.