Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add tobihagemann/turbo --skill run-checksgit clone --depth 1 https://github.com/tobihagemann/turboWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/tobihagemann/turbo/run-checks)<a href="https://agentmods.dev/skills/tobihagemann/turbo/run-checks"><img src="https://agentmods.dev/badge/skills/tobihagemann/turbo/run-checks/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/tobihagemann/turbo/run-checks"><img src="https://agentmods.dev/badge/skills/tobihagemann/turbo/run-checks.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00096 | $0.00616 |
| Opus 5.5 | $0.00038 | $0.00246 |
| Sonnet 5.5 | $0.00019 | $0.00123 |
| Haiku 4.5 | $0.00010 | $0.00062 |
Grade A, and why
run-checks scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 14d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
What it actually says
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. A check still running has no exit status: wait for every check to exit, one running in the background included, before reporting the gate or starting anything that follows it. 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. When a fix, or a tool resolving its own failure, edits the code while the gate is running, re-run every check whose passing run started before that edit. When the same edit keeps recurring across re-runs, stop and report the checks that produce it. 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.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 14d ago Changed 41b468fca198
- 20d ago Changed 63df739c9a13
- 26d ago Changed c0e040312066
- 28d ago Changed 6c95b3bfef65
- 1mo ago Changed bbdfc899dc47
- 1mo ago Changed a3241432df73
- 1mo ago First seen · 20 lines · 96 tokens per session scan A d76fe184d52e
run-checks is a skill published in the GitHub repository tobihagemann/turbo (416 stars, last pushed 3d ago), licensed MIT. It adds 96 tokens to every session and 616 once invoked, about $0.0004 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
test-first-bugfix
Test-driven bug fixing — reproduce before you fix. Use this skill whenever the user reports a bug, describes unexpected behavior, says something is broken, mentions a regression, or asks you to fix an error. This includes phrases like "this is broken", "X doesn't work", "there's a bug in", "getting an error when", "it…
debug-test-capture
Turns a finished debug session into permanent regression tests. Use right after a bug fix is verified or committed: after a post-fix regression trace comes back clean, after a trace-based debug workflow passes its final gate, or when the user says 'write tests for that fix', 'capture that as a test', 'add a regression…
test-orphan-guard
Detects and kills leftover or runaway node --test processes that pile up after a test run finishes or fails — the orphaned, CPU-pinned node processes that accumulate (often 10–15 at a time) until the machine bogs down or overheats. Use this skill whenever the user mentions leftover / zombie / orphan / stray node…
agent-harness-fault-injection
Use when an agent workflow needs deterministic recovery evidence for sandbox, MCP/tool, worker, checkpoint, memory, or orchestration failures.
agent-qa-debug-fix
Debug, patch, and verify failed Agent QA runs from MCP evidence, artifacts, logs, and local code without hiding product or infrastructure defects.
debug-failing-test
Debug a failing test using an iterative logging approach, then clean up and document the learning.