
test
Comprehensive testing workflow - unit tests ∥ integration tests → E2E tests
- Installs
- 501
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/parcadei/continuous-claude-v3 --skill test- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads test automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
/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 tests
Agent 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?
- Fast feedback: Unit tests fail fast
- Parallel efficiency: No dependency between unit and integration
- 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 -10
Why 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.py
This 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 tests
Feature Scope
User: /test authentication
→ Only auth-related tests
Quick 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
FAQ
What does the test skill do?
Comprehensive testing workflow - unit tests ∥ integration tests → E2E tests
How do I install test?
Run npx skills add https://github.com/parcadei/continuous-claude-v3 --skill test in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/test/ (personal) or .claude/skills/test/ (project).
Which AI agents can use test?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is test safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains test?
It is published by parcadei in parcadei/continuous-claude-v3. It has 501 recorded installs.
More from parcadei/continuous-claude-v3
discovery-interview
parcadei/continuous-claude-v3
Deep interview process to transform vague ideas into detailed specs. Works for technical and non-technical users.
premortem
parcadei/continuous-claude-v3
Identify failure modes before they occur using structured risk analysis
math
parcadei/continuous-claude-v3
Unified math capabilities - computation, solving, and explanation. I route to the right tool.
github-search
parcadei/continuous-claude-v3
Search GitHub code, repositories, issues, and PRs via MCP
dead-code
parcadei/continuous-claude-v3
Find unused functions and dead code in the codebase
refactor
parcadei/continuous-claude-v3
Code refactoring workflow - analyze → plan → implement → review → validate
Popular testing & qa skills
tdd
mattpocock/skills
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
grilling
mattpocock/skills
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
migrate-to-shoehorn
mattpocock/skills
Migrate test files from as type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace as in tests, or needs partial test data.
run-train
lllllllama/rigorpilot-skills
Rigor Train skill for deep learning research repositories. Use when a documented or selected training command should be run conservatively for startup verification, short-run verification, full kickoff, or resume, with command, config, seed, log, checkpoint, status, and metric evidence written to standardized trainoutputs/. Do not use for environment setup, exploratory sweeps, speculative idea implementation, or end-to-end orchestration.
test-driven-development
obra/superpowers
Use when implementing any feature or bugfix, before writing implementation code
finishing-a-development-branch
obra/superpowers
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work