agentleFS
annatomkaannatomka/skills/playwright-impact-analysis/SKILL.md

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

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
  1. Distinctive:

    When this file is present:

    line 18
  2. Distinctive:

    read it from the current repository

    line 19
  3. Distinctive:

    use it as the primary source of truth for test selection

    line 20
  4. Distinctive:

    When this file is not present:

    line 23
  5. Distinctive:

    Prefer repository scripts over raw Playwright commands because they may apply environment setup, filtering, retries, or project-specific …

    line 38
  6. Distinctive:

    Default to all local changes compared to the default branch, usually main or master.

    line 47
  7. Distinctive:

    Use the mapping file first Read the detected E2E mapping file and resolve each changed file against the mapping.

    line 52
  8. Distinctive:

    Read the detected E2E mapping file and resolve each changed file against the mapping.

    line 53
  9. Distinctive:

    Prefer explicit mappings over heuristics If a changed file has an explicit mapping, use that mapping.

    line 63
  10. Distinctive:

    If a changed file has an explicit mapping, use that mapping.

    line 64
  11. Distinctive:

    Only use heuristics when:

    line 65
  12. Distinctive:

    If the same test is selected multiple times:

    line 78
  13. Distinctive:

    keep it only once

    line 79
  14. Distinctive:

    keep the highest confidence level

    line 80
  15. Distinctive:

    Use heuristics only for unmapped files For files not covered by the mapping:

    line 87
  16. Very specific:

    prefer SMOKE over guessing exact tests unless confidence is strong

    line 91
  17. Distinctive:

    Never claim the selected tests are guaranteed sufficient unless the mapping is explicit and direct.

    line 103
  18. Distinctive:

    If you had to rely on heuristics and the inferred relationship is strong, suggest one or more candidate additions to the detected E2E …

    line 110
  19. Distinctive:

    Always prefer the repository-standard E2E command:

    line 114
  20. Very specific:

    If a custom script exists, use it.

    line 120
  21. Very specific:

    Use npx playwright test only as a fallback when no repository script is available.

    line 122
  22. Very specific:

    Use output-template.md for response formatting.

    line 124
  23. Very specific:

    Use heuristics.md only when the mapping file does not fully answer the request.

    line 125

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.md
  • tests/e2e-test-mapping.md
  • e2e/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

  1. Discover the repository's E2E setup Inspect the repository before recommending commands or paths:

    • package.json scripts containing playwright, e2e, test:e2e, or similar names
    • Playwright config files such as playwright.config.ts, playwright.config.js, or playwright.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.

  2. 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 main or master.

  3. Collect changed files Build the list of changed files for the selected scope.
  4. 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
  5. 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
  6. Resolve special values Handle these exactly:
    • ALL → recommend running the full E2E suite with the detected E2E command
    • SMOKE → 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
  7. 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
  8. Use heuristics only for unmapped files For files not covered by the mapping:
    • apply the guidance from heuristics.md
    • be conservative
    • prefer SMOKE over guessing exact tests unless confidence is strong
  9. Produce actionable output Output:
    • the scope analyzed
    • changed files reviewed
    • recommended tests grouped by confidence
    • whether ALL or SMOKE was triggered
    • exact commands using the detected repository E2E command
    • assumptions and uncertainty
  10. 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
  1. 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.