run-checks

Imported from tobywise/agent-skills (skills/run-checks/SKILL.md). Install upstream with npx skills add tobywise/agent-skills --skill run-checks. Copyright stays with the author.

Run checks

Choose the runner

Decide once per session, before the first check:

1. The project says. If the project's agent instructions (AGENTS.md or CLAUDE.md) name a runner — for example "checks in this repository run locally" — use it.
2. Otherwise, detect. Run command -v cbrun.
   • Found: this machine is a controller for remote Crabbox workers. Read references/crabbox.md in this skill's directory (~/.agents/skills/run-checks/references/crabbox.md) and follow it as well as the rules below. Never run tests, builds, type checks, installs, or other expensive commands directly on this machine.
   • Not found: run checks locally, as described below.

State which runner you chose and why in your first report of a check.

Local runner

• Run checks in the project's own locked environment, through its declared entrypoints: uv run --locked for a uv project (plain uv run can rewrite uv.lock), the project's make targets or scripts, and so on. Respect .python-version and requires-python.
• Project-locked setup is allowed, such as uv sync --locked. Never add, upgrade, or install unlocked dependencies to make a check pass.
• Keep checks bounded. Stop and ask the user to run an intensive scientific analysis themselves, giving the exact command and expected artifacts.
• Never run migrations, deployments, or anything that changes external systems as a check.

Always

• Batch related checks into one invocation, cheapest first, rather than separate runs per file or tool.
• Give long commands a generous timeout. A timeout or cancellation is not a test result.
• Report the exact command and its exit code. Distinguish a real test failure from an environment, setup, infrastructure, or timeout failure.
• Never rerun an unchanged failing check; rerun only after a relevant change.
• Retry an infrastructure failure only for idempotent checks: tests, linting, builds. Never automatically retry deployments, migrations, publishing, or other side-effecting commands.
• Let output stream normally; don't pipe long-running commands through head, tail, or grep unless necessary.