Use when writing tests, deciding what to test, setting up test infrastructure, or reviewing test coverage. Also use when adding new commands or features that need test coverage.
Pre-push quality gates for the Pokédex project. Use before any git push, PR creation, or when verifying code changes pass all checks. Activates when running tests, linting, or formatting.
Language-agnostic testing, with Swift Testing and XCTest migration. Use for TDD, test strategy, regression and property-based tests, test doubles, legacy characterization, coverage, flaky suites, or migrating XCTest to @Test, #expect, and #require. For Swift concurrency test patterns, use `swift`; for running Apple builds and tests, use `xcode`.
Guides writing, reviewing, and improving software tests, including test selection, unit and integration testing, regression coverage, and test quality. Use when creating or evaluating tests for code.
Rules for tests that fail only when real behavior breaks: coverage, test doubles, naming, assertions, and testability. Use before writing or changing a test, when reviewing tests, when deciding what to test or whether to use a real object, fake, or mock, when a test is flaky, brittle, or breaks on every refactor, or when production code is hard to test.
Write, review, and audit tests for Flutter projects using Clean Architecture + Riverpod. Use when writing unit tests, widget tests, golden tests, reviewing test quality, checking test coverage, creating mocks/spies, or testing Riverpod providers.
Methodology and formats for test-case design and execution across the entire SSDLC. Code tests, logic, processes, specs, constraints. Domain-specific eval patterns: testing/eval_patterns/. Triggers when test cases must be designed or executed (build prepare test-design, fix verify); NOT for ad-hoc manual checks without a test plan.
Methodology and formats for test-case design and execution across the entire SSDLC. Code tests, logic, processes, specs, constraints. Domain-specific eval patterns: testing/eval_patterns/. Triggers when test cases must be designed or executed (build prepare test-design, fix verify); NOT for ad-hoc manual checks without a test plan.
Skill: Testing
## Description
Write, run, or fix tests for the Blog API using pytest and httpx.
## When to Use
Trigger this skill when the user says:
- "write tests", "add tests
Testing taxonomy: test purposes, levels, verification modes, and doubles. Use when choosing the kind of test, its boundary, or how to observe its subject.
Choose tests for their concrete regression value, avoid low-value coverage, and verify changes by exercising the real built behaviour. Use during implementation, fixes, planning, diagnosis, and code review when choosing verification, adding or changing tests, considering a missing-test finding, or when the user asks to test, check, or verify a change.
Use when about to write, add or change a test in any project — a unit, component, API or E2E test, a regression test for a bug, or tests for a change just made. Preloaded into code-writing agents (implementation and bugfix) so the authoring core is in context before the first test file is written. Fires on "write a test for", "add a regression test", "add tests for this change", "cover this with a test", "write a Playwright spec for". Not for: planning or auditing a suite, choosing which tests to run, fixtures, the E2E environment or the testing profile (/aidex:coverage); the RED-first bug-fix procedure (/aidex:bugfix).
This skill should be used when the user asks to "add an E2E test", "run live E2E", "run mock-LLM tests", "debug Playwright CI", "test the Docker image", or changes tests/e2e, Playwright configs, E2E workflows, artifacts, or test reporting.
Use when asked to test a microsoft/aspire pull request, including CLI, hosting, dashboard, component, template, and VS Code extension changes. Also covers testing PRs that change CI infrastructure — GitHub Actions (workflows, actions, gh-aw agentic workflows, CI scripts under .github/ and eng/) and Azure DevOps pipelines (eng/pipelines, eng/common).
Steady19 mentions in 2 weeks
1 project uses a version of this
6.4k5mo agoReviewMountCreate a free account to mount
Write, review and place automated tests that can fail. Use for writing, generating or reviewing tests, choosing a layer (unit, DOM, runtime-specific, end-to-end, benchmark), or rejecting a test that cannot fail. Covers Vitest and Playwright.
Use when writing tests, deciding on test coverage, choosing between unit/integration/E2E tests, applying TDD, or reviewing test quality — covers rigor tiers, the Red-Green-Refactor cycle, coverage requirements, and Playwright for UI testing.
测试与覆盖率:单元/集成/功能测试、TDD、回归测试、性质测试(Hypothesis/QuickCheck)、 mock 外部依赖、行覆盖率与 Codecov。Use when the user asks to write tests, raise coverage, or choose a testing approach. 触发于「写测试/提覆盖率/选测试策略」。
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.