菜单
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.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/laurigates/claude-plugins --skill test-analyze命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Install, configure and troubleshoot MCP servers. Use when adding/enabling servers, editing .mcp.json, fixing OAuth, or when a server runs stale code after an upstream fix.
FinOps snapshot — org billing, workflow stats, cache usage. Use when you want a high-level view of CI spending or workflow health before diving deeper.
GitHub Actions billing, workflow efficiency, and waste analysis at org or repo level. Use when investigating CI/CD costs, wasted runs, or optimizing triggers.
正在显示 SKILL.md
| description | 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. |
| args | <results-path> [--type <test-type>] [--focus <area>] |
| argument-hint | Path to test results (e.g., ./test-results/), optional --type and --focus filters |
| allowed-tools | Task, Read, Glob, Grep, TodoWrite |
| created | "2025-12-16T00:00:00.000Z" |
| modified | "2026-08-08T00:00:00.000Z" |
| reviewed | "2026-08-08T00:00:00.000Z" |
| name | test-analyze |
| agent | general-purpose |
| context | fork |
Analyzes test results from any testing framework, uses Zen planner to create a systematic fix strategy, and delegates fixes to appropriate subagents.
| 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) |
/test:analyze <results-path> [--type <test-type>] [--focus <area>]
<results-path>: Path to test results directory or file (required)
./test-results/, ./coverage/, pytest-report.xml--type <test-type>: Type of tests (optional, auto-detected if omitted)
accessibility - Playwright a11y, axe-coreunit - Jest, pytest, cargo testintegration - API tests, database testse2e - Playwright, Cypress, Seleniumsecurity - OWASP ZAP, Snyk, TruffleHogperformance - Lighthouse, k6, JMeter--focus <area>: Specific area to focus on (optional)
authentication, api, ui-components, database# Analyze Playwright accessibility test results
/test:analyze ./test-results/ --type accessibility
# Analyze unit test failures with focus on auth
/test:analyze ./coverage/junit.xml -- unit --focus authentication
/test:analyze ./test-output/
/test:analyze ./security-report.json -- security
Analyze Test Results
Plan Fixes with PAL Planner
mcp__pal__planner for systematic planningDelegate to Subagents
subagent_type this skill dispatches.Execute Plan
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 |
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:
mcp__pal__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.The command produces:
Summary Report
Fix Plan (from PAL planner)
Subagent Assignments
Actionable Next Steps
/git:smartcommit for automated fixes/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 messagesPrompt:
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:
| 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:
Step 2: Use PAL Planner
Call mcp__pal__planner with model "gemini-2.5-pro" to create a systematic fix plan:
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:
Step 5: Present Summary
Provide:
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:
TDD Workflow: Follow RED → GREEN → REFACTOR:
Do you want me to proceed with the analysis and planning, or would you like to review the plan first?