Test Analyze

Test Analysis and Fix Planning

Analyzes test results from any testing framework, uses Zen planner to create a systematic fix strategy, and delegates fixes to appropriate subagents.

When to Use This Skill

Usage

/test:analyze <results-path> [--type <test-type>] [--focus <area>]

Parameters

• <results-path>: Path to test results directory or file (required)

  • Examples: ./test-results/, ./coverage/, pytest-report.xml

• --type <test-type>: Type of tests (optional, auto-detected if omitted)

  • accessibility - Playwright a11y, axe-core
  • unit - Jest, pytest, cargo test
  • integration - API tests, database tests
  • e2e - Playwright, Cypress, Selenium
  • security - OWASP ZAP, Snyk, TruffleHog
  • performance - Lighthouse, k6, JMeter

• --focus <area>: Specific area to focus on (optional)

  • Examples: authentication, api, ui-components, database

Examples

# Analyze Playwright accessibility test results
/test:analyze ./test-results/ --type accessibility

# Analyze unit test failures with focus on auth
/test:analyze ./coverage/junit.xml --type unit --focus authentication

# Auto-detect test type and analyze all issues
/test:analyze ./test-output/

# Analyze security scan results
/test:analyze ./security-report.json --type security

Command Flow

1. Analyze Test Results

   • Parse test result files (XML, JSON, HTML, text)
   • Extract failures, errors, warnings
   • Categorize issues by type and severity
   • Identify patterns and root causes

2. Plan Fixes with PAL Planner

   • Use mcp__pal-mcp-server__planner for systematic planning
   • Break down complex fixes into actionable steps
   • Identify dependencies between fixes
   • Estimate effort and priority

3. Delegate to Subagents

   • Route each issue category through the Subagent Routing table below — it is the single source of truth for every subagent_type this skill dispatches.

4. Execute Plan

   • Sequential execution based on dependencies
   • Verification after each fix
   • Re-run tests to confirm resolution

Subagent Routing

This table is the single source of truth for delegation. Every subagent_type this skill dispatches is listed here; no other section restates it. The values are plugin-qualified plugin:agent IDs — the form the Task/Agent tool resolves for plugin-provided agents (a bare name only resolves for user- or project-level agents in ~/.claude/agents/ or .claude/agents/).

It is also the contract the workflow harness's category enum and AGENT_FOR map encode — edit them together. scripts/check-subagent-types.sh fails CI if any value here stops resolving to a real agents-plugin/agents/*.md.

Workflow harness (template)

workflows/test-analyze.workflow.js ships beside this skill. It is a TEMPLATE to adapt, not a script to run verbatim. Read it, then rewrite it for the work in front of you.

Adapt freely: the agent prompts, the severity vocabulary, the result-file globs and format hints for your test framework, the --focus weighting, and the verification command each plan agent is told to emit.

Preserve across any adaptation: (a) the fan-out width comes from the AGENT_FOR table above — one agent per agent type, never a prose "for each failure", which is what caps the harness at 8 concurrent agents; (b) the category and severity enums in RoutedFailuresSchema, which force every failure either onto a route or into unroutable[] with a stated reason instead of the nearest-looking row; (c) the parallel() barrier before Synthesize — group agents emit depends_on edges pointing at failures in other groups, so the ordering only exists once every group has returned.

Skip the harness when: there are fewer than 5 routable failures — the script returns {mode:'inline'} at that floor, because below it one opus agent per category costs more than the linear pass. That floor is a hard bound, not a tunable knob. The steps below remain the authoritative description of what each stage must produce; the harness only fixes how the work is split.

Two consequences worth stating inline:

