playwright-trace-analyzer
Skill20 starsChanged 13 days agoMITView on GitHub
Analyzes Playwright `trace.zip` archives (or a GitHub Actions run URL) — action timeline, network, console errors — to name the race behind a flake and rank test or app fixes by measured impact. Invoke with /playwright-trace-analyzer for "why is this test flaky" or "why did playwright time out".
In this repository48 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- skills/workflow/autonomous-workflow/CLAUDE.mdCLAUDE.md
- ideateSkill
- interviewSkill
- profile-optimizerSkill
- rum-trackingSkill
- screencastSkill
- video-analyserSkill
- youtube-transcriptSkill
- create-skillSkill
- docsSkill
- handoffSkill
- optimize-claude-mdSkill
- persistent-memorySkill
- attach-mediaSkill
- ci-auto-fixSkill
- create-prSkill
- github-actions-authorSkill
- resolve-conflictsSkill
- animations-nativeSkill
- animationsSkill
- behavioral-designSkill
- chartingSkill
- storybookSkill
- uxSkill
- visual-designSkill
- ai-engineeringSkill
- confidenceSkill
- criticalSkill
- impact-mapSkill
- jev-assertSkill
- measurableSkill
- optimize-approachSkill
- polishSkill
- pr-reviewSkill
- review-loopSkill
- tddSkill
- verify-behaviorSkill
- aw-verifySkill
- e2e-testing-mobileSkill
- e2e-testingSkill
- telemetry-verifySkill
- ui-verifySkill
- autonomous-workflowSkill
- aw-create-planSkill
- aw-create-walkthroughSkill
- fix-bugSkill
- implement-suggestionSkill
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 1 is distinctive, and 8 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 55
If the user passes a report.json plus a trace.zip, treat the report as a high-level test status map and the trace as the source of truth …
- Very specific: line 59
If a test-results/ directory is passed, scan for the most recent trace.zip per failed test and process them in order of failure recency.
- Very specific: line 102
After the first pass at root-cause analysis, invoke the confidence skill in analysis mode:
- Very specific: line 117
After two deep-dive iterations without reaching 90%, stop and present findings as a hypothesis with the evidence required to confirm it.
- Very specific: line 125
Measure before recommending: Every fix must be tied to a number from the trace.
- Distinctive: line 134
Auto-detect, do not interrogate: Read the file shape, infer the format, state what you found.
- Very specific: line 137
Confidence-gated honesty: If /confidence returns < 90%, dig deeper or admit uncertainty.
- Very specific: line 178
If gh is not installed or unauthenticated, ask the user to download the trace artifact manually from the Actions run page and provide the …
- Very specific: line 205
Map suspects to source: Use rules/flake-diagnosis.md Phases 3–4 to go from action callId → test file/line (Playwright trace events embed …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Playwright Trace Analyzer
Turn a Playwright trace.zip into a ranked, evidence-backed report of
flakes, slow steps, and root causes.
Index file. Detailed extraction rules, analysis playbooks, and report templates live under
rules/,references/, andtemplates/. Load only what the current phase needs — the body ofSKILL.mdis a thin orchestrator.
Inputs
The user passes one or more of:
| Input | Detection signal |
| GitHub Actions run URL | Matches https://github.com/<owner>/<repo>/actions/runs/<id> — fetch artifacts via gh run download |
trace.zip archive | Magic bytes 50 4b 03 04; entries include trace.trace, trace.network, *.png, resources/ |
| Unpacked trace directory | Contains trace.trace + trace.network (NDJSON) and a resources/ subdir |
Single trace.trace JSONL stream | NDJSON; each line has type, callId, startTime, params (e.g. before, action, after) |
Single trace.network JSONL stream | NDJSON; entries with type: "resource-snapshot" or requestEvent / responseEvent |
report.json (Playwright reporter) | Top-level config, suites, stats; complementary, never authoritative for timing |
If the user passes a report.json plus a trace.zip, treat the report as
a high-level test status map and the trace as the source of truth for
timing and network data.
If a test-results/ directory is passed, scan for the most recent
trace.zip per failed test and process them in order of failure recency.
See rules/input-detection.md for the
precise detection logic and unpack recipe.
Workflow
Six phases. Do not skip a gate.
| Phase | Name | Rule file | Gate |
| 0 | Intake | rules/input-detection.md | Format detected, archive unpacked, trace.trace + trace.network parseable |
| 1 | Measurement frame | rules/measurement-methodology.md | Failure mode named (timeout, assertion, error, slow-but-passing) and primary metric chosen (action ms, total wall-clock, request count) |
| 2 | Hotspot extraction | rules/action-timing.md, rules/network-analysis.md, rules/console-and-errors.md | Top-N slow actions, top-N slow requests, error/console list — all with concrete numbers |
| 3 | Root-cause | rules/flake-diagnosis.md | Each hotspot mapped to a code-level cause (selector, locator, network call, app event) with file path or line where possible |
| 4 | Confidence gate | rules/confidence-loop.md | /confidence analysis ≥ 90% — else iterate (max 2 deep-dives) |
| 5 | Fix plan | templates/analysis-report.md | Report written with ranked fixes, expected impact, and verification plan |
Required reading by phase
Load on demand — do not preload.
| Phase | Files |
| 0 | rules/input-detection.md — also points to scripts/trace-extract.mjs |
| 1 | rules/measurement-methodology.md |
| 2 | rules/action-timing.md, rules/network-analysis.md, rules/console-and-errors.md — backed by scripts/trace-summary.mjs |
| 3 | rules/flake-diagnosis.md, references/flake-patterns.md, references/performance-patterns.md |
| 4 | rules/confidence-loop.md |
| 5 | templates/analysis-report.md |
Pass-vs-fail comparison (when given two traces of the same test):
scripts/trace-diff.mjs.
Confidence-gated iteration
After the first pass at root-cause analysis, invoke the confidence skill
in analysis mode:
Skill(skill="confidence", args="analysis")Apply this gate:
| Score | Action |
| ≥ 90% | Proceed to Phase 5 (fix plan). |
| 70–89% | Run one deeper pass: re-read the trace, expand the action's before/after snapshots, correlate with network. |
| < 70% | Surface the gap to the user with a question — do not propose changes on speculation. |
After two deep-dive iterations without reaching 90%, stop and present
findings as a hypothesis with the evidence required to confirm it. See
rules/confidence-loop.md.
Core principles
- Measure before recommending. Every fix must be tied to a number
from the trace. "This selector is slow" is not a finding; "
page.click('text=Save')waited 4,820ms across 3 attempts before the button became actionable" is. - Distinguish symptom from cause. A timeout is the symptom; the
reason the wait never resolved is the cause. The trace records the
beforeandafterDOM snapshots and every poll attempt — read them. - Rank by impact, not by ease. A 50ms selector fix that runs once
matters less than a 200ms wait that runs in
beforeEachof 40 tests. - Auto-detect, do not interrogate. Read the file shape, infer the format, state what you found. Ask the user only if detection genuinely fails.
- Confidence-gated honesty. If
/confidencereturns < 90%, dig deeper or admit uncertainty. Do not paper over a weak diagnosis with a confident-sounding fix. - One trace at a time, but diff when given two. A passing run vs. a failing run of the same test is the strongest signal available.
Anti-patterns (one-liners — full list in
references/flake-patterns.md)
- Recommending
page.waitForTimeout(N)without measuring the underlying race condition. - Calling a test "flaky" without naming the race — every flake has a cause; "non-deterministic" is not a diagnosis.
- Reporting raw action counts without converting to wall-clock time share.
- Skipping the network log when an action timed out — most action timeouts are blocked on a request that never resolved.
- Swapping
text=forgetByRole(...)without checking whether the failure was selector resolution or actionability (visibility, pointer-events, animation). - Fixing one slow action and ignoring the long tail of cumulative
auto-waitdelays (death-by-a-thousand-cuts is the common case in real suites).
Trace-analysis quickstart
Input is a GitHub Actions run URL
node <skill_dir>/scripts/fetch-gh-run.mjs https://github.com/<owner>/<repo>/actions/runs/<id> [--out <dir>]The script uses the gh CLI (gh run download) to fetch every artifact
whose name matches Playwright conventions (playwright-report*,
playwright-traces*, test-results*, *-traces, *-trace), unpacks
nested ZIPs, and writes a manifest of all trace.zip files discovered,
grouped by failed test where possible. Then continue with the unpacked
flow below.
If gh is not installed or unauthenticated, ask the user to download the trace artifact manually from the Actions run page and provide the local path — the trace.zip flow below is unaffected.
Input is a trace.zip
- Unpack and index.
Writes a normalisednode <skill_dir>/scripts/trace-extract.mjs <path/to/trace.zip> [--out <dir>]trace.trace.jsonl,trace.network.jsonl, and a manifest of resources/snapshots into<dir>(defaults to a sibling<name>.unpacked/). - Run the summary.
Prints: total wall-clock, top-N slow actions, top-N slow requests, console errors, page errors, and the failing-action stack trace if present.node <skill_dir>/scripts/trace-summary.mjs <dir> - (Optional) Diff a passing trace against a failing trace.
Surfaces actions that diverge in duration, requests present in one but not the other, and the first action where the two timelines fork.node <skill_dir>/scripts/trace-diff.mjs <pass-dir> <fail-dir> - Map suspects to source. Use
rules/flake-diagnosis.mdPhases 3–4 to go from action callId → test file/line (Playwright trace events embedlocation: { file, line, column }).
The full extraction methodology (capture protocol, how to interpret the
network log, common flake shapes) is in
rules/flake-diagnosis.md. Don't preload
it — only when an input is detected.
Definition of Done
- Input format detected and stated (zip / dir / single JSONL).
- Failure mode named — timeout, assertion, error, or slow-passing (Phase 1).
- Top-N slow actions listed with measured
dur(ms). - Top-N slow requests listed with
responseEnd - requestStart(ms) and status. - Console / page errors captured verbatim.
- Each hotspot mapped to a test file + line (from
locationin the trace event), or to an app file when the cause is in product code. /confidence analysisreached ≥ 90% (or two deep-dives recorded with the remaining uncertainty surfaced to the user).- Fix plan written using
templates/analysis-report.md, with ranked fixes, expected ms saved, and a re-run verification step. - User has the next concrete action (apply fix N, re-run with
--trace=on, compare).
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

