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.
git clone --depth 1 https://github.com/louisbrulenaudet/monorepo-templateWrote 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/rules/louisbrulenaudet/monorepo-template/vitest-config)<a href="https://agentmods.dev/rules/louisbrulenaudet/monorepo-template/vitest-config"><img src="https://agentmods.dev/badge/rules/louisbrulenaudet/monorepo-template/vitest-config/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/rules/louisbrulenaudet/monorepo-template/vitest-config"><img src="https://agentmods.dev/badge/rules/louisbrulenaudet/monorepo-template/vitest-config.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.00000 | $0.00941 |
| Opus 5 | $0.00000 | $0.00470 |
| Sonnet 5 | $0.00000 | $0.00188 |
| Haiku 4.5 | $0.00000 | $0.00094 |
Grade A, and why
vitest-config 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 7d 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.
How it starts
The opening of the file, as written. The whole thing — 60 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Shared Vitest Config (@repo/vitest-config)
Factories for per-package Vitest configs. This monorepo follows Turborepo package-level caching, not root Vitest Projects: each app owns vitest.config and test / test:watch scripts; turbo run test parallelizes and caches.
Official alignment:
- Turborepo Vitest guide: prefer package tasks plus a shared config package over Vitest Projects for cache hits
- Vitest: workspace is deprecated in favor of projects; we still avoid root projects so Turbo owns the graph
- Vitest performance: Node uses pool threads and isolate false; Workers keep Cloudflare per-file isolation
- Vitest 4.1: leave reporters unset so AI_AGENT / std-env can select the agent reporter
General test authoring: vitest.mdc. Workers: hono-workers.mdc. Front: front-react.mdc. Package checklist: AGENTS.md.
Exports
| Import | For |
|---|---|
| @repo/vitest-config | defineNodeConfig, sharedTestDefaults, resolvePackageRoot for front-* |
| @repo/vitest-config/workers | defineWorkersConfig, resolvePackageRoot for worker-, queue-, webhook-, mcp- |
Two entry files on purpose: src/index.ts and src/workers.ts. Node apps must never resolve @cloudflare/vitest-plugin. Shared mock-hygiene defaults are intentionally duplicated across those files. Do not reintroduce a relative import between them. resolvePackageRoot lives in package-root.js and is re-exported from both.
Editing rules
Changing this package is a monorepo-wide breaking change.
- Keep the package config-tagged. Do not add a workspace dependency on @repo/typescript-config; config.dependencies.allow is empty.
- Stay JIT with source .ts exports. Do not add a build-to-dist step unless the monorepo moves off JIT configs.
- Do not set reporters in shared defaults. That breaks Vitest 4.1 auto agent detection and the GHA github-actions summary.
- Node factory only: environment node, pool threads, isolate false, experimental.fsModuleCache. Never attach cloudflareTest.
- Workers factory only: wrap cloudflareTest. Never set isolate false, a Node pool, or a custom environment or runner.
- Keep mock hygiene on: restoreMocks, clearMocks, unstubEnvs, unstubGlobals, passWithNoTests true. Include globs diverge on purpose: the Node factory matches tests//*.test.{ts,tsx} (component suites must never be silently skipped), the Workers factory stays tests//*.test.ts (no JSX inside workerd). Apps with suites override passWithNoTests to false so a glob mismatch fails loudly; the shared true keeps test-less packages green.
- Do not enable coverage, blob reporters, or sharding here without an explicit follow-up that wires Turbo outputs and a merge task.
- After changing factories, run pnpm turbo run test --filter=front-app --filter=worker-api.
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.
- 7d ago First seen · 60 lines · 0 tokens per session scan A b0bc0446fcdf
vitest-config is a cursor rule published in the GitHub repository louisbrulenaudet/monorepo-template (19 stars, last pushed 10d ago), licensed Apache-2.0. It costs nothing until one of its globs matches a file; then it loads 941 tokens. 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 cursor rules, from other repositories
android_unit_testing_bdd
Unit testing best practices with BDD style.
go
Idiomatic Go rules. Explicit error handling, interface-based design, context-first concurrency.
ci-cd
CI/CD pipeline patterns and deployment rules.
spec-for-ut
Unit testing is essential to ensure the reliability and stability of code, especially for React components and functions. Adhering to best practices and ensuring high test coverage is critical to maintaining a robust codebase.
testing
USE WHEN: Writing unit, integration, or component tests. Mandatory for logic in features.
rule-01
This is test rule number in the large package scalability test.