메뉴
Use when running, debugging, or extending the test suite — unit, integration, e2e, property, mutation, or flaky-test management
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when asked to implement an epic, a backlog of issues, or "/epic-implement N" — autonomous multi-agent execution of a GitHub epic's sub-issues, safe under a permission-bypassed session. Pass the epic number as the argument; if omitted, asks which open epic to run. A single issue goes to issue-implement.
Use when asked to implement a single GitHub issue end to end — "implement #171", "fix issue N", "pick up that bug" — where the deliverable is a reviewed PR. Epics and multi-issue backlogs go to epic-implement.
Use when capturing a feature, remediation, port/resurrection of old functionality, or any multi-issue program of work as a GitHub epic with sub-issues for later execution by separate agents — including when asked to "create an epic", "file this as issues", or "plan this so a lesser model can execute it". Single-issue-scale work (one bug/feature/chore) goes to issue-plan.
Use when capturing a single unit of work as a GitHub issue for later execution by a separate session — a bug found while debugging, a feature request, a chore, or a discovery out of scope for the current task. Triggers include "file an issue", "create an issue", "write this up as a bug". Multi-issue programs of work go to epic-plan.
Use when starting work in an unfamiliar module, when a module's `.context.md` is missing or stale, or when asked to document or understand a module's role
Use when restructuring existing code without changing behavior — extracting functions, splitting modules, or addressing tech debt and code smells
| name | test |
| description | Use when running, debugging, or extending the test suite — unit, integration, e2e, property, mutation, or flaky-test management |
| allowed-tools | Bash(make test:*), Bash(make test-quick:*), Bash(make test-coverage:*), Bash(make check:*) |
Tests are the specification. A green suite means the software does what was specified; a red one means either the spec changed or the code broke — both demand action.
For TDD itself (writing tests first, RED/GREEN/REFACTOR), use superpowers:test-driven-development. This skill is about running and analyzing.
See advanced.md for property-based, mutation, contract, and snapshot testing plus flaky-test management.
| Invocation | Command |
|---|---|
/test | make test (full suite) |
/test unit | make test-unit |
/test int or /test integration | make test-int |
/test e2e | make test-e2e |
/test [pattern] | runner with file/pattern argument |
/test mutation | mutation tests (see advanced.md) |
/test property | property-based tests |
/test flaky | identify and manage flaky tests |
/test watch | suggest the project's watch command |
Total: N Passed: N Failed: N Skipped: N Duration: Ns
For each failure:
| Runner | Watch |
|---|---|
| pytest | pytest-watch / ptw |
| vitest | vitest --watch |
| jest | jest --watch |
| cargo | cargo watch -x test |