What it does
/test runs your full test suite, reports results with coverage percentages per file, flags files below the 80% minimum threshold, and diagnoses failures systematically before attempting any fix.
When to use
Use/test to verify behavior after implementation, check coverage before shipping, or investigate test failures. It is also used as the verification step inside /implement.
Prerequisites
- A test framework configured in the project
- Dependencies installed
Conversation mode
Fast Mode — recommended for direct test execution.What happens
Run full test suite to establish baseline
The complete test suite runs first to capture the full picture before any analysis.
Report results
Results are reported as: total tests, passed, failed, skipped, and coverage % per file. For failures, exact error messages are shown — not summaries.
Flag coverage gaps
Files below 80% coverage are flagged. High-risk code (auth, payments, data mutations) is expected at 95%+.
Diagnose failures
On test failure, the
systematic-debugging skill is loaded to investigate root cause. The fix is never attempted without a diagnosis. For mass failures (>20 tests), the failure pattern is identified first — the root cause is fixed once rather than test-by-test.Skills invoked
test-driven-development— RED-GREEN-REFACTOR processsystematic-debugging— loaded on test failure to investigate root causeverification-before-completion— final check before declaring tests fixed
Coverage standards
80% is the minimum floor for shipping — it is not a target. Do not write tests purely to increase coverage numbers.| Code type | Minimum coverage |
|---|---|
| General code | 80% |
| Auth, payments, data mutations | 95%+ |
Example
Related commands
/implement
/test is embedded in the /implement workflow’s TDD cycle.
/build
Run /build after tests pass to verify the full production build.
/troubleshoot
For test failures that need the full four-phase debugging process.
/review
Review code quality and test coverage as part of the pre-ship checklist.