{"slug": "beyond-the-form-tester-building-a-skill-pack-for-your-whole-playwright-suite", "title": "Beyond the Form Tester: Building a Skill Pack for Your Whole Playwright Suite", "summary": "A developer building a Playwright skill pack for Claude Code has created a three-skill pack covering locator policy, page object generation, and flaky-test debugging, organized under a shared references folder to avoid repeating conventions. The pack uses progressive disclosure so that only relevant skills are loaded per session, saving tokens.", "body_md": "*Part 6 of the \"Automating Playwright with Claude Code\" series. In Part 4 we built one Skill; in Part 5 we learned why installing many Skills doesn't bloat every session. This post uses both to grow a single Skill into a small, organized **pack** covering more of your actual test suite.*\n\nOne Skill is useful. A handful of *related* Skills, organized as a pack, is what actually replaces a chunk of your team's onboarding docs. This post takes the `playwright-form-tester`\n\nSkill from Part 4 and grows it into a three-Skill pack — a locator policy, a page object generator, and a flaky-test debugger — using the progressive disclosure model from Part 5 so none of it costs you tokens you're not using.\n\n`references/`\n\nfolder across Skills instead of repeating the same conventions in three separate files.**Grows with your team.** New teammates get your locator conventions, your page object style, and your flaky-test triage process automatically — the same idea the wider \"Skill pack\" ecosystem (directories like qaskills.sh) is built around.\n\nCompleted [Part 4](https://dev.to/aswani25/what-is-skillmd-building-a-reusable-playwright-testing-skill-for-claude-code-27b1) (the `playwright-form-tester`\n\nSkill) and [Part 5](https://dev.to/aswani25/progressive-disclosure-why-you-can-install-30-skills-and-pay-for-almost-nothing-3n04) (progressive disclosure) of this series.\n\nComfortable creating multiple sibling folders under `.claude/skills/`\n\n.\n\nBefore writing anything, it helps to map out which Skill owns which trigger, so descriptions don't overlap:\n\n| Skill | Fires on requests like... |\n|---|---|\n`playwright-form-tester` (Part 4) |\n\"test the login form\", \"validate checkout\" |\n`playwright-locator-policy` |\n\"add a locator for...\", \"find the best selector for...\" |\n`playwright-page-object-generator` |\n\"generate a page object for...\", \"scaffold a POM for...\" |\n`playwright-flaky-test-debugger` |\n\"this test is flaky\", \"why does this fail intermittently\" |\n\n```\n.claude/skills/\n├── playwright-form-tester/\n├── playwright-locator-policy/\n├── playwright-page-object-generator/\n├── playwright-flaky-test-debugger/\n└── playwright-shared/\n    └── references/\n```\n\nThis Skill enforces a consistent locator strategy instead of letting Claude default to fragile CSS selectors.\n\n```\n---\nname: playwright-locator-policy\ndescription: Enforce locator strategy when writing or reviewing Playwright\n  selectors. Use whenever the user asks to add a locator, pick a selector,\n  or review existing locators for reliability.\n---\n\n# Playwright locator policy\n\n## Priority order\n1. `getByRole` (accessible name + role) — always prefer this first.\n2. `getByLabel` / `getByPlaceholder` — for form fields without a clear role match.\n3. `getByTestId` — only when no accessible attribute exists, using the\n   project's `data-testid` convention.\n4. Raw CSS/XPath — last resort only; flag it in the response so it can be\n   revisited later.\n\n## Process\n1. Inspect the snapshot for accessible roles and names before suggesting\n   any selector.\n2. Never suggest a locator tied to visual position (nth-child, index) —\n   these break the moment layout changes.\n3. If an existing test uses a fragile selector, suggest a replacement\n   rather than leaving it as-is.\n```\n\nThis Skill turns a page snapshot into a Page Object class matching your team's conventions.\n\n```\n---\nname: playwright-page-object-generator\ndescription: Generate or update Playwright Page Object Model classes. Use\n  whenever the user asks to scaffold a page object, generate a POM, or\n  create a page class for a UI flow.\n---\n\n# Playwright page object generator\n\n## Process\n1. Navigate to the target page and take a snapshot.\n2. Apply `playwright-locator-policy` conventions for every element chosen.\n3. Generate one class per page, with:\n   - Locators as readonly properties, named after their purpose\n     (`emailInput`, not `input1`).\n   - One method per user action (`login()`, `submitForm()`), not per\n     individual click or fill.\n4. Place the file under `pages/<PageName>Page.ts` (or the project's\n   existing page object folder, if one exists — check first).\n5. Never duplicate an existing Page Object; check for one before creating\n   a new file.\n```\n\nNotice this Skill explicitly references the locator-policy Skill's conventions in step 2 — Skills in a pack can lean on each other's standards without repeating the full policy inline.\n\nThis one handles a completely different trigger: diagnosing, not writing.\n\n```\n---\nname: playwright-flaky-test-debugger\ndescription: Diagnose intermittently failing Playwright tests. Use whenever\n  the user says a test is flaky, fails intermittently, or passes locally\n  but fails in CI.\n---\n\n# Playwright flaky test debugger\n\n## Process\n1. Ask for (or locate) the failing test's trace file or CI logs first —\n   never guess at a root cause without evidence.\n2. Check, in order, for the most common causes:\n   - Missing `await` before an action or assertion.\n   - An assertion that doesn't wait for state (use `expect(locator)`\n     auto-waiting patterns, not manual `sleep`/` wait` calls).\n   - Test-order dependency (does it fail only when run after another\n     specific test?).\n   - Environment difference (timing, viewport, or data state between\n     local and CI).\n3. Report the most likely cause with the specific line of evidence from\n   the trace/log that supports it — don't report a guess as a finding.\n4. Suggest one fix at a time; don't rewrite the whole test speculatively.\n```\n\nNotice step 3's guardrail — this mirrors the \"never fabricate\" guidance that's become a best practice for AI-assisted QA work: report evidence, not guesses.\n\nIf several Skills need the same longer reference (say, your team's full accessibility-name conventions for `getByRole`\n\n), put it once in a shared location instead of duplicating it:\n\n```\n.claude/skills/playwright-shared/references/accessible-naming.md\n```\n\nThen point to it by relative path from any Skill that needs it, rather than pasting the same content into three separate `SKILL.md`\n\nbodies. Per the progressive disclosure model from Part 5, this file still only loads when a step actually calls for it — sharing it doesn't cost you anything extra.\n\nRestart your Claude Code session, then test each trigger independently:\n\n```\nAdd a locator for the \"Remember me\" checkbox.\n→ should fire playwright-locator-policy\n\nGenerate a page object for the checkout page.\n→ should fire playwright-page-object-generator\n\nThis test passes locally but fails in CI about half the time.\n→ should fire playwright-flaky-test-debugger\n```\n\nIf two Skills fire for the same request, or neither fires, revisit their `description`\n\nfields — Part 5 covered why this is almost always a description problem, not a bug in the Skill body.\n\nA single Skill solves one repeated conversation. A pack — planned so each Skill has a clear, non-overlapping trigger, and sharing common references — starts to genuinely replace parts of your team's onboarding documentation, all without costing you tokens for the Skills you're not using in a given session. In the next post, we'll add explicit guardrails and human-review gates across this whole pack, so none of these Skills ever ship a fabricated result unchecked.\n\nHave you grouped your own Skills into a pack yet? What's in it? Let me know in the comments!", "url": "https://wpnews.pro/news/beyond-the-form-tester-building-a-skill-pack-for-your-whole-playwright-suite", "canonical_source": "https://dev.to/aswani25/beyond-the-form-tester-building-a-skill-pack-for-your-whole-playwright-suite-gk5", "published_at": "2026-07-23 16:30:00+00:00", "updated_at": "2026-07-23 17:04:30.742347+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence", "large-language-models"], "entities": ["Playwright", "Claude Code"], "alternates": {"html": "https://wpnews.pro/news/beyond-the-form-tester-building-a-skill-pack-for-your-whole-playwright-suite", "markdown": "https://wpnews.pro/news/beyond-the-form-tester-building-a-skill-pack-for-your-whole-playwright-suite.md", "text": "https://wpnews.pro/news/beyond-the-form-tester-building-a-skill-pack-for-your-whole-playwright-suite.txt", "jsonld": "https://wpnews.pro/news/beyond-the-form-tester-building-a-skill-pack-for-your-whole-playwright-suite.jsonld"}}