Vitest
Install agent guidance for writing and reviewing Vitest suites with 44 prioritized rules across async, isolation, mocking, and organization.
Overview
Vitest is an agent skill most often used in Ship (also Build) that encodes 44 Vitest testing rules across 8 categories for AI-assisted test writing and review.
Install
npx skills add https://github.com/pproenca/dot-skills --skill vitestWhat is this skill?
- 44 rules across 8 categories, prioritized from critical async/isolation issues to incremental organization
- Critical async coverage: await assertions, act() with user events, return promises from tests, and async error handling
- Incorrect vs correct examples per rule for agent refactors and automated code review
- Optimized for AI-maintained codebases with explicit impact metrics on each rule
- 8 rule categories from async patterns through test organization
Adoption & trust: 1.1k installs on skills.sh; 157 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent writes Vitest tests that pass while assertions never run, flake on async UI updates, or ignore isolation and mocking pitfalls.
Who is it for?
Solo builders on Vite + Vitest stacks who want consistent agent output for unit and component tests.
Skip if: Teams standardizing on Jest without Vitest, or projects that only need Playwright-style end-to-end coverage with no unit layer.
When should I use this skill?
Maintaining, generating, or refactoring Vitest tests in AI-assisted workflows on Vite-based codebases.
What do I get? / Deliverables
Suites follow prioritized Vitest rules so async behavior, errors, and structure stay reliable in CI and local runs.
- Vitest tests aligned to prioritized rules
- Review notes mapped to rule categories
- Reduced flakiness from async and isolation fixes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Ship/testing is the canonical shelf because Vitest is invoked when you harden behavior before release, not when you are still scoping the idea. Testing subphase matches unit/integration suite work, flakiness fixes, and agent-generated test refactors.
Where it fits
Refactor a flaky payment-form spec so async assertions and returned promises align with Vitest’s event loop.
Generate new component tests that await user events and avoid act warnings.
Run agent review on a PR that adds mocks without resetting modules between files.
Tighten error-handling tests after production bug fixes land in the same module.
How it compares
Opinionated Vitest rule corpus for agents—not a test runner installer or a one-off snapshot generator skill.
Common Questions / FAQ
Who is vitest for?
Developers and agents maintaining Vitest projects who need repeatable guidance for async tests, React Testing Library act warnings, mocks, and suite layout.
When should I use vitest?
During Ship testing when adding or fixing suites, during Build frontend when scaffolding components with tests, or before release when CI flakiness spikes.
Is vitest safe to install?
It is documentation-style guidance without mandated shell exploits; still review the Security Audits panel on this Prism page and your repo’s skill install path.
SKILL.md
READMESKILL.md - Vitest
# Vitest **Version 1.0.0** community January 2026 > **Note:** > This document is mainly for agents and LLMs to follow when maintaining, > generating, or refactoring codebases. Humans may also find it useful, > but guidance here is optimized for automation and consistency by AI-assisted workflows. --- ## Abstract Comprehensive testing best practices guide for Vitest, designed for AI agents and LLMs. Contains 44 rules across 8 categories, prioritized by impact from critical (async patterns, test isolation) to incremental (test organization). Each rule includes detailed explanations, real-world examples comparing incorrect vs. correct implementations, and specific impact metrics to guide automated test writing and code review. --- ## Table of Contents 1. [Async Patterns](references/_sections.md#1-async-patterns) — **CRITICAL** - 1.1 [Await Async Assertions](references/async-await-assertions.md) — CRITICAL (Prevents false positives where tests pass despite failing assertions) - 1.2 [Await User Events to Avoid Act Warnings](references/async-act-wrapper.md) — CRITICAL (Prevents "not wrapped in act(...)" warnings and ensures UI updates complete) - 1.3 [Return Promises from Test Functions](references/async-return-promises.md) — CRITICAL (Prevents tests from completing before async operations finish) - 1.4 [Test Async Error Handling Properly](references/async-error-handling.md) — CRITICAL (Prevents tests from passing when async operations fail silently) - 1.5 [Use Fake Timers for Time-Dependent Code](references/async-fake-timers.md) — CRITICAL (Eliminates timer-based flaky tests and reduces test duration by 100×) - 1.6 [Use Test Context Expect in Concurrent Tests](references/async-concurrent-expect.md) — CRITICAL (Prevents snapshot collision and assertion cross-contamination in parallel tests) - 1.7 [Use vi.waitFor for Async Conditions](references/async-waitfor-polling.md) — CRITICAL (Replaces arbitrary timeouts with condition-based waiting, eliminating flaky tests) 2. [Test Setup & Isolation](references/_sections.md#2-test-setup-&-isolation) — **CRITICAL** - 2.1 [Avoid Shared Mutable State Between Tests](references/setup-avoid-shared-state.md) — CRITICAL (Eliminates order-dependent test failures and enables reliable parallel execution) - 2.2 [Clean Up State in afterEach Hooks](references/setup-beforeeach-cleanup.md) — CRITICAL (Prevents test pollution where one test's side effects cause subsequent tests to fail) - 2.3 [Reset Modules When Testing Module State](references/setup-reset-modules.md) — HIGH (Ensures modules with cached state are properly isolated between tests) - 2.4 [Restore Mocks After Each Test](references/setup-restore-mocks.md) — CRITICAL (Prevents mock leakage where mocked behavior persists into unrelated tests) - 2.5 [Use beforeAll for Expensive One-Time Setup](references/setup-beforeall-expensive.md) — HIGH (Reduces test suite time by 50-90% for tests with expensive setup) - 2.6 [Use Test Factories for Complex Test Data](references/setup-test-factories.md) — MEDIUM (Reduces test setup boilerplate by 60% and improves test readability) 3. [Mocking Patterns](references/_sections.md#3-mocking-patterns) — **HIGH** - 3.1 [Avoid Over-Mocking](references/mock-avoid-overmocking.md) — HIGH (Prevents tests that pass despite broken code by testing mocks instead of behavior) - 3.2 [Choose vi.spyOn vs vi.mock Appropriately](references/mock-spyon-vs-mock.md) — HIGH (Prevents over-mocking and ensures tests exercise real code paths) - 3.3 [Clear Mock State Between Tests](references/mock-clear-between-tests.md) — MEDIUM (Prevents call count and argument contamination between tests) - 3.4 [Maintain Type Safety in Mocks](references/mock-type-safety.md) — MEDIUM (Catches mock/implementation mismatches at compile time instead of runtime) - 3.5 [Understand vi.mock Hoisting Behavior](references/mock-vi-mock-hoisting.md) — HIGH (Prevents "module not mocked" errors and un