| name | unit-test |
|---|---|
| description | Use when writing or reviewing unit tests that test a single function, class, or module in isolation with all external dependencies replaced by test doubles. |
A unit test verifies the behaviour of one unit (function, class, or module) in complete isolation. Every dependency that crosses an architectural boundary is replaced by a test double. Speed and determinism are non-negotiable.
An agent role for coordinating incident response across multiple specialists.
You are the Incident Commander for a production incident. Your job is to coordinate the response, ensure information flows between specialists, and maintain a clear picture of incident status.
An agent role for coordinating incident response across multiple specialists.
You are the Incident Commander for a production incident. Your job is to coordinate the response, ensure information flows between specialists, and maintain a clear picture of incident status.
| name | ai-config |
|---|---|
| description | Manage AI assistant config files across tools. USE FOR: initializing AI configs for a new repo (AGENTS.md, CLAUDE.md, copilot-instructions.md, .cursorrules, GEMINI.md, etc.); adding a config for a newly adopted AI tool; detecting drift between multiple co-existing AI config files; updating preferences across all active configs; detecting when tooling changes (linter, framework, test runner) are not yet reflected in AI configs. Triggers on: 'set up AI configs', 'add Cursor config', 'my copilot instructions are out of date', 'sync my AI configs', 'check if my AI configs match the stack', 'onboard Claude Code'. |
| argument-hint | Optional: pass a mode to skip detection — init | add <tool> | check | edit | drift |
---
name: auto-test
description: Use when writing, reviewing, or diagnosing any automated test regardless of scope or framework. Triggers on: writing new tests, reviewing test quality, identifying test smells, naming tests, structuring test suites, or deciding which scope skill to apply.
---
Core principles that apply to every automated test regardless of scope (unit, integration, e2e, contract, performance) or framework. Scope skills extend these; they do not replace them.
| name | contract-test |
|---|---|
| description | Use when writing or reviewing contract tests that verify the agreement between a service consumer and a service provider, including consumer-driven contracts, schema validation, and provider verification. |
A contract test verifies the agreement between a consumer and a provider — not their internal behaviour. The consumer defines what it expects from the provider; the provider verifies it can meet those expectations. Contract testing is a design discipline as much as a testing technique.
| name | e2e-test |
|---|---|
| description | Use when writing or reviewing end-to-end tests that verify observable user-facing behaviour through the full stack with no mocks, covering browser flows, API journeys, or CLI interactions against a real or production-equivalent environment. |
An end-to-end test verifies that a complete user-facing flow works correctly through the full stack. Nothing is mocked. The test interacts with the system the same way a real user or client would and asserts on observable outcomes.
| name | integration-test |
|---|---|
| description | Use when writing or reviewing tests that verify a real integration boundary such as database queries, message queue interactions, external service calls, or inter-module wiring where real infrastructure is intentional. |
An integration test verifies that two or more components work correctly when wired together through a real boundary — a database, queue, HTTP client, or file system. The use of real infrastructure is intentional; that is what distinguishes it from a unit test.