Design test strategy using Beck's Test Desiderata — which properties matter, which tradeoffs to make. Use when the user asks "how should I test this", "what tests do I need", "review my test strategy", "is this well-tested", or when planning tests for a new feature or refactor.
Generate SOX sample selections, testing workpapers, and control assessments. Use when planning quarterly or annual SOX 404 testing, pulling a sample for a control (revenue, P2P, ITGC, close), building a testing workpaper template, or evaluating and classifying a control deficiency.
Steady7 mentions in 2 weeks
1 project uses a version of this
36k10mo agoReviewMountCreate a free account to mount
Testing Gloomberb at every level: CLI commands for fast data/integration checks, OpenTUI's built-in test harness for component tests, and tmux for full end-to-end terminal TUI testing. Use this skill when you need to verify terminal TUI features, write OpenTUI regression tests, or smoke-test the terminal app. Do not use it for Electrobun/desktop-web-only visual or window chrome work unless tmux/OpenTUI coverage is explicitly needed.
2.7k43d agoReviewMountCreate a free account to mount
Use when writing or updating Krayin CRM tests (unit or feature), debugging test failures, using datasets, mocks or custom expectations, writing architecture tests, or when the user mentions test, spec, TDD, expects, assertion, or coverage. Uses the Pest PHP framework (v3) with Laravel 12.
Test a change across the surfaces it touches, not only the path just written. Use when starting non-trivial implementation (claims, case grid, seams), when that work is built (attack the grid, keep few durable tests), when fixing a reported defect, and when judging an existing suite. Skip for one-line fixes with an obvious cause, copy or colour changes, and renames.
Which kind of test to write for which kind of change, and the helpers this repo gives you. Use when adding or changing an action, repository, screen, assistant behavior or database migration, or when a test fails.
Covers the testing pattern for every layer — domain (package:test with a hand-written Fake data provider, no mocktail), data (an ephemeral real instance or a mocked client), ui Cubit/BLoC (blocTest + mocktail against the domain repository), ui widgets (the pumpApp helper), and router tests (a fresh buildAppRouter() per test); triggers whenever a test is being written for a new entity, provider, repository, Cubit/BLoC, widget, or route.
Guides which automated tests are worth writing and how to write them well. Use when deciding whether code needs tests or when creating, modifying, or reviewing automated tests.
Unit, bloc, widget, and integration testing conventions — bloc_test, mocktail, http_mock_adapter, test naming, and what to test. Use when writing or fixing any test, mocking a dependency, or deciding what tests a change requires.
Use when writing tests, deciding what to test, reviewing test coverage, or verifying that a spec's acceptance criteria are actually covered. Also when a test is failing and the fix is unclear.
Coverage-driven, discovery-first product testing that operates a real app across risk-driven sessions and multi-session campaigns, maintains complementary product-surface and risk-dimension coverage, uncovers unreported bugs, and independently verifies fixes without changing production code. Use for Quick Exploration, Delta Discovery, systematic Full Discovery Campaigns, Final Broad Testing, Fix Verification / Regression after Builder implementation, Maestro-assisted flows, hardware/device coverage planning, or proactive testing beyond existing unit/UI suites.
Run, write, and debug tests — unit, integration, and end-to-end — in whatever framework the project already uses (Jest, Vitest, PHPUnit, Pytest, Go test, cargo test, RSpec, JUnit). Invoke when the user asks to test something, run the suite, add or fix tests, check coverage, or investigate a failing test. Skip when they want a code review rather than tests, or are asking how a test framework works in the abstract.
Stratégies de test, TDD, tests unitaires, d'intégration, E2E, et couverture de code. Use when writing or fixing unit, integration or E2E tests, choosing a test strategy, setting up TDD, mocks, fixtures or coverage, or when the user says test, tester, couverture, TDD, jest, vitest ou playwright.
Write comprehensive, maintainable tests following TDD and AAA pattern. Use when writing unit tests, integration tests, setting up fixtures, mocking dependencies, or improving test coverage. Covers Python (pytest), TypeScript (Jest), Go (testing), and Rust (built-in + proptest). Do NOT use for mutation testing specifics (use mutation-testing skill).
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.