Chooses which tests a change needs, with one owning test per behavioral claim at the boundary where it is observable, and runs applicable quality checks. Use when changing behavior, writing tests, or reviewing test quality.
Power Platform Testing Strategy. Use when: writing unit tests, E2E tests, Vitest/Jest setup, Playwright, Canvas App testing, plugin testing with FakeXrmEasy, Solution Checker, accessibility testing with axe-core, CI/CD test integration.
Spec-first testing for this Next.js and vitest monorepo. Use when building a feature or fixing a bug test-first (TDD, red → green), when authoring or replacing a vitest suite over existing code, when a test is failing, or when judging whether coverage is real.
Repository-aware rules for choosing which tests a change needs, one owning test per claim, observable proof, and test integrity. Use when writing, reviewing, or fixing tests.
Software testing expertise for writing effective tests. Use when writing tests, reviewing test quality, designing test suites, debugging test failures, or implementing TDD. Covers xUnit patterns, test case selection, mocks/fixtures, parametrization, testing stateful systems, BDD, golden/snapshot testing, and LLM output evaluation.
Use for flaky or nondeterministic tests, especially local-vs-CI inconsistencies. Trigger on intermittent failures, race/timing symptoms, retry-only greens, or unexplained skip/xfail markers. Output should isolate reproducible cause, narrowest durable fix, and prevention guidance.
Universal testing framework (frontend + backend) — a meticulous run of any testing task with evidence discipline. Use when you need to test a feature/form/build/API/service, draft a test plan, run checks, perform exploratory or regression testing, or find defects.
Skill: Testing Strategy & Implementation
## Role
You are a Quality Assurance Architect and Testing Specialist.
## Objective
Design and implement a comprehensive testing strategy that focuses on behavior-driven integration tests
Write, review, and debug tests using Vitest. Use for: unit tests, API route tests, executor/serializer/tool tests, jsdom vs node environment selection, shared __test-utils__ patterns, and mandatory code-to-test sync with executed test runs.
When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program," or "experiment playbook." Use this whenever someone is comparing two approaches and wants to measure which performs better, or when they want to build a systematic experimentation practice. For tracking implementation, see analytics. For page-level conversion optimization, see cro.
A folder with a SKILL.md file: a name, a description of when to use it, and instructions. Claude loads a skill only when the task matches its description.
How do I use one I find here?
Copy the folder into your project's .claude/skills/ directory, or into your own skills folder to use it everywhere.
What do the warnings mean?
We read each file for commands that read secrets, delete things or pipe downloads into a shell, and say so before you copy it. No warning is not a promise that a file is safe.
Which skills worked for people?
Open a skill to see its discussion. Reports from people and their agents are coming.