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 `for fork_skill in` loop inside `check_skill_body()` — cited by name, because a line number in that file drifts every time a regression guard is inserted) 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.