القائمة
Use when creating page objects or refactoring Playwright E2E tests for better maintainability with Page Object Model patterns.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | playwright-page-objects |
| description | Use when creating page objects or refactoring Playwright E2E tests for better maintainability with Page Object Model patterns. |
| allowed-tools | ["Bash","Read","Write","Edit"] |
Modern POM architecture using Playwright's fixtures pattern, composition over inheritance, and role-based locators.
getByRole() > getByLabel() > getByText() > getByTestId()readonlythis for chaining; navigation methods return target page objectprivatewaitForPageLoad(), waitForResponse() before assertions| Pattern | When to Use | Reference |
|---|---|---|
| Fixtures | Always for page object instantiation | fixtures-pattern.md |
| Basic POM | All page objects | core-patterns.md |
| Composition | Shared UI elements (header, cards, modals) | core-patterns.md |
| Waiting strategies | Loading states, API responses | core-patterns.md |
| High-level actions | Multi-page flows (checkout, onboarding) | core-patterns.md |
| Form handling | Multi-step forms, validation | form-handling.md |
1. page.getByRole('button', { name: 'Add to Cart' }) // Preferred
2. page.getByLabel('Email') // Form inputs
3. page.getByText('Welcome back') // Non-interactive
4. page.getByPlaceholder('Search...') // When no label
5. page.getByTestId('cart-item-count') // Escape hatch
| Anti-Pattern | Problem | Solution |
|---|---|---|
| Assertions in POMs | Hidden test logic | Expose state, assert in tests |
| Fat page objects | 50+ locators unmaintainable | Split into components |
| Deep inheritance | Rigid, hard to modify | Use composition |
| CSS selectors | Break on styling changes | Use role-based selectors |
| Wrapping Playwright | Unnecessary abstraction | Use Playwright directly |
| All members public | Exposes internals | Mark internal members private |
Frontend building block catalog — typed patterns for components, hooks, queries, mutations, stores, and models. ALWAYS read the relevant rule file before creating or modifying any building block in src/features/ or src/lib/. This includes spec implementation (read rule files for every block in the Building Blocks Diff), new feature work, refactoring, and architectural decisions.
Collaboratively write a feature spec with the developer. Trigger when a task involves 5+ unconstrained decisions, spans 10+ files, or the developer explicitly asks for a spec. Do NOT trigger for config edits, CSS fixes, helper functions, exploratory prototyping, presentation-only changes, or when the developer explicitly opts out.
Test building block catalog — typed patterns for Storybook play-function tests, Vitest hook tests, Vitest unit tests, MSW handlers, and test data fixtures. Read the relevant rule file before writing or modifying any test, handler, or fixture. Covers: deciding which kind of test to write, authoring a new test from scratch, adding MSW mocks or fixtures, and reviewing existing tests for conformance.
Refactor bloated AGENTS.md, CLAUDE.md, or similar agent instruction files to follow progressive disclosure principles. Splits monolithic files into organized, linked documentation.
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Create high-quality git commits: review/stage intended changes, split into logical commits, and write clear commit messages (including Conventional Commits). Use when the user asks to commit, craft a commit message, stage changes, or split work into multiple commits.