• The harness surrenders mcp__pal-mcp-server__planner. A workflow script cannot reach MCP tools, so the dependency edges in the merged plan are inferred by the group agents, not planned. A run that genuinely needs PAL planning (Step 2 below) should stay inline.
• context: fork stays, and it is not what justifies the harness. The pin lives in scripts/plugin-compliance-check.sh (the context: fork guard list, currently around lines 898–914) and is unchanged by this template. Per .claude/rules/workflow-vs-skill.md § "The context: fork corollary", fork already bought context isolation for free — so this harness has to earn its tokens by splitting the planning work across agent types behind a real barrier, which it does. The parallel() width is capped at the fixed agent-type set (8) precisely so it does not become the wide fan-out .claude/rules/skill-fork-context.md warns about.

Output

The command produces:

1. Summary Report

   • Total issues found
   • Breakdown by category/severity
   • Top priorities

2. Fix Plan (from PAL planner)

   • Step-by-step remediation strategy
   • Dependency graph
   • Effort estimates

3. Subagent Assignments

   • Which agent handles which issues
   • Rationale for delegation
   • Execution order

4. Actionable Next Steps

   • Commands to run
   • Files to modify
   • Verification steps

Notes

• Works with any test framework that produces structured output
• Auto-detects common test result formats (JUnit XML, JSON, TAP)
• Preserves test evidence for debugging
• Can be chained with /git:smartcommit for automated fixes
• Respects TDD workflow (RED → GREEN → REFACTOR)

Related Commands

• /test:run - Run tests with framework detection
• /code:review - Manual code review for test files
• /docs:update - Update test documentation
• /git:smartcommit - Commit fixes with conventional messages

Prompt:

Analyze test results from <results-path> and create a systematic fix plan.

Bind the three values from $ARGUMENTS first (see Parameters) — they come from the caller, and nothing substitutes them for you:

Step 1: Analyze Test Results

Read the test result files from <results-path> and extract:

• Failed tests with error messages
• Warnings and deprecations
• Performance metrics (if available)
• Coverage gaps (if available)
• Categorize by: severity (critical/high/medium/low), type (functional/security/performance/accessibility)

Step 2: Use PAL Planner

Call mcp__pal-mcp-server__planner with model "gemini-2.5-pro" to create a systematic fix plan:

• Step 1: Summarize findings and identify root causes
• Step 2: Prioritize issues (impact × effort matrix)
• Step 3: Break down fixes into actionable tasks
• Step 4: Identify dependencies between fixes
• Step 5: Assign each fix category to appropriate subagent
• Continue planning steps as needed for complex scenarios

Step 3: Subagent Delegation Strategy

For each issue category found, look it up in the Subagent Routing table above and dispatch a Task with that row's subagent_type (a plugin-qualified plugin:agent ID) and that row's focus. Do not invent a subagent_type that is absent from the table — an unlisted value does not resolve and the dispatch fails.

Step 4: Create Execution Plan

For each subagent assignment:

1. Context: What files/areas need attention
2. Objective: Specific fix goal
3. Success Criteria: How to verify the fix
4. Dependencies: What must be done first
5. Verification: Commands to re-run tests

Step 5: Present Summary

Provide:

• 📊 Issue Breakdown: Count by category and severity
• 🎯 Priorities: Top 3-5 issues to fix first
• 🤖 Subagent Plan: Which agents will handle what
• ✅ Next Steps: Concrete actions to take
• 🔍 Verification: How to confirm fixes worked

When a <focus-area> was bound: prioritize issues related to that area and give the relevant subagents extra context about it. When none was passed, skip this — do not invent a focus.

Documentation-First Reminder: Before implementing fixes, research relevant documentation using context7 to verify:

• Test framework best practices
• Accessibility standards (WCAG 2.1)
• Security patterns (OWASP)
• Performance optimization techniques

TDD Workflow: Follow RED → GREEN → REFACTOR:

1. Verify tests fail (RED) ✓ (already done)
2. Implement minimal fix (GREEN)
3. Refactor for quality
4. Re-run tests to confirm

Proceed with the analysis and planning now — this skill runs context: fork and cannot wait for a reply. Present the completed Step 5 summary as the deliverable; the caller reviews the plan after the fact, not before it.