Testing
Unit tests, integration tests, test automation
user-input-protocol
by jwilger
Structured checkpoint format for requesting human input. When an agent needs a decision, it must stop, present context, show options, and wait. Activate when delegating to subagents, running background tasks, or hitting any decision point that requires human judgment.
bun
by mikkelkrogsholm
"Bun — fast all-in-one JavaScript/TypeScript runtime, package manager, bundler, and test runner. Use when building with Bun, running TypeScript, managing packages with bun install, writing tests with bun test, or asking about Bun APIs, configuration, or Node.js migration. Fetch live documentation for up-to-date API details."
github-actions
by 1Mangesh1
GitHub Actions CI/CD mastery for workflows, matrix builds, caching, secrets, and reusable actions. Use when user asks to "set up CI", "create a workflow", "add GitHub Actions", "matrix builds", "cache dependencies", "deploy with actions", "reusable workflows", or any CI/CD pipeline tasks.
gas-test-review
by whichguy
Review test plans and existing tests for GAS projects using the mocha/chai test framework. AUTOMATICALLY INVOKE when: - "review test", "test plan", "test coverage", "validate tests" - File patterns: .test.gs, .spec.gs, .test.html, .spec.html - After qa-analyst generates specs - Before committing test files to GAS projects NOT for: Testing the framework itself, general JS/TS tests (use code-reviewer)
makefile
by 1Mangesh1
Makefile patterns for project automation and build tasks. Use when user asks to "create Makefile", "add make target", "automate with make", "build commands", or set up project automation with GNU Make.
conflux-rust-integration-test
by conflux-fans
Create or update pytest-based integration tests for conflux-rust, including adding new test modules under integration_tests/tests, using ConfluxTestFramework and pytest fixtures (network, cw3/ew3, accounts, internal_contracts), customizing framework_class and fixtures, and running/debugging tests with pytest and xdist options.
go-unit-testing
by sentenz
Automates unit test creation for Go projects using the standard testing package with consistent software testing patterns including In-Got-Want, Table-Driven Testing, and AAA patterns. Use when creating, modifying, or reviewing unit tests, or when the user mentions unit tests, test coverage, or Go testing.
go-fuzz-testing
by sentenz
Automates fuzz test creation for Go projects using Go's native fuzzing engine with consistent software testing patterns. Use when creating fuzz tests, mutation testing, or when the user mentions fuzzing, coverage-guided testing, or property-based testing.
b1e55ed Operator Manual
by P-U-C
```
test-driven-development
by Crumbgrabber
Use when implementing any feature or bugfix, before writing implementation
tdd
by jwilger
Adaptive test-driven development cycle. Detects harness capabilities and routes to guided (manual phase control) or automated (orchestrated) mode. Invoke with /tdd for automated or /tdd red domain green commit for guided.
spec-driven-planning
by xbklairith
Use when planning new features or need structured requirements - creates feature structure, elicits EARS requirements through systematic questioning, proposes architectural approaches with trade-offs. Activates when user mentions "new feature", "requirements", "specs", "design", "architecture", or uses /dev-workflow:spec commands (create, requirements, design).
mutation-testing
by jwilger
Mutation testing to validate test quality before PR creation. Runs mutation tools, enforces 100% kill rate, reports surviving mutants with recommended fixes. Activate when validating test coverage, preparing pull requests, checking test quality, or when asked about mutation testing.
writing-plans
by jtsang4
Use when you have a spec or requirements for a multi-step task, before touching code
android-espresso-dependencies
by hitoshura25
Add Espresso and AndroidX Test dependencies to Android project
pentest-outbound-interaction-oob-detection
by crtvrffnrt
"Security assessment skill for outbound interaction and out-of-band (OOB) validation. Use when prompts include SSRF callback confirmation, blind XSS beacons, webhook abuse, XXE/OOB behavior, DNS/HTTP callback correlation, or asynchronous server-side interaction proof. Do not use when vulnerabilities are fully in-band and require no external callback correlation."
subagent-driven-development
by jtsang4
Use when executing implementation plans with independent tasks in the current session
my-web-plan
by ex3ndr
Planning for React web UI implementation with component design focus
go-testing
by MolcajeteAI
This skill should be used when writing, reviewing, or debugging Go tests. It covers table-driven tests, test organization, assertions, mocking patterns, coverage analysis, benchmarking, integration tests, race detection, and test quality standards.
Specification Creation Skill
by hitoshura25
Keep specs actionable, not academic.
android-test-structure
by hitoshura25
Create androidTest directory structure with base classes and utilities
debugging-protocol
by jwilger
Systematic 4-phase debugging: understand the failure, form hypotheses, test one change at a time, fix with confidence. Activate when tests fail unexpectedly, errors occur, behavior is wrong, or something that worked before is now broken. Triggers on: "debug", "why is this failing", "test failure", "unexpected error", "bug", "broken".
spec-driven-implementation
by xbklairith
Use when ready to implement designed features - breaks design into TDD tasks (Red-Green-Refactor), tracks progress with checkboxes in tasks.md, enforces strict testing discipline. Activates when user says "implement this", "let's code", "start execution", mentions "tasks", "TDD", or uses /dev-workflow:spec commands (tasks, execute).
brainstorming
by xbklairith
Use when exploring unclear requirements or architectural decisions - refines rough ideas into clear requirements/designs through collaborative questioning (one at a time), explores alternatives, validates incrementally. Activates when user has vague feature idea, mentions "not sure about", "exploring options", "what approach", or during spec-driven requirements/design phases.