agentleFS
Sign inStart free
TangleMLTangleML/tangle-ui/.claude/skills/e2e-testing/SKILL.md

e2e-testing

Skill104 starsChanged 3 days agoApache-2.0View on GitHub

Playwright E2E testing best practices for this project. Use when writing, modifying, or reviewing E2E tests.

We split this skill into the rules it gives an agent

7 rules. 0 are common, 5 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 38 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use Playwright helpers from tests/e2e/helpers.ts

    line 10
  2. Very specific:

    Use data-testid attributes for stable selectors

    line 11
  3. Distinctive:

    Write descriptive test names that explain user behavior

    line 12
  4. Distinctive:

    Ensure tests are isolated and can run independently

    line 13
  5. Distinctive:

    Don't depend on test execution order (unless using serial mode intentionally)

    line 91
  6. Distinctive:

    Create new helpers for repeated workflows

    line 97
  7. Distinctive:

    Keep helpers focused and reusable

    line 98

“Common” is measured: kept by at least 6 in 10 of the 38 edited versions of this file we could read. “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

E2E Testing Best Practices (Playwright)

Setup

  • Use Playwright helpers from tests/e2e/helpers.ts
  • Use data-testid attributes for stable selectors
  • Write descriptive test names that explain user behavior
  • Ensure tests are isolated and can run independently

Never Use Hard-Coded Timeouts

// Bad
await element.click();
await page.waitForTimeout(200);

// Good
await element.click();
await expect(otherElement).toBeVisible();

Use Playwright's Auto-Waiting

// Bad
if (await element.isVisible()) {
  await element.click();
}

// Good
await expect(element).toBeVisible();
await element.click();

Never Use Non-Null Assertions

// Bad
const box = await element.boundingBox();
const x = box!.x;

// Good
const box = await element.boundingBox();
if (!box) {
  throw new Error("Unable to locate element bounding box");
}
const x = box.x;

Don't Await Locators (They're Lazy)

// Bad
const button = await page.getByTestId("submit");

// Good
const button = page.getByTestId("submit");
await expect(button).toBeVisible();

Use Consistent Assertion Patterns

// Bad
expect(await element).toHaveText("text");
expect(await element.isVisible()).toBe(true);

// Good
await expect(element).toHaveText("text");
await expect(element).toBeVisible();

Prefer Semantic Selectors

Priority order:

  1. getByRole() - Best for accessibility
  2. getByTestId() - Best for test stability (preferred for this app)
  3. getByText() - Good for static content
  4. locator() with data attributes - When above don't work
  5. CSS selectors - Last resort

Test Isolation

  • Each test should set up its own state
  • Don't depend on test execution order (unless using serial mode intentionally)
  • Clean up after tests in afterEach or afterAll

Helper Functions

  • Leverage existing helpers from tests/e2e/helpers.ts
  • Create new helpers for repeated workflows
  • Keep helpers focused and reusable

Add Meaningful Error Context

// Okay
await expect(element).toBeVisible();

// Better
await expect(element, "Component should appear after loading").toBeVisible();

Test User Behavior, Not Implementation

// Bad - implementation detail
await expect(button).toHaveClass("bg-blue-500");

// Good - user-visible behavior
await expect(button).toBeVisible();
await expect(button).toBeEnabled();
await expect(button).toHaveText("Submit");

Download now (ZIP)

  • Other versions89 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 89

    1. affaan-m/ECC★ 246ksame name
    2. langflow-ai/langflow★ 156ksame name
    3. All-Hands-AI/OpenHands★ 92ksame name
    4. OpenHands/OpenHands★ 92ksame name
    5. pulsejet/memories★ 3.9ksame name
    6. xu-xiang/everything-claude-code-zh★ 1.9ksame name
    7. paradigmxyz/centaur★ 1.4ksame name
    8. etewiah/property_web_builder★ 644same name
    9. nodetool-ai/nodetool★ 603same name
    10. Opentrons/opentrons★ 529same name

    79 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use everything-claude-code, investor-materials and 10 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • InfopibeSkill

      everything-claude-code

      Also in 10 projects that use this

    • InfopibeSkill

      investor-materials

      Create and update pitch decks, one-pagers, investor memos, accelerator applications, financial models, and fundraising materials. Use when the user needs investor-facing documents, projections, use-of-funds tables, milestone plans, or materials that must stay internally consistent across multiple fundraising assets.

      Also in 28 projects that use this

    • mryeastcodeSkill

      everything-claude-code-conventions

      Development conventions and patterns for everything-claude-code. JavaScript project with conventional commits.

      Also in 8 projects that use this

    • tpavanipradeepSkill

      bun-runtime

      Bun as runtime, package manager, bundler, and test runner. When to choose Bun vs Node, migration notes, and Vercel support.

      Also in 18 projects that use this

    • niloykumarbarmanSkill

      agent-sort

      Build an evidence-backed ECC install plan for a specific repo by sorting skills, commands, rules, hooks, and extras into DAILY vs LIBRARY buckets using parallel repo-aware review passes. Use when ECC should be trimmed to what a project actually needs instead of loading the full bundle.

      Also in 8 projects that use this

    • niloykumarbarmanSkill

      product-capability

      Translate PRD intent, roadmap asks, or product discussions into an implementation-ready capability plan that exposes constraints, invariants, interfaces, and unresolved decisions before multi-service work starts. Use when the user needs an ECC-native PRD-to-SRS lane instead of vague planning prose.

      Also in 9 projects that use this

    • +1 more from Infopibe
  • In this repository20 other files it gives its agents.

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.

Check your setup, free