Msw
Install this skill when your agent should scaffold or refactor MSW v2 mocks with correct worker setup, handlers, and test lifecycle instead of brittle fetch stubs.
Overview
MSW is an agent skill most often used in Build (also Ship) that encodes 45+ Mock Service Worker v2 rules for correct API mocking setup, handlers, and test isolation.
Install
npx skills add https://github.com/pproenca/dot-skills --skill mswWhat is this skill?
- 45+ prioritized rules across 8 MSW v2 categories from setup through debugging
- CRITICAL guidance on committing the worker script, test lifecycle hooks, and unhandled-request policy
- TypeScript 4.7+ and handler-architecture patterns with incorrect vs correct examples
- Team and CI-friendly setup that reduces flaky tests and handler leakage
- Automation-oriented rule doc for agents maintaining or generating mock layers
- 45+ rules across 8 categories
- 8 rule categories from setup through debugging
Adoption & trust: 518 installs on skills.sh; 157 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need realistic API behavior in dev and tests but ad-hoc mocks leak state, break CI, and miss unhandled requests.
Who is it for?
Solo builders shipping SPAs or full-stack apps who want agents to apply MSW v2 consistently across dev and test targets.
Skip if: Teams that only need a one-line fetch stub for a single test with no shared worker or no intention to run MSW in the browser or Node test runner.
When should I use this skill?
Maintaining, generating, or refactoring codebases that use Mock Service Worker v2 for API mocking in dev or tests.
What do I get? / Deliverables
Your repo gets MSW v2 patterns for worker setup, handlers, and test hooks so clients and tests share dependable mocks without a live API.
- MSW worker and handler layout
- Test setup with lifecycle hooks
- Unhandled-request policy aligned with CI
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
API mocking is first needed while wiring clients and backends during product construction, before full environments exist. Integrations is the canonical shelf because MSW sits at the HTTP boundary between UI/clients and APIs.
Where it fits
Mock checkout and auth endpoints while building UI before the backend is deployed.
Generate shared handler modules that mirror OpenAPI contracts for multiple clients.
Configure server.resetHandlers and lifecycle hooks so parallel tests stay isolated.
Replay production-like error payloads in mocks when reproducing a reported API regression locally.
How it compares
Use as a structured skill playbook instead of copying random MSW snippets from Stack Overflow or chat.
Common Questions / FAQ
Who is msw for?
Solo and indie developers and their coding agents who maintain frontends or full-stack apps and rely on Mock Service Worker for local and CI API simulation.
When should I use msw?
During Build when wiring API clients and integration mocks, and during Ship when configuring test runners and preventing flaky handler leakage; also when upgrading an older MSW setup to v2 or fixing unhandled-request failures in CI.
Is msw safe to install?
Treat it as procedural documentation for your agent; review the Security Audits panel on this Prism page and skim generated mock code before merging, especially around network and filesystem worker paths.
SKILL.md
READMESKILL.md - Msw
# MSW (Mock Service Worker) **Version 1.0.0** mswjs 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 API mocking guide for MSW v2 applications, designed for AI agents and LLMs. Contains 45+ rules across 8 categories, prioritized by impact from critical (setup, handler architecture) to incremental (debugging). Each rule includes detailed explanations, real-world examples comparing incorrect vs. correct implementations, and specific impact metrics to guide automated refactoring and code generation. --- ## Table of Contents 1. [Setup & Initialization](references/_sections.md#1-setup-&-initialization) — **CRITICAL** - 1.1 [Commit Worker Script to Version Control](references/setup-worker-script-commit.md) — CRITICAL (Eliminates setup friction for team members; prevents CI failures) - 1.2 [Configure Server Lifecycle in Test Setup](references/setup-lifecycle-hooks.md) — CRITICAL (Prevents handler leakage and ensures test isolation; eliminates flaky tests) - 1.3 [Configure TypeScript for MSW v2](references/setup-typescript-config.md) — CRITICAL (TypeScript 4.7+ required; incorrect config causes type errors) - 1.4 [Configure Unhandled Request Behavior](references/setup-unhandled-requests.md) — CRITICAL (Catches missing handlers immediately; prevents silent test failures) - 1.5 [Require Node.js 18+ for MSW v2](references/setup-node-version.md) — CRITICAL (MSW v2 requires Node 18+; older versions cause complete failure) - 1.6 [Use Correct Entrypoint for Node.js](references/setup-server-node-entrypoint.md) — CRITICAL (Zero mocking if wrong entrypoint; 100% test failures) 2. [Handler Architecture](references/_sections.md#2-handler-architecture) — **CRITICAL** - 2.1 [Define Happy Path Handlers as Baseline](references/handler-happy-path-first.md) — CRITICAL (Establishes reliable baseline; enables clean runtime overrides) - 2.2 [Destructure Resolver Arguments Correctly](references/handler-resolver-argument.md) — CRITICAL (Wrong destructuring pattern causes undefined values; silent failures) - 2.3 [Explicitly Parse Request Bodies](references/handler-request-body-parsing.md) — CRITICAL (v2 no longer auto-parses bodies; missing parsing returns undefined) - 2.4 [Extract Shared Response Logic into Resolvers](references/handler-shared-resolvers.md) — CRITICAL (Eliminates duplication; ensures consistent mock responses across tests) - 2.5 [Group Handlers by Domain](references/handler-domain-grouping.md) — CRITICAL (Reduces maintenance overhead; scales to large APIs without N×M complexity) - 2.6 [Share Handlers Across Environments](references/handler-reusability-environments.md) — CRITICAL (Single source of truth; eliminates mock drift between dev/test) - 2.7 [Use Absolute URLs in Handlers](references/handler-absolute-urls.md) — CRITICAL (Prevents URL mismatch failures; required for Node.js environments) - 2.8 [Use MSW v2 Response Syntax](references/handler-v2-response-syntax.md) — CRITICAL (v1 syntax breaks in v2; causes complete handler failure) 3. [Test Integration](references/_sections.md#3-test-integration) — **HIGH** - 3.1 [Avoid Direct Request Assertions](references/test-avoid-request-assertions.md) — HIGH (Tests implementation details; breaks on refactors that preserve behavior) - 3.2 [Clear Request Library Caches Between Tests](references/test-clear-request-cache.md) — HIGH (Prevents stale cached responses; ensures fresh mock data per test) - 3.3 [Configure Fake Timers to Preserve queueMicrotask](references/test-fake-timers-config.md) — HIGH (Prevents request body parsing from hanging indefinitely) - 3.4 [Reset Handlers After Each Test](references/test-reset-handlers.md) — HIGH (Prevents handler pollution; eliminates test order depend