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 test-run-rulesgit 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/test-run-rules)<a href="https://agentmods.dev/skills/tobihagemann/turbo/test-run-rules"><img src="https://agentmods.dev/badge/skills/tobihagemann/turbo/test-run-rules/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/test-run-rules"><img src="https://agentmods.dev/badge/skills/tobihagemann/turbo/test-run-rules.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.00062 | $0.02590 |
| Opus 5.5 | $0.00025 | $0.01036 |
| Sonnet 5.5 | $0.00012 | $0.00518 |
| Haiku 4.5 | $0.00006 | $0.00259 |
Grade A, and why
test-run-rules 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 yesterday.
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.
How it starts
The opening of the file, as written. The whole thing — 61 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test Run Rules
Apply these rules for the rest of the test run, whether it drives the running app or runs a test target. A scenario they leave blocked could not be set up or run; one they leave inconclusive ran, but its result cannot be read.
Sandbox Denials
When a command failed on a sandbox denial, whether it starts or reaches infrastructure or is a scenario's own command, re-run it via the Bash tool (dangerouslyDisableSandbox: true) before treating the infrastructure as unavailable or recording the scenario as failed, blocked, or inconclusive.
Isolation
- Isolate shared process state so concurrent or subagent runs don't collide: bind dev servers and services to unique ports, scope tmux sessions (
tmux -L <name>), give each browser session a unique name so cleanup can target only its own, and write screenshots and other scratch state to absolute paths under a uniquely named subdirectory of the session scratchpad directory. Derive each such identifier once and reuse that exact value in every later command, writing it as a literal or reading it back from a note in that subdirectory. A value recomputed per shell, such as$$, differs between the command that creates a resource and the command that releases it, so cleanup releases something it never created and reports success while the real resource leaks. A port picked as unique may already be held by a concurrent agent, so check it before binding and move to another when it is taken, leaving the incumbent running. When a unique port moves a service off its default address, find the settings elsewhere in the stack that name that default, such as allowed origins and sign-in callback URLs, and bring each in line through runtime overrides, leaving the working tree unchanged: add the new address beside the default in a list, and replace the default only where no process outside this run reads the setting. - Reuse a running dev server only when this session started it and has not handed it to the user to try. Otherwise start one on a port this run selected and wait for it to be ready. Confirm it bound to that port before sending it traffic — a failed bind leaves another agent's service answering. Move to another port when the port is taken. When the start refuses to run because the project allows one dev server instance and one is already running, build and serve the project's production output with the configuration the dev server reads, on a port this run selected and confirmed bound the same way, and name that substitution in the result. A scenario that needs development-only behavior, or configuration the production output cannot be given, is then blocked: name what it needs. Report the error and stop when the server failed to start for any other reason.
- Treat state the app persists at a fixed path, such as a data file or a local database, as shared with every other live instance of the app. When another live instance is using it, give this run's instance a copy of its own under the run's scratch subdirectory: repoint the path there through runtime configuration, or, when the path cannot be repointed and the app resolves it relative to its own tree, run the instance from a copy of the working tree placed there, uncommitted changes included. Leave the working tree unchanged. When neither separates the state, every scenario that writes to it is blocked: name the path.
- Run each test runner this run starts in its own process group under a timeout enforced from outside the runner. Before reading an exit status as the runner's, confirm the runner ran: it printed its own output, or wrote a result artifact after this invocation started. An artifact left by an earlier invocation reads the same as a fresh one. When the runner did not run, fix the launch and rerun; the scenario is blocked when no fix starts it.
- Scope a screen capture or recording this run takes to the surface under test, addressed by its identifier, whenever the capture tool can. A capture of the whole display holds whatever else is open on it and can miss a surface that is covered or not in front.
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.
- yesterday Changed · +5 lines 13defa8e8572
- 5d ago Changed · +1 lines ca5950a0d58e
- 6d ago Changed 6ce4e13c01cd
- 9d ago Changed · +1 lines 60d4027fc701
- 11d ago Changed · +1 lines a404f4eec3c3
- 13d ago Changed · +1 lines d8e89ea21e23
- 16d ago Changed · +1 lines 15e297c619cc
- 20d ago First seen · 51 lines · 62 tokens per session scan A 0722a78551ec
test-run-rules is a skill published in the GitHub repository tobihagemann/turbo (414 stars, last pushed yesterday), licensed MIT. It adds 62 tokens to every session and 2,590 once invoked, about $0.0002 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-28.
Other skills, from other repositories
visual-qa
Use when verifying that a UI renders correctly. Covers visual regression testing, responsive checks across breakpoints, cross-browser verification, and screenshot-based review of an implementation against a design. Trigger on "does this match the figma", "set up screenshot tests", "layout breaks on mobile", "looks…
e2e-playwright
Use when writing end-to-end browser tests with Playwright. Covers resilient locators, auto-waiting, network interception, authentication reuse, parallelization, and eliminating flakiness. Trigger on "write playwright tests", "e2e test is flaky", "replace our cypress suite", "reuse login state in playwright". Do not…
test-strategy
Use when deciding what to test and at which level. Covers the test pyramid, what belongs in unit versus integration versus end-to-end tests, coverage as a signal rather than a target, and eliminating flakiness. Trigger on "what should we test", "our test suite is slow and flaky", "unit or integration test", "what…
web-app-testing
Use when testing a web application interactively — verifying a feature, reproducing a bug, or checking a flow in a real browser. Covers systematic exploration, console and network inspection, and reporting what you find. Trigger on "check this works in the browser", "reproduce this bug", "click through the signup…
test-writer
Write thorough tests following TDD and BDD principles.
security-regression-tests
Turning a confirmed and fixed finding into a permanent guard: proving the test fails without the fix, asserting the effect and not only the status code, seeding the two principals an authorization test needs, making a timing or out-of-band proof deterministic enough for CI, and keeping the test in a job that can…