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 | 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.
| name | repo-init |
|---|---|
| description | Interactive repo setup wizard. Use when: initializing a new repository, setting up project conventions, configuring dev tooling, choosing tech stack, setting up CI/CD, configuring AI tools. Guides user through structured questions covering repo structure (monorepo/polyrepo), tech stack (language, database, API, frontend, testing), AI tools (agents, methodology), and CI/CD (pipelines, IaC). Produces a reviewed summary and generates config files. |
| argument-hint | Optional: pass a specific section to jump to (repo-structure, tech-stack, ai-tools, ci-cd) |
| name | performance-test |
|---|---|
| description | Use when writing or reviewing performance tests that measure latency, throughput, resource utilisation, or scalability under load, and when asserting results against SLO thresholds as a pass/fail gate. |
A performance test measures non-functional properties — latency, throughput, concurrency capacity, resource consumption — under a defined load profile. Results are statistical; pass/fail is determined by comparison against an explicit SLO baseline, not exact values.
| 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.
| 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 | 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.