agentleFS
jovd83jovd83/playwright-skill/pom/SKILL.md

playwright-pom

Skill1 starsChanged 35 days agoMITView on GitHub

Test-architecture skill for Playwright page objects, fixtures, and helpers. Use when the agent needs to decide whether to introduce a Page Object Model, how to structure page objects, and how to separate browser state, UI behavior, and stateless utilities cleanly.

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 7 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when the main decision is architectural rather than tactical.

    line 19
  2. Distinctive:

    Use fixtures for setup, teardown, shared state, and authenticated contexts.

    line 23
  3. Distinctive:

    Use page objects to encapsulate repeated or complex UI behavior.

    line 24
  4. Distinctive:

    Use helpers only for stateless utilities such as data generation, formatting, or pure transformations.

    line 25
  5. Distinctive:

    Do not force page objects for every one-off interaction.

    line 26
  6. Distinctive:

    Keep assertions close to the test unless a reusable page-level assertion adds clarity.

    line 31
  7. Very specific:

    Avoid helpers that accept a Page or mutate browser state.

    line 32
  8. Distinctive:

    Keep the testing support code organized with the tests it serves.

    line 33

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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

Playwright POM

Use this skill when the main decision is architectural rather than tactical.

Decision Model

  • Use fixtures for setup, teardown, shared state, and authenticated contexts.
  • Use page objects to encapsulate repeated or complex UI behavior.
  • Use helpers only for stateless utilities such as data generation, formatting, or pure transformations.
  • Do not force page objects for every one-off interaction.

Practical Rules

  1. Reach for a page object when the same UI behavior appears in multiple tests or when the page flow is complex enough to deserve a named abstraction.
  2. Keep assertions close to the test unless a reusable page-level assertion adds clarity.
  3. Avoid helpers that accept a Page or mutate browser state.
  4. Keep the testing support code organized with the tests it serves.

Read by Need

NeedGuide
Page object designpage-object-model.md
POM vs fixture vs helper tradeoffspom-vs-fixtures-vs-helpers.md
Broader architecture decisions../core/test-architecture.md

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.

Reviews can't be read right now.

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.