Test agents via subagents: known inputs, captured outputs, verification.
npx skills add https://github.com/notque/vexjoy-agent --skill testing-agents-with-subagents
This skill applies TDD methodology to agent development — RED (observe failures), GREEN (fix agent definition), REFACTOR (edge cases and robustness) — with subagent dispatch as the execution mechanism.
Test what the agent DOES, not what the prompt SAYS. Evidence-based verification only: capture exact outputs from subagent dispatch, verify every prompt change through testing. Always test via the Task tool, always test via the Task tool rather than reading prompts.
Minimum test counts vary by agent type: Reviewer agents need 6 cases (2 real issues, 2 clean, 1 edge, 1 ambiguous), Implementation agents 5 cases (2 typical, 1 complex, 1 minimal, 1 error), Analysis agents 4 cases (2 standard, 1 edge, 1 malformed), Routing/orchestration 4 cases (2 correct route, 1 ambiguous, 1 invalid). No agent is simple enough to skip testing — get human confirmation before exempting any agent.
Each test runs in a fresh subagent to avoid context pollution. After any fix, re-run ALL test cases to catch regressions. One fix at a time — you cannot determine what changed the outcome with multiple simultaneous fixes.
| Signal | Load These Files | Why |
|---|---|---|
| example-driven tasks, errors | examples-and-errors.md | Loads detailed guidance from examples-and-errors.md. |
| dispatch-and-capture, negative, consistency, A/B, and routing-verification test patterns | testing-patterns.md | Loads detailed guidance from testing-patterns.md. |
Goal: Read the agent definition and understand what it claims to do before writing tests.
Step 1: Read the agent file
# Read agent definition
cat agents/{agent-name}.md
# Read any referenced skills
cat skills/{skill-name}/SKILL.md
Step 2: Identify testable claims
Extract concrete, testable behaviors from the agent definition:
Step 3: Determine minimum test count
| Agent Type | Minimum Tests | Required Coverage |
|------------|---------------|-------------------|
| Reviewer agents | 6 | 2 real issues, 2 clean, 1 edge, 1 ambiguous |
| Implementation agents | 5 | 2 typical, 1 complex, 1 minimal, 1 error |
| Analysis agents | 4 | 2 standard, 1 edge, 1 malformed |
| Routing/orchestration | 4 | 2 correct route, 1 ambiguous, 1 invalid |
No gate — this phase is preparation. Move directly to Phase 1.
Goal: Run agent with test inputs and document exact current behavior before any changes.
Step 1: Define test plan
Write the test plan to a file before executing — this creates a reproducible baseline. See ${CLAUDE_SKILL_DIR}/references/examples-and-errors.md for the Test Plan template.
Step 2: Dispatch subagent with test inputs
Use the Task tool to dispatch the agent (see dispatch template in references/examples-and-errors.md). Each test runs in a fresh subagent — this prevents context pollution from earlier tests affecting later ones.
Step 3: Capture results verbatim
Document exact agent outputs. See the verbatim result capture template in references/examples-and-errors.md.
Step 4: Identify failure patterns
Gate: All test cases executed. Exact outputs captured verbatim. Failures documented with specific issues identified. Proceed only when gate passes.
Goal: Update agent definition until all test cases pass. One fix at a time.
Step 1: Prioritize failures
Triage failures by severity — see the Failure Severity table in ${CLAUDE_SKILL_DIR}/references/examples-and-errors.md (Critical/High/Medium/Low).
Step 2: Diagnose root cause
Map the failure type to a fix approach — see the Root Cause → Fix Approach table in references/examples-and-errors.md.
Step 3: Make one fix at a time
Change one thing in the agent definition. Re-run ALL test cases. Document which tests now pass/fail.
Make one fix at a time — you cannot determine which change was effective. Same debugging principle: one variable at a time.
Step 4: Iterate until green
Repeat Step 3 until all test cases pass. If a fix causes a previously passing test to fail, revert and try a different approach. Track fix iterations using the Fix Log template in references/examples-and-errors.md.
Gate: All test cases pass. No regressions from previously passing tests. Can explain what each fix changed and why. Proceed only when gate passes.
Goal: Verify agent handles boundary conditions and produces consistent outputs.
Step 1: Add edge case tests
See the Edge Case Categories table in ${CLAUDE_SKILL_DIR}/references/examples-and-errors.md (Empty / Large / Unusual / Ambiguous inputs).
Step 2: Run consistency tests
Run the same input 3 times. Outputs should be consistent:
If inconsistent: add more explicit instructions to the agent definition. Re-test.
Step 3: Run regression suite
Re-run ALL test cases (original + edge cases) to confirm nothing broke during refactoring.
Step 4: Document final test report
See the Test Report template in ${CLAUDE_SKILL_DIR}/references/examples-and-errors.md.
Gate: Edge cases handled. Consistency verified. Full suite green. Test report documented. Fix is complete.
See ${CLAUDE_SKILL_DIR}/references/examples-and-errors.md for error cases: agent-type-not-found, inconsistent-outputs, subagent-timeout, agent-asks-questions.
See ${CLAUDE_SKILL_DIR}/references/examples-and-errors.md for worked examples: testing a new reviewer agent, testing after agent modification, testing routing logic.
agent-comparison: A/B test agent variantsagent-evaluation: Structural quality checkstest-driven-development: TDD principles applied to agents${CLAUDE_SKILL_DIR}/references/testing-patterns.md: Dispatch patterns, test scenarios, eval harness integration${CLAUDE_SKILL_DIR}/references/examples-and-errors.md: Worked examples (new reviewer, modification, routing) and error handling (agent-not-found, inconsistency, timeout, question-asking)Multi-agent autonomous startup system for Claude Code. Triggers on "Loki Mode". Orchestrates 100+ specialized agents across engineering, QA, DevOps, security, data/ML, business operations, marketing, HR, and customer success. Takes PRD to fully deployed, revenue-generating product with zero human intervention. Features Task tool for subagent dispatch, parallel code review with 3 specialized reviewers, severity-based issue triage, distributed task queue with dead letter handling, automatic deployment to cloud providers, A/B testing, customer feedback loops, incident response, circuit breakers, and self-healing. Handles rate limits via distributed state checkpoints and auto-resume with exponential backoff. Requires --dangerously-skip-permissions flag.
Use when working with error debugging multi agent review
Build evaluation frameworks for agent systems. Use when testing agent performance systematically, validating context engineering choices, or measuring improvements over time.
Diagnoses and debugs A2A agent communication issues including agent status, message routing, transport connectivity, and log analysis. Use when agents aren't responding, messages aren't being delivered, routing is incorrect, or when debugging orchestrator, coder-agent, tester-agent communication problems.
Use when working with error debugging multi agent review
Rapidly creates atomic, focused skills optimized with evidence-based prompting, specialist agents, and systematic testing. Each micro-skill does one thing exceptionally well using self-consistency, program-of-thought, and plan-and-solve patterns. Enhanced with agent-creator principles and functionality-audit validation. Perfect for building composable workflow components.
Ultimate multi-agent framework for Google Antigravity. Orchestrates specialized domain agents (PM, Frontend, Backend, Mobile, QA, Debug) via Serena Memory.
This skill should be used when the user asks to "evaluate agent performance", "build test framework", "measure agent quality", "create evaluation rubrics", or mentions LLM-as-judge, multi-dimensional evaluation, agent testing, or quality gates for agent pipelines.
Take notque/testing-agents-with-subagents from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.