playwright-impact-analysis
Skill1 starsChanged 6 months agoMITView on GitHub
Use this skill when user asks for analyzing changes. Determine which Playwright e2e tests should run for local changes by using the E2E test mapping file first, then falling back to safe heuristics for unmapped files
In this repository6 other files it gives its agents.
The file
Show its rules and text
We split this skill into the rules it gives an agent
23 rules. About 0 are common, 18 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈18
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 18
When this file is present:
- Distinctive: line 19
read it from the current repository
- Distinctive: line 20
use it as the primary source of truth for test selection
- Distinctive: line 23
When this file is not present:
- Distinctive: line 38
Prefer repository scripts over raw Playwright commands because they may apply environment setup, filtering, retries, or project-specific …
- Distinctive: line 47
Default to all local changes compared to the default branch, usually main or master.
- Distinctive: line 52
Use the mapping file first Read the detected E2E mapping file and resolve each changed file against the mapping.
- Distinctive: line 53
Read the detected E2E mapping file and resolve each changed file against the mapping.
- Distinctive: line 63
Prefer explicit mappings over heuristics If a changed file has an explicit mapping, use that mapping.
- Distinctive: line 64
If a changed file has an explicit mapping, use that mapping.
- Distinctive: line 65
Only use heuristics when:
- Distinctive: line 78
If the same test is selected multiple times:
- Distinctive: line 79
keep it only once
- Distinctive: line 80
keep the highest confidence level
- Distinctive: line 87
Use heuristics only for unmapped files For files not covered by the mapping:
- Very specific: line 91
prefer SMOKE over guessing exact tests unless confidence is strong
- Distinctive: line 103
Never claim the selected tests are guaranteed sufficient unless the mapping is explicit and direct.
- Distinctive: line 110
If you had to rely on heuristics and the inferred relationship is strong, suggest one or more candidate additions to the detected E2E …
- Distinctive: line 114
Always prefer the repository-standard E2E command:
- Very specific: line 120
If a custom script exists, use it.
- Very specific: line 122
Use npx playwright test only as a fallback when no repository script is available.
- Very specific: line 124
Use output-template.md for response formatting.
- Very specific: line 125
Use heuristics.md only when the mapping file does not fully answer the request.
≈ “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
Determine the smallest safe subset of Playwright e2e tests affected by local changes.
This skill is repository-aware. Do not assume a specific framework, E2E folder, package manager, or test command.
Your primary source of truth is the repository's E2E test mapping file, if one exists.
Common mapping locations include:
e2e-test-mapping.mdtests/e2e-test-mapping.mde2e/e2e-test-mapping.md__e2e__/e2e-test-mapping.md<detected-e2e-folder>/e2e-test-mapping.md
When this file is present:
- read it from the current repository
- use it as the primary source of truth for test selection
- apply its precedence, confidence, special values, and fallback rules exactly
When this file is not present:
- fall back to the heuristics in this skill
- clearly state that no project mapping file was found
Your goal is to avoid running the full E2E suite unless necessary, while minimizing the chance of missing affected tests.
Workflow
Discover the repository's E2E setup Inspect the repository before recommending commands or paths:
package.jsonscripts containingplaywright,e2e,test:e2e, or similar names- Playwright config files such as
playwright.config.ts,playwright.config.js, orplaywright.config.mjs - common E2E folders such as
e2e/,tests/e2e/,__e2e__/,playwright/, or folders referenced by Playwright config - E2E mapping files in common locations
Prefer repository scripts over raw Playwright commands because they may apply environment setup, filtering, retries, or project-specific exclusions.
Determine the change scope Identify what local changes should be analyzed:
- unstaged changes
- staged changes
- stash, if the user explicitly asks
- local commits different from the default branch
Default to all local changes compared to the default branch, usually
mainormaster.- Collect changed files Build the list of changed files for the selected scope.
Use the mapping file first Read the detected E2E mapping file and resolve each changed file against the mapping.
Apply the mapping rules exactly as defined there:
- special values
- pattern rules
- match precedence
- confidence merge rules
- selection procedure
- fallback rules
- Prefer explicit mappings over heuristics
If a changed file has an explicit mapping, use that mapping.
Only use heuristics when:
- no mapping matches
- a mapping is too broad and additional explanation is useful
- the user asks for deeper reasoning
- Resolve special values
Handle these exactly:
ALL→ recommend running the full E2E suite with the detected E2E commandSMOKE→ recommend the repository's smoke command or append the appropriate Playwright grep flag when safe<e2e-folder>/**→ include all tests in that folder- exact test files → include those exact files
Merge and deduplicate results If the same test is selected multiple times:
- keep it only once
- keep the highest confidence level
Confidence priority:
- HIGH
- MEDIUM
- LOW
- Use heuristics only for unmapped files
For files not covered by the mapping:
- apply the guidance from
heuristics.md - be conservative
- prefer
SMOKEover guessing exact tests unless confidence is strong
- apply the guidance from
- Produce actionable output
Output:
- the scope analyzed
- changed files reviewed
- recommended tests grouped by confidence
- whether
ALLorSMOKEwas triggered - exact commands using the detected repository E2E command
- assumptions and uncertainty
- Do not overclaim Never claim the selected tests are guaranteed sufficient unless the mapping is explicit and direct. Clearly distinguish:
- mapping-based selections
- heuristic selections
- fallbacks
- Suggest mapping improvements when useful If you had to rely on heuristics and the inferred relationship is strong, suggest one or more candidate additions to the detected E2E mapping file.
Command rules
Always prefer the repository-standard E2E command:
- full suite:
<e2e-command> - smoke:
<e2e-command> --grep "@smoke", unless the repository has a dedicated smoke script - exact files:
<e2e-command> <file1> <file2> - grep by test name only if exact files are unavailable and there is a strong reason
If a custom script exists, use it. Examples include yarn test:e2e-local, npm run e2e, pnpm test:e2e, or another project-specific wrapper.
Use npx playwright test only as a fallback when no repository script is available.
Use output-template.md for response formatting.
Use heuristics.md only when the mapping file does not fully answer the request.
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.

