
Test
- 484 installs
- 3.9k repo stars
- Updated January 26, 2026
- parcadei/continuous-claude-v3
test is a Claude Code testing workflow skill that runs diagnostics, parallel unit and integration tests, and E2E tests as a comprehensive pre-merge verification pipeline.
About
test is the /test comprehensive testing workflow skill from parcadei/continuous-claude-v3. It orchestrates a multi-stage pipeline: diagnostics for type checking, parallel arbiter runs for unit tests alongside integration tests, then atlas for end-to-end verification. Developers invoke it with phrases like run all tests, test the feature, verify everything works, or full test suite—typically before releases, merges, or after major changes. The parallel execution model reduces wall-clock time compared to sequential unit-then-integration runs. test consolidates scattered test commands into one agent-routed workflow so verification coverage spans type safety, isolated units, service integration, and browser or API E2E paths.
- test
Test by the numbers
- 484 all-time installs (skills.sh)
- +2 installs in the week ending Aug 4, 2026 (Skillselion tracking)
- Ranked #857 of 4,347 Backend & APIs skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/parcadei/continuous-claude-v3 --skill testAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 484 |
|---|---|
| repo stars | ★ 3.9k |
| Last updated | January 26, 2026 |
| Repository | parcadei/continuous-claude-v3 ↗ |
How do you run full test suite in parallel?
Use test for development tasks
Who is it for?
Developers preparing merges or releases who need diagnostics, unit, integration, and E2E coverage in one orchestrated run.
Skip if: Developers who only need a single failing test fixed or a quick smoke check without full suite orchestration.
When should I use this skill?
The user asks to run all tests, verify a feature end-to-end, or execute the full test suite before a merge or release.
What you get
Diagnostics type-check results, parallel unit and integration test reports, and E2E atlas test outcomes.
- unit test results
- integration test results
- E2E test report
Files
/test - Testing Workflow
Run comprehensive test suite with parallel execution.
When to Use
- "Run all tests"
- "Test the feature"
- "Verify everything works"
- "Full test suite"
- Before releases or merges
- After major changes
Workflow Overview
┌─────────────┐ ┌───────────┐
│ diagnostics │ ──▶ │ arbiter │ ─┐
│ (type check)│ │ (unit) │ │
└─────────────┘ └───────────┘ │
├──▶ ┌─────────┐
┌───────────┐ │ │ atlas │
│ arbiter │ ─┘ │ (e2e) │
│ (integ) │ └─────────┘
└───────────┘
Pre-flight Parallel Sequential
(~1 second) fast tests slow testsAgent Sequence
| # | Agent | Role | Execution |
|---|---|---|---|
| 1 | arbiter | Unit tests, type checks, linting | Parallel |
| 1 | arbiter | Integration tests | Parallel |
| 2 | atlas | E2E/acceptance tests | After 1 passes |
Why This Order?
1. Fast feedback: Unit tests fail fast 2. Parallel efficiency: No dependency between unit and integration 3. E2E gating: Only run slow E2E tests if faster tests pass
Execution
Phase 0: Pre-flight Diagnostics (NEW)
Before running tests, check for type errors - they often cause test failures:
tldr diagnostics . --project --format text 2>/dev/null | grep "^E " | head -10Why diagnostics first?
- Type check is instant (~1s), tests take longer
- Diagnostics show ROOT CAUSE, tests show symptoms
- "Expected int, got str" is clearer than "AttributeError at line 50"
- Catches errors in untested code paths
If errors found: Fix them BEFORE running tests. Type errors usually mean tests will fail anyway.
If clean: Proceed to Phase 1.
Phase 0.5: Change Impact (Optional)
For large test suites, find only affected tests:
tldr change-impact --session
# or for explicit files:
tldr change-impact src/changed_file.pyThis returns which tests to run based on what changed. Skip this for small projects or when you want full coverage.
Phase 1: Parallel Tests
# Run both in parallel
Task(
subagent_type="arbiter",
prompt="""
Run unit tests for: [SCOPE]
Include:
- Unit tests
- Type checking
- Linting
Report: Pass/fail count, failures detail
""",
run_in_background=true
)
Task(
subagent_type="arbiter",
prompt="""
Run integration tests for: [SCOPE]
Include:
- Integration tests
- API tests
- Database tests
Report: Pass/fail count, failures detail
""",
run_in_background=true
)
# Wait for both
[Check TaskOutput for both]Phase 2: E2E Tests (If Phase 1 Passes)
Task(
subagent_type="atlas",
prompt="""
Run E2E tests for: [SCOPE]
Include:
- End-to-end flows
- Acceptance tests
- UI tests if applicable
Report: Pass/fail count, screenshots on failure
"""
)Test Scopes
Full Suite
User: /test
→ All unit + integration + E2E testsFeature Scope
User: /test authentication
→ Only auth-related testsQuick Check
User: /test --quick
→ Only unit tests (skip integration and E2E)Example
User: /test the new payment feature
Claude: Starting /test workflow for payment feature...
Phase 0: Pre-flight diagnostics...
$ tldr diagnostics . --project --format text | grep "^E "
(no type errors found)
Phase 1: Running parallel tests...
┌─────────────────────────────────────────┐
│ arbiter: Running unit tests... │
│ arbiter: Running integration tests... │
└─────────────────────────────────────────┘
arbiter: ✅ 45/45 unit tests passing
arbiter: ✅ 12/12 integration tests passing
Phase 2: Running E2E tests...
atlas: ✅ 8/8 E2E tests passing
Test Summary:
┌─────────────┬─────────┬────────┐
│ Type │ Passed │ Failed │
├─────────────┼─────────┼────────┤
│ Unit │ 45 │ 0 │
│ Integration │ 12 │ 0 │
│ E2E │ 8 │ 0 │
├─────────────┼─────────┼────────┤
│ TOTAL │ 65 │ 0 │
└─────────────┴─────────┴────────┘
All tests passing! ✅Example with Type Errors
User: /test
Claude: Starting /test workflow...
Phase 0: Pre-flight diagnostics...
$ tldr diagnostics . --project --format text | grep "^E "
E src/payment.py:45:12: Argument of type 'str' not assignable to 'int'
E src/refund.py:23:8: Return type 'None' not assignable to 'float'
Found 2 type errors. Fixing before running tests...
[Claude fixes the type errors]
Re-running diagnostics... clean.
Phase 1: Running parallel tests...Failure Handling
If Phase 1 fails:
arbiter: ❌ 43/45 tests passing
2 failures:
- test_payment_validation: expected 'invalid' got 'valid'
- test_refund_calculation: off by $0.01
Stopping workflow. Fix failures before running E2E tests.Flags
--quick: Unit tests only--no-e2e: Skip E2E tests--coverage: Include coverage report--watch: Re-run on file changes
Related skills
FAQ
What stages does the /test workflow run?
The test skill runs diagnostics for type checking, then parallel arbiter unit and integration tests, followed by atlas E2E tests. Stages chain so type safety and isolated tests complete before end-to-end verification.
When should I use the test skill?
The test skill fits before releases or merges and after major changes when phrases like run all tests or full test suite appear. It consolidates diagnostics, unit, integration, and E2E into one comprehensive verification pass.