Finds complex business logic, edge cases, corner cases, and past regressions that lack tests, then writes the missing unit tests (and integration/E2E tests when the risk genuinely crosses a boundary) — enforcing Google's Testing on the Toilet best practices (real > fake > mock, don't mock types you don't own, verify state not queries, avoid change-detector tests, DAMP over DRY in tests, limit mocks per test). Use when asked to "add tests", "cover edge cases", "check test coverage", "write missing tests", "harden the tests", "test this properly", or "make sure this is tested".
Maintains IdeaVim test suite quality. Reviews disabled tests, ensures Neovim annotations are documented, and improves test readability. Use for periodic test maintenance.
When the user wants to plan, design, or implement an A/B test or experiment. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," or "hypothesis." For tracking implementation, see analytics-tracking.
Validate a commit-specific Next.js preview package and manually trigger the entire Next.js deployment test suite through the test_e2e_deploy_release.yml GitHub Actions workflow. Use only when asked to run the full deploy test suite or this workflow specifically from an internal vercel/next.js PR branch. Do not use for focused deployment-test sanity checks; run the relevant tests locally with pnpm test-deploy instead. Covers resolving the latest branch SHA, waiting for vercel-packages, preserving default workflow inputs, dispatching the workflow, and verifying the run.
Analyzes any web project and recommends a comprehensive testing strategy: what to test, which test type to use (unit, integration, component, E2E), how to prioritize coverage, and what mocking approach to follow. Can also generate tests based on its recommendations when the user asks. Use this skill when the user asks "what should I test", "create a testing strategy", "what tests does this project need", "analyze test coverage gaps", "which parts of my code need tests", "help me prioritize testing", "review my tests", "generate tests for this module", or any request to plan, evaluate, or create tests for a codebase. Also triggers when the user mentions testing pyramid, test coverage, TDD, test-driven development, or asks about the right type of test for a piece of code.
MANDATORY before creating, editing, or reviewing tests in agentic.nvim, and before behavior changes that require TDD. Covers mini.test workflow, red/green rules, commands, mark-count checks, and which test references to load.
Detects tests that pass by construction — tests that define a private copy of the function under test instead of importing the production module — and self-heals by extracting the inline logic to an exported function, updating production callers, and rewriting the test to import the export. Two checks: (1) static — the test file must import the SUT and must not shadow its exported names; (2) mutation — blanking the production function body re-runs the test and expects failure. Runs autonomously inside autonomous-workflow Phase 4 and as a slash command for human-driven PR review. Use when adding new tests for existing or refactored code, when CI is green but you are unsure whether the tests actually exercise production, or when reviewing a PR for tests-by-construction. Triggers on "test provenance", "tests by construction", "verify tests cover real code", "tests duplicate logic", "mutation sanity check", "are these tests fake", "/test-provenance-guard".
Analyzes test suites in any language and tags each test with a standardized set of traits (positive, negative, critical-path, boundary, smoke, regression, integration, performance, security). Use when the user wants to categorize, audit, or label tests with traits. Works with .NET (MSTest TestCategory / xUnit Trait / NUnit Category / TUnit Property), Python (pytest markers; unittest has no canonical tag syntax so report-only), TypeScript/JavaScript (Jest/Vitest test names, describe-block conventions), Java (JUnit 5 @Tag / TestNG groups), Go (subtest naming / build tags / file _test.go), Ruby (RSpec metadata), Rust (cargo test naming / cfg attributes), Swift (XCTest test plans / Swift Testing @Tag), Kotlin (JUnit @Tag / Kotest tags), PowerShell (Pester -Tag), C++ (GoogleTest filter prefixes / Catch2 [tags] / doctest decorators). Auto-edits when the framework has canonical syntax; falls back to report-only otherwise. Do not use for writing new tests, running tests, or migrating frameworks.
Smoke Testing Skill
Run pre-configured smoke tests for common user flows. Quick validation that critical functionality works.
## What is Smoke Testing?
Smoke testing is a quick sanity check
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.
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.
ariadossSkill
