# Test Analyze

> Analyze test results and create a fix plan with subagents. Use when triaging failing tests, analyzing JUnit XML, planning fixes for accessibility/security, or categorizing flaky/E2E failures.

- Skill: `laurigates/test-analyze` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add laurigates/test-analyze`
- Raw SKILL.md: https://api.skillmd.com/api/skills/laurigates/test-analyze/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: laurigates (https://skillmd.com/u/laurigates)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/laurigates/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

| Use this skill when... | Use test-report instead when... |
|---|---|
| Triaging a directory of failing-test results into a fix plan | You only need a quick cached status read |
| Categorizing flaky, performance, accessibility, or security failures | Running the tests in the first place (use test-run) |
| Delegating fixes to specialized subagents | Asking strategic "how should we test X?" questions (use test-consult) |
| Producing a structured plan from JUnit XML or coverage output | Iterating on a single failing spec (use test-focus) |

## Usage

```bash
/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

```bash
# 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](#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`.

| Issue category | Triggers | Dispatch | Focus to pass |
|---|---|---|---|
| Accessibility violations | WCAG, ARIA, colour contrast, keyboard nav | `subagent_type: agents-plugin:review` | WCAG 2.1 compliance, semantic HTML, ARIA best practices |
| Security vulnerabilities | XSS, SQLi, CSRF, auth bypass | `subagent_type: agents-plugin:security-audit` | OWASP Top 10, input validation, authentication |
| Performance issues | Slow tests/queries, memory leaks, timeouts | `subagent_type: agents-plugin:performance` | Profiling, bottleneck identification, optimization |
| Code quality / smells | Duplication, complexity, coupling, maintainability | `subagent_type: agents-plugin:refactor` | SOLID principles, DRY, behaviour-preserving restructure |
| Flaky tests / test infrastructure | Race conditions, timing, shared state, isolation | `subagent_type: agents-plugin:test` | Test stability, isolation, determinism |
| Integration failures | Failing behaviour needing root-cause diagnosis | `subagent_type: agents-plugin:debug` | Root cause, minimal fix, verification |
| Build / CI failures | Pipeline errors, dependency issues | `subagent_type: agents-plugin:ci` | GitHub Actions, dependency management, caching |
| Documentation gaps | Missing docs, outdated examples | `subagent_type: agents-plugin:docs` | API docs, test documentation, migration guides |

## 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](#parameters)) —
they come from the **caller**, and nothing substitutes them for you:

| Value | Source | When absent |
|---|---|---|
| `<results-path>` | first non-flag token (required) | ask for it; do not guess a path |
| `<test-type>` | `--type <test-type>` | auto-detect from the result files' formats and content |
| `<focus-area>` | `--focus <area>` | analyze all areas with no prioritization bias |

**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.