Back to Skills

e2e-tests-studio

REQUIRED when modifying any file in packages/playground-ui or packages/playground. Triggers on: React component creation/modification/refactoring, UI changes, new playground features, bug fixes affecting studio UI. Generates Playwright E2E tests that validate PRODUCT BEHAVIOR, not just UI states.

26,920stars2,566forksUpdated 8/5/2026

Security Assessment

Safe(95/100)
Security Score95/100

About e2e-tests-studio

The e2e-tests-studio skill generates Playwright end-to-end tests for the Mastra studio playground UI, and is marked required whenever files in packages/playground-ui or packages/playground are modified. Its central principle is testing product behavior rather than UI states: tests must verify that features actually work (an LLM provider selection is used in the request payload, a created agent persists and appears in the list, a workflow executes tools in order) instead of merely asserting that a dropdown opens or a spinner shows.

It enforces a strict three-level BDD structure — an outer describe naming the unit under test, inner 'when …' describe blocks each expressing exactly one precondition, and each test asserting exactly one observable outcome — mirroring the project's MSW tests and its e2e-bdd lint rule. The skill walks through understanding feature intent (user problem, expected outcome, data flow, persistence, downstream effects), building and starting the playground kitchen-sink server, and mapping feature categories to behavior tests via a detailed table (agent configuration, LLM provider selection, tool execution, workflow execution, chat/streaming, MCP server tools, memory/persistence, error handling). It includes test-structure templates and patterns such as intercepting API routes to verify the selected provider is actually used. It requires the Playwright MCP server and pins the model to claude-opus-4-5.

It targets contributors to the Mastra codebase working on the playground/studio frontend. Use cases include validating new playground features, refactors, and bug fixes with behavior-focused e2e coverage that survives page reloads and checks real downstream effects rather than superficial rendering.

FAQ

What is the difference between testing behavior and UI state here?

UI-state tests assert things render (a modal appears, a sidebar collapses); behavior tests verify the feature works — e.g. selecting a provider is reflected in the API request, or a created agent persists and shows in the list after reload.

What BDD structure is required?

Exactly three levels: one outer describe naming the unit, inner test.describe('when …') blocks with exactly one precondition each (titles must start with 'when'), and each test asserting one observable outcome. No top-level flat test() is allowed.

What are the prerequisites?

The Playwright MCP server (added via 'claude mcp add playwright -- npx @playwright/mcp@latest' if browser_navigate is unavailable), and building/starting the playground kitchen-sink server, verified at http://localhost:4111.

When is this skill required?

Whenever any file in packages/playground-ui or packages/playground is modified — React component creation, modification, or refactoring, UI changes, new playground features, or bug fixes affecting the studio UI.

How do you verify configuration actually affects behavior?

Using patterns like page.route() to intercept the API call and assert the selected LLM provider appears in the request payload, rather than only checking that the selection UI updated.

Install e2e-tests-studio

Download and extract the skill files to your .claude/skills/ directory.

Quick Setup:

  1. Copy the skill folder to .claude/skills/
  2. Claude will automatically detect and use the skill