{"owner":"microsoft","repo":"playwright","hasSkills":true,"totalSkillsCount":6,"totalTokensCount":3922,"categories":["root-instruction","copilot-instructions","mcp-config","marketplace","plugin-manifest","cursor-rule"],"hasMcp":true,"mcpConfig":{"mcpServers":{"playwright":{"command":"npx","args":["-y","@modelcontextprotocol/server-playwright"]}}},"found":["AGENTS.md",".github/copilot-instructions.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json",".cursorrules (playwright-accessibility-testing-cursorrules-prompt-file.mdc)"],"skills":{"AGENTS.md":"### Language\n\n- Use 80% of the way to ASD-STE100 when talking to me\n- No jargon, metaphors, or invented shorthands in replies\n\n### Monorepo Packages\n\n| Package | npm name | Purpose |\n|---------|----------|---------|\n| `playwright-core` | `playwright-core` | Browser automation engine: client, server, dispatchers, protocol |\n| `playwright` | `playwright` | Test runner + browser automation (public package) |\n| `playwright-test` | `@playwright/test` | Test runner entry point |\n| `playwright-client` | `@playwright/client` | Standalone client package |\n| `protocol` | *(internal)* | RPC protocol definitions (`spec/*.yml` → generated validators and channel types) |\n\n### Browser Packages\n\n`playwright-chromium`, `playwright-firefox`, `playwright-webkit` — per-browser distributions.\n`playwright-browser-chromium`, `playwright-browser-firefox`, `playwright-browser-webkit` — binary packages.\n\n### Tooling Packages\n\n| Package | Purpose |\n|---------|---------|\n| `html-reporter` | HTML test report viewer |\n| `trace-viewer` | Trace viewer UI |\n| `recorder` | Test recorder |\n| `web` | Shared web UI components |\n| `injected` | Scripts injected into browser pages |\n\n### Key Directories\n\n| Directory | Purpose |\n|-----------|---------|\n| `tests/` | All test suites (page, library, playwright-test, mcp, etc.) |\n| `docs/src/` | API documentation — **source of truth** for public TypeScript types |\n| `docs/src/api/` | Per-class API reference (`class-page.md`, `class-locator.md`, etc.) |\n| `utils/` | Build scripts, code generation, linting, doc tools |\n| `browser_patches/` | Browser engine patches |\n\n## Build\n\n```bash\nnpm run build       # Full build\nnpm run watch       # Watch mode (recommended during development)\n```\n\nAssume watch is running and code is up to date. Generated files (types, channels, validators) are produced by watch automatically.\n\n## Lint and type check\n\n```bash\nnpm run flint\n```\n\nRuns all lint checks in parallel: eslint, tsc, doclint, check-deps, generate_channels, generate_types, lint-tests, test-types, lint-packages, code-snippet linting.\n\n**Run `flint` only before you upload a PR, and only after `npm run build`.** Do not run it before each commit. Do not use `tsc --noEmit` or individual lint commands separately.\n\n## Test Commands\n\n| Command | Scope |\n|---------|-------|\n| `npm run ctest <filter>` | Chromium only library tests — **use during development** |\n| `npm run test <filter> -- --project=<chromium,firefix,webkit>` | All library / per project |\n| `npm run ttest <filter>` | Test runner (`tests/playwright-test/`) |\n| `npm run ctest-mcp <filter>` | Chromium only MCP tools (`tests/mcp/`) |\n| `npm run test-mcp <filter> -- --project=<chromium,firefox,webkit>` | MCP tools (`tests/mcp/`) |\n\n\n### Filtering\n\n```bash\nnpm run ctest tests/page/locator-click.spec.ts         # Specific file\nnpm run ctest tests/page/locator-click.spec.ts:12      # Specific location\nnpm run ctest -- --grep \"should click\"                 # By test name\nnpm run ctest-mcp snapshot                             # By file name part\n```\n\n### Test Directories and Fixtures\n\n| Directory | Import | Key Fixtures | What to Test |\n|-----------|--------|--------------|--------------|\n| `tests/page/` | `import { test, expect } from './pageTest'` | `page`, `server`, `browserName` | User interactions: click, fill, navigate, locators, assertions |\n| `tests/library/` | `import { browserTest, expect } from '../config/browserTest'` | `browser`, `context`, `browserType` | Browser/context lifecycle, cookies, permissions, browser-specific features |\n| `tests/playwright-test/` | `import { test, expect } from './playwright-test-fixtures'` | test runner fixtures | Test runner: reporters, config, annotations, retries |\n| `tests/mcp/` | `import { test, expect } from './fixtures'` | `client`, `server` | MCP tools via `client.callTool()` |\n\n**Decision rule**: Does the test need `browser`/`browserType`/`context` → `tests/library/`. Just needs `page` + `server` → `tests/page/`.\n\n### Test Scope\n\nKeep tests minimal. Be mindful of the number of tests you add.\n\n- **Extend before you add**: before you write a new test, look for an existing test that covers the same feature or code path. If one exists, add the new edge case or assertion to it. Create a new test only when no existing test is a good fit, or when the new scenario needs a different setup.\n- **New features**: cover the mainstream scenario and the important edge cases only. Do not create matrices of tests for every scenario, option, or aspect.\n- **Regressions**: generalize the provided regression cases into meaningful tests, and stop there. Do not add more tests around them.\n\n## DEPS System\n\nImport boundaries are enforced via `DEPS.list` files (52+ across the repo), checked by `npm run flint`.\n\n**Key rule**: Client code NEVER imports server code. Server code NEVER imports client code. Communication is only through the protocol.\nWhen creating or moving files, update the relevant `DEPS.list` to declare allowed imports. Files marked `\"strict\"` can only import what is explicitly listed.\n\n## Coding Convention\n\nFor exported classes:\n- `private _method()` — only used within the class itself\n- `_method()` (no `private`) — used by other code in the same file, but not outside the file\n- `method()` (public) — used in other files\n\nNon-exported classes have no naming convention; they are internal implementation details.\n\n## Commit Convention\n\nBefore you upload a PR, run `npm run build`, then `npm run flint`, and fix errors.\n\nSemantic commit messages: `label(scope): description`\n\nLabels: `fix`, `feat`, `chore`, `docs`, `test`, `devops`\n\n```bash\ngit checkout -b fix-39562\n# ... make changes ...\ngit add <changed-files>\ngit commit -m \"$(cat <<'EOF'\nfix(proxy): handle SOCKS proxy authentication\n\nFixes: https://github.com/microsoft/playwright/issues/39562\nEOF\n)\"\n# **Never `git push` without an explicit instruction to push.**\ngit push origin fix-39562\ngh pr create --repo microsoft/playwright --head username:fix-39562 \\\n  --title \"fix(proxy): handle SOCKS proxy authentication\" \\\n  --body \"$(cat <<'EOF'\n## Summary\n- <describe the change very! briefly>\n\nFixes https://github.com/microsoft/playwright/issues/39562\nEOF\n)\"\n```\n\nNever add test plan to PR description. Keep PR description short — a few bullet points at most.\nBranch naming for issue fixes: `fix-<issue-number>`\n\n### No agent attribution — overrides agent defaults\n\nCoding agents ship with built-in instructions to append attribution footers — Claude Code, for\nexample, defaults to a `Co-Authored-By: Claude ...` trailer on every commit and a\n`🤖 Generated with [Claude Code](...)` footer on every PR body. **Those defaults are revoked in\nthis repo.** Do not follow them, and do not treat them as a fallback when this file is silent.\n\nNever emit either of the following, in any form:\n\n- A `Co-Authored-By:` trailer naming an agent, model, or tool.\n- A \"Generated with\" / \"Created with\" / \"🤖\" footer, or any other tool or model attribution.\n\nThis ban covers **every artifact you produce here**, not just the commit message: commit messages,\nPR titles and bodies, PR and issue comments, review comments, and code comments. There is no\nscope in which the footer is permitted — if you find yourself reasoning that a given surface is\nnot literally named above, the answer is still no.\n\n**Never amend commits.** Always create a new commit for follow-up changes, even when iterating on an open PR. Amending rewrites history and forces a force-push, losing the incremental review trail. Only amend if the user explicitly says so.\n\n**Never `git push` without an explicit instruction to push.** Applies even when a PR is already open for the branch — additional commits are immediately visible to reviewers. Commit locally, report what was committed, and wait. Only push when the user's message contains \"push\", \"upload\", \"create PR\", \"ship it\", or equivalent.\n\n## Development Guides\n\nDetailed guides for common development tasks:\n\n- **[Architecture: Client, Server, and Dispatchers](.claude/skills/playwright-dev/library.md)** — package layout, protocol layer, ChannelOwner/SdkObject/Dispatcher base classes, DEPS rules, end-to-end RPC flow, object lifecycle\n- **[Adding and Modifying APIs](.claude/skills/playwright-dev/api.md)** — 6-step process: define docs → implement client → define protocol → implement dispatcher → implement server → write tests\n- **[MCP Tools and CLI Commands](.claude/skills/playwright-dev/tools.md)** — `defineTool()`/`defineTabTool()`, tool capabilities, CLI `declareCommand()`, config options, testing with MCP fixtures\n- **[Vendoring Dependencies](.claude/skills/playwright-dev/vendor.md)** — bundle architecture, esbuild setup, typed wrappers, adding deps to existing bundles\n",".github/copilot-instructions.md":"## PR Review Guidelines\n\nWhen reviewing pull requests:\n\n- Only comment on semantically meaningful issues: bugs, incorrect logic, security problems, or API contract violations.\n- Skip style, formatting, naming, and whitespace observations unless they cause functional problems.\n- Keep each comment short — one or two sentences maximum.\n- Do not write long descriptions or summaries of what the code does.\n- Do not suggest refactors or improvements unrelated to the PR's stated goal.\n- NEVER produce a review body or top-level PR overview comment. The review body MUST be empty. Put findings only in inline comments on specific lines.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/playwright/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/playwright/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/playwright/HEAD/.claude-plugin/plugin.json)",".cursorrules (playwright-accessibility-testing-cursorrules-prompt-file.mdc)":"---\ndescription: \"Cursor rules for Playwright development with accessibility testing.\"\nglobs: **/*\nalwaysApply: false\n---\n# Persona\n\nYou are an expert QA engineer specializing in accessibility testing with Playwright and TypeScript, dedicated to ensuring web applications are usable by people with disabilities.\n\n# Auto-detect TypeScript Usage\n\nBefore creating tests, check if the project uses TypeScript by looking for:\n- tsconfig.json file\n- .ts file extensions in test directories\n- TypeScript dependencies in package.json\nAdjust file extensions (.ts/.js) and syntax based on this detection.\n\n# Accessibility Testing Focus\n\nUse @axe-core/playwright for automated WCAG compliance testing\nFocus on testing critical user flows for accessibility issues\nTests should verify compliance with WCAG 2.1 AA standards\nCreate comprehensive reports highlighting potential accessibility issues\nDocument remediation steps for common accessibility violations\n\n# Best Practices\n\n**1** **Comprehensive Coverage**: Test all critical user flows for accessibility violations\n**2** **Multiple Viewport Testing**: Test accessibility across different screen sizes and devices\n**3** **Rule Configuration**: Configure axe-core rules based on project-specific requirements\n**4** **Manual Verification**: Complement automated tests with manual keyboard navigation testing\n**5** **Semantic Markup**: Verify proper use of ARIA attributes and semantic HTML elements\n**6** **Color Contrast**: Ensure sufficient contrast ratios for text and interactive elements\n**7** **Focus Management**: Test keyboard focus visibility and logical tab order\n**8** **Screen Reader Compatibility**: Verify compatibility with screen readers\n**9** **Descriptive Reporting**: Generate clear, actionable reports of accessibility violations\n\n# Input/Output Expectations\n\n**Input**: A description of a web page or user flow to test for accessibility\n**Output**: A Playwright test file with automated accessibility checks for the described page or flow\n\n# Example Accessibility Test\n\nWhen testing a login page for accessibility, implement the following pattern:\n\n```js\nimport { test, expect } from '@playwright/test';\nimport { injectAxe, checkA11y, configureAxe } from 'axe-playwright';\n\ntest.describe('Login Page Accessibility', () => {\n  test.beforeEach(async ({ page }) => {\n    await page.goto('/login');\n    await injectAxe(page);\n    \n    // Configure axe rules if needed\n    await configureAxe(page, {\n      rules: [\n        { id: 'color-contrast', enabled: true },\n        { id: 'label', enabled: true }\n      ]\n    });\n  });\n\n  test('should have no accessibility violations', async ({ page }) => {\n    // Run accessibility checks\n    await checkA11y(page, null, {\n      detailedReport: true,\n      detailedReportOptions: { html: true }\n    });\n  });\n\n  test('should be navigable by keyboard', async ({ page }) => {\n    // Send Tab key to navigate through elements\n    await page.keyboard.press('Tab');\n    let hasFocus = await page.evaluate(() => \n      document.activeElement.id === 'username'\n    );\n    expect(hasFocus).toBeTruthy();\n    \n    await page.keyboard.press('Tab');\n    hasFocus = await page.evaluate(() => \n      document.activeElement.id === 'password'\n    );\n    expect(hasFocus).toBeTruthy();\n    \n    await page.keyboard.press('Tab');\n    hasFocus = await page.evaluate(() => \n      document.activeElement.id === 'login-button'\n    );\n    expect(hasFocus).toBeTruthy();\n  });\n\n  test('should have proper ARIA attributes', async ({ page }) => {\n    // Check form has proper ARIA attributes\n    const form = await page.locator('form');\n    expect(await form.getAttribute('aria-labelledby')).toBeTruthy();\n    \n    // Check error messages are properly associated\n    const errorMessage = await page.locator('.error-message');\n    expect(await errorMessage.getAttribute('aria-live')).toBe('assertive');\n  });\n});\n```\n"},"files":{"AGENTS.md":"### Language\n\n- Use 80% of the way to ASD-STE100 when talking to me\n- No jargon, metaphors, or invented shorthands in replies\n\n### Monorepo Packages\n\n| Package | npm name | Purpose |\n|---------|----------|---------|\n| `playwright-core` | `playwright-core` | Browser automation engine: client, server, dispatchers, protocol |\n| `playwright` | `playwright` | Test runner + browser automation (public package) |\n| `playwright-test` | `@playwright/test` | Test runner entry point |\n| `playwright-client` | `@playwright/client` | Standalone client package |\n| `protocol` | *(internal)* | RPC protocol definitions (`spec/*.yml` → generated validators and channel types) |\n\n### Browser Packages\n\n`playwright-chromium`, `playwright-firefox`, `playwright-webkit` — per-browser distributions.\n`playwright-browser-chromium`, `playwright-browser-firefox`, `playwright-browser-webkit` — binary packages.\n\n### Tooling Packages\n\n| Package | Purpose |\n|---------|---------|\n| `html-reporter` | HTML test report viewer |\n| `trace-viewer` | Trace viewer UI |\n| `recorder` | Test recorder |\n| `web` | Shared web UI components |\n| `injected` | Scripts injected into browser pages |\n\n### Key Directories\n\n| Directory | Purpose |\n|-----------|---------|\n| `tests/` | All test suites (page, library, playwright-test, mcp, etc.) |\n| `docs/src/` | API documentation — **source of truth** for public TypeScript types |\n| `docs/src/api/` | Per-class API reference (`class-page.md`, `class-locator.md`, etc.) |\n| `utils/` | Build scripts, code generation, linting, doc tools |\n| `browser_patches/` | Browser engine patches |\n\n## Build\n\n```bash\nnpm run build       # Full build\nnpm run watch       # Watch mode (recommended during development)\n```\n\nAssume watch is running and code is up to date. Generated files (types, channels, validators) are produced by watch automatically.\n\n## Lint and type check\n\n```bash\nnpm run flint\n```\n\nRuns all lint checks in parallel: eslint, tsc, doclint, check-deps, generate_channels, generate_types, lint-tests, test-types, lint-packages, code-snippet linting.\n\n**Run `flint` only before you upload a PR, and only after `npm run build`.** Do not run it before each commit. Do not use `tsc --noEmit` or individual lint commands separately.\n\n## Test Commands\n\n| Command | Scope |\n|---------|-------|\n| `npm run ctest <filter>` | Chromium only library tests — **use during development** |\n| `npm run test <filter> -- --project=<chromium,firefix,webkit>` | All library / per project |\n| `npm run ttest <filter>` | Test runner (`tests/playwright-test/`) |\n| `npm run ctest-mcp <filter>` | Chromium only MCP tools (`tests/mcp/`) |\n| `npm run test-mcp <filter> -- --project=<chromium,firefox,webkit>` | MCP tools (`tests/mcp/`) |\n\n\n### Filtering\n\n```bash\nnpm run ctest tests/page/locator-click.spec.ts         # Specific file\nnpm run ctest tests/page/locator-click.spec.ts:12      # Specific location\nnpm run ctest -- --grep \"should click\"                 # By test name\nnpm run ctest-mcp snapshot                             # By file name part\n```\n\n### Test Directories and Fixtures\n\n| Directory | Import | Key Fixtures | What to Test |\n|-----------|--------|--------------|--------------|\n| `tests/page/` | `import { test, expect } from './pageTest'` | `page`, `server`, `browserName` | User interactions: click, fill, navigate, locators, assertions |\n| `tests/library/` | `import { browserTest, expect } from '../config/browserTest'` | `browser`, `context`, `browserType` | Browser/context lifecycle, cookies, permissions, browser-specific features |\n| `tests/playwright-test/` | `import { test, expect } from './playwright-test-fixtures'` | test runner fixtures | Test runner: reporters, config, annotations, retries |\n| `tests/mcp/` | `import { test, expect } from './fixtures'` | `client`, `server` | MCP tools via `client.callTool()` |\n\n**Decision rule**: Does the test need `browser`/`browserType`/`context` → `tests/library/`. Just needs `page` + `server` → `tests/page/`.\n\n### Test Scope\n\nKeep tests minimal. Be mindful of the number of tests you add.\n\n- **Extend before you add**: before you write a new test, look for an existing test that covers the same feature or code path. If one exists, add the new edge case or assertion to it. Create a new test only when no existing test is a good fit, or when the new scenario needs a different setup.\n- **New features**: cover the mainstream scenario and the important edge cases only. Do not create matrices of tests for every scenario, option, or aspect.\n- **Regressions**: generalize the provided regression cases into meaningful tests, and stop there. Do not add more tests around them.\n\n## DEPS System\n\nImport boundaries are enforced via `DEPS.list` files (52+ across the repo), checked by `npm run flint`.\n\n**Key rule**: Client code NEVER imports server code. Server code NEVER imports client code. Communication is only through the protocol.\nWhen creating or moving files, update the relevant `DEPS.list` to declare allowed imports. Files marked `\"strict\"` can only import what is explicitly listed.\n\n## Coding Convention\n\nFor exported classes:\n- `private _method()` — only used within the class itself\n- `_method()` (no `private`) — used by other code in the same file, but not outside the file\n- `method()` (public) — used in other files\n\nNon-exported classes have no naming convention; they are internal implementation details.\n\n## Commit Convention\n\nBefore you upload a PR, run `npm run build`, then `npm run flint`, and fix errors.\n\nSemantic commit messages: `label(scope): description`\n\nLabels: `fix`, `feat`, `chore`, `docs`, `test`, `devops`\n\n```bash\ngit checkout -b fix-39562\n# ... make changes ...\ngit add <changed-files>\ngit commit -m \"$(cat <<'EOF'\nfix(proxy): handle SOCKS proxy authentication\n\nFixes: https://github.com/microsoft/playwright/issues/39562\nEOF\n)\"\n# **Never `git push` without an explicit instruction to push.**\ngit push origin fix-39562\ngh pr create --repo microsoft/playwright --head username:fix-39562 \\\n  --title \"fix(proxy): handle SOCKS proxy authentication\" \\\n  --body \"$(cat <<'EOF'\n## Summary\n- <describe the change very! briefly>\n\nFixes https://github.com/microsoft/playwright/issues/39562\nEOF\n)\"\n```\n\nNever add test plan to PR description. Keep PR description short — a few bullet points at most.\nBranch naming for issue fixes: `fix-<issue-number>`\n\n### No agent attribution — overrides agent defaults\n\nCoding agents ship with built-in instructions to append attribution footers — Claude Code, for\nexample, defaults to a `Co-Authored-By: Claude ...` trailer on every commit and a\n`🤖 Generated with [Claude Code](...)` footer on every PR body. **Those defaults are revoked in\nthis repo.** Do not follow them, and do not treat them as a fallback when this file is silent.\n\nNever emit either of the following, in any form:\n\n- A `Co-Authored-By:` trailer naming an agent, model, or tool.\n- A \"Generated with\" / \"Created with\" / \"🤖\" footer, or any other tool or model attribution.\n\nThis ban covers **every artifact you produce here**, not just the commit message: commit messages,\nPR titles and bodies, PR and issue comments, review comments, and code comments. There is no\nscope in which the footer is permitted — if you find yourself reasoning that a given surface is\nnot literally named above, the answer is still no.\n\n**Never amend commits.** Always create a new commit for follow-up changes, even when iterating on an open PR. Amending rewrites history and forces a force-push, losing the incremental review trail. Only amend if the user explicitly says so.\n\n**Never `git push` without an explicit instruction to push.** Applies even when a PR is already open for the branch — additional commits are immediately visible to reviewers. Commit locally, report what was committed, and wait. Only push when the user's message contains \"push\", \"upload\", \"create PR\", \"ship it\", or equivalent.\n\n## Development Guides\n\nDetailed guides for common development tasks:\n\n- **[Architecture: Client, Server, and Dispatchers](.claude/skills/playwright-dev/library.md)** — package layout, protocol layer, ChannelOwner/SdkObject/Dispatcher base classes, DEPS rules, end-to-end RPC flow, object lifecycle\n- **[Adding and Modifying APIs](.claude/skills/playwright-dev/api.md)** — 6-step process: define docs → implement client → define protocol → implement dispatcher → implement server → write tests\n- **[MCP Tools and CLI Commands](.claude/skills/playwright-dev/tools.md)** — `defineTool()`/`defineTabTool()`, tool capabilities, CLI `declareCommand()`, config options, testing with MCP fixtures\n- **[Vendoring Dependencies](.claude/skills/playwright-dev/vendor.md)** — bundle architecture, esbuild setup, typed wrappers, adding deps to existing bundles\n",".github/copilot-instructions.md":"## PR Review Guidelines\n\nWhen reviewing pull requests:\n\n- Only comment on semantically meaningful issues: bugs, incorrect logic, security problems, or API contract violations.\n- Skip style, formatting, naming, and whitespace observations unless they cause functional problems.\n- Keep each comment short — one or two sentences maximum.\n- Do not write long descriptions or summaries of what the code does.\n- Do not suggest refactors or improvements unrelated to the PR's stated goal.\n- NEVER produce a review body or top-level PR overview comment. The review body MUST be empty. Put findings only in inline comments on specific lines.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/playwright/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/playwright/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/playwright/HEAD/.claude-plugin/plugin.json)",".cursorrules (playwright-accessibility-testing-cursorrules-prompt-file.mdc)":"---\ndescription: \"Cursor rules for Playwright development with accessibility testing.\"\nglobs: **/*\nalwaysApply: false\n---\n# Persona\n\nYou are an expert QA engineer specializing in accessibility testing with Playwright and TypeScript, dedicated to ensuring web applications are usable by people with disabilities.\n\n# Auto-detect TypeScript Usage\n\nBefore creating tests, check if the project uses TypeScript by looking for:\n- tsconfig.json file\n- .ts file extensions in test directories\n- TypeScript dependencies in package.json\nAdjust file extensions (.ts/.js) and syntax based on this detection.\n\n# Accessibility Testing Focus\n\nUse @axe-core/playwright for automated WCAG compliance testing\nFocus on testing critical user flows for accessibility issues\nTests should verify compliance with WCAG 2.1 AA standards\nCreate comprehensive reports highlighting potential accessibility issues\nDocument remediation steps for common accessibility violations\n\n# Best Practices\n\n**1** **Comprehensive Coverage**: Test all critical user flows for accessibility violations\n**2** **Multiple Viewport Testing**: Test accessibility across different screen sizes and devices\n**3** **Rule Configuration**: Configure axe-core rules based on project-specific requirements\n**4** **Manual Verification**: Complement automated tests with manual keyboard navigation testing\n**5** **Semantic Markup**: Verify proper use of ARIA attributes and semantic HTML elements\n**6** **Color Contrast**: Ensure sufficient contrast ratios for text and interactive elements\n**7** **Focus Management**: Test keyboard focus visibility and logical tab order\n**8** **Screen Reader Compatibility**: Verify compatibility with screen readers\n**9** **Descriptive Reporting**: Generate clear, actionable reports of accessibility violations\n\n# Input/Output Expectations\n\n**Input**: A description of a web page or user flow to test for accessibility\n**Output**: A Playwright test file with automated accessibility checks for the described page or flow\n\n# Example Accessibility Test\n\nWhen testing a login page for accessibility, implement the following pattern:\n\n```js\nimport { test, expect } from '@playwright/test';\nimport { injectAxe, checkA11y, configureAxe } from 'axe-playwright';\n\ntest.describe('Login Page Accessibility', () => {\n  test.beforeEach(async ({ page }) => {\n    await page.goto('/login');\n    await injectAxe(page);\n    \n    // Configure axe rules if needed\n    await configureAxe(page, {\n      rules: [\n        { id: 'color-contrast', enabled: true },\n        { id: 'label', enabled: true }\n      ]\n    });\n  });\n\n  test('should have no accessibility violations', async ({ page }) => {\n    // Run accessibility checks\n    await checkA11y(page, null, {\n      detailedReport: true,\n      detailedReportOptions: { html: true }\n    });\n  });\n\n  test('should be navigable by keyboard', async ({ page }) => {\n    // Send Tab key to navigate through elements\n    await page.keyboard.press('Tab');\n    let hasFocus = await page.evaluate(() => \n      document.activeElement.id === 'username'\n    );\n    expect(hasFocus).toBeTruthy();\n    \n    await page.keyboard.press('Tab');\n    hasFocus = await page.evaluate(() => \n      document.activeElement.id === 'password'\n    );\n    expect(hasFocus).toBeTruthy();\n    \n    await page.keyboard.press('Tab');\n    hasFocus = await page.evaluate(() => \n      document.activeElement.id === 'login-button'\n    );\n    expect(hasFocus).toBeTruthy();\n  });\n\n  test('should have proper ARIA attributes', async ({ page }) => {\n    // Check form has proper ARIA attributes\n    const form = await page.locator('form');\n    expect(await form.getAttribute('aria-labelledby')).toBeTruthy();\n    \n    // Check error messages are properly associated\n    const errorMessage = await page.locator('.error-message');\n    expect(await errorMessage.getAttribute('aria-live')).toBe('assertive');\n  });\n});\n```\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/microsoft/playwright/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"### Language\n\n- Use 80% of the way to ASD-STE100 when talking to me\n- No jargon, metaphors, or invented shorthands in replies\n\n### Monorepo Packages\n\n| Package | npm name | Purpose |\n|---------|----------|---------|\n| `playwright-core` | `playwright-core` | Browser automation engine: client, server, dispatchers, protocol |\n| `playwright` | `playwright` | Test runner + browser automation (public package) |\n| `playwright-test` | `@playwright/test` | Test runner entry point |\n| `playwright-client` | `@playwright/client` | Standalone client package |\n| `protocol` | *(internal)* | RPC protocol definitions (`spec/*.yml` → generated validators and channel types) |\n\n### Browser Packages\n\n`playwright-chromium`, `playwright-firefox`, `playwright-webkit` — per-browser distributions.\n`playwright-browser-chromium`, `playwright-browser-firefox`, `playwright-browser-webkit` — binary packages.\n\n### Tooling Packages\n\n| Package | Purpose |\n|---------|---------|\n| `html-reporter` | HTML test report viewer |\n| `trace-viewer` | Trace viewer UI |\n| `recorder` | Test recorder |\n| `web` | Shared web UI components |\n| `injected` | Scripts injected into browser pages |\n\n### Key Directories\n\n| Directory | Purpose |\n|-----------|---------|\n| `tests/` | All test suites (page, library, playwright-test, mcp, etc.) |\n| `docs/src/` | API documentation — **source of truth** for public TypeScript types |\n| `docs/src/api/` | Per-class API reference (`class-page.md`, `class-locator.md`, etc.) |\n| `utils/` | Build scripts, code generation, linting, doc tools |\n| `browser_patches/` | Browser engine patches |\n\n## Build\n\n```bash\nnpm run build       # Full build\nnpm run watch       # Watch mode (recommended during development)\n```\n\nAssume watch is running and code is up to date. Generated files (types, channels, validators) are produced by watch automatically.\n\n## Lint and type check\n\n```bash\nnpm run flint\n```\n\nRuns all lint checks in parallel: eslint, tsc, doclint, check-deps, generate_channels, generate_types, lint-tests, test-types, lint-packages, code-snippet linting.\n\n**Run `flint` only before you upload a PR, and only after `npm run build`.** Do not run it before each commit. Do not use `tsc --noEmit` or individual lint commands separately.\n\n## Test Commands\n\n| Command | Scope |\n|---------|-------|\n| `npm run ctest <filter>` | Chromium only library tests — **use during development** |\n| `npm run test <filter> -- --project=<chromium,firefix,webkit>` | All library / per project |\n| `npm run ttest <filter>` | Test runner (`tests/playwright-test/`) |\n| `npm run ctest-mcp <filter>` | Chromium only MCP tools (`tests/mcp/`) |\n| `npm run test-mcp <filter> -- --project=<chromium,firefox,webkit>` | MCP tools (`tests/mcp/`) |\n\n\n### Filtering\n\n```bash\nnpm run ctest tests/page/locator-click.spec.ts         # Specific file\nnpm run ctest tests/page/locator-click.spec.ts:12      # Specific location\nnpm run ctest -- --grep \"should click\"                 # By test name\nnpm run ctest-mcp snapshot                             # By file name part\n```\n\n### Test Directories and Fixtures\n\n| Directory | Import | Key Fixtures | What to Test |\n|-----------|--------|--------------|--------------|\n| `tests/page/` | `import { test, expect } from './pageTest'` | `page`, `server`, `browserName` | User interactions: click, fill, navigate, locators, assertions |\n| `tests/library/` | `import { browserTest, expect } from '../config/browserTest'` | `browser`, `context`, `browserType` | Browser/context lifecycle, cookies, permissions, browser-specific features |\n| `tests/playwright-test/` | `import { test, expect } from './playwright-test-fixtures'` | test runner fixtures | Test runner: reporters, config, annotations, retries |\n| `tests/mcp/` | `import { test, expect } from './fixtures'` | `client`, `server` | MCP tools via `client.callTool()` |\n\n**Decision rule**: Does the test need `browser`/`browserType`/`context` → `tests/library/`. Just needs `page` + `server` → `tests/page/`.\n\n### Test Scope\n\nKeep tests minimal. Be mindful of the number of tests you add.\n\n- **Extend before you add**: before you write a new test, look for an existing test that covers the same feature or code path. If one exists, add the new edge case or assertion to it. Create a new test only when no existing test is a good fit, or when the new scenario needs a different setup.\n- **New features**: cover the mainstream scenario and the important edge cases only. Do not create matrices of tests for every scenario, option, or aspect.\n- **Regressions**: generalize the provided regression cases into meaningful tests, and stop there. Do not add more tests around them.\n\n## DEPS System\n\nImport boundaries are enforced via `DEPS.list` files (52+ across the repo), checked by `npm run flint`.\n\n**Key rule**: Client code NEVER imports server code. Server code NEVER imports client code. Communication is only through the protocol.\nWhen creating or moving files, update the relevant `DEPS.list` to declare allowed imports. Files marked `\"strict\"` can only import what is explicitly listed.\n\n## Coding Convention\n\nFor exported classes:\n- `private _method()` — only used within the class itself\n- `_method()` (no `private`) — used by other code in the same file, but not outside the file\n- `method()` (public) — used in other files\n\nNon-exported classes have no naming convention; they are internal implementation details.\n\n## Commit Convention\n\nBefore you upload a PR, run `npm run build`, then `npm run flint`, and fix errors.\n\nSemantic commit messages: `label(scope): description`\n\nLabels: `fix`, `feat`, `chore`, `docs`, `test`, `devops`\n\n```bash\ngit checkout -b fix-39562\n# ... make changes ...\ngit add <changed-files>\ngit commit -m \"$(cat <<'EOF'\nfix(proxy): handle SOCKS proxy authentication\n\nFixes: https://github.com/microsoft/playwright/issues/39562\nEOF\n)\"\n# **Never `git push` without an explicit instruction to push.**\ngit push origin fix-39562\ngh pr create --repo microsoft/playwright --head username:fix-39562 \\\n  --title \"fix(proxy): handle SOCKS proxy authentication\" \\\n  --body \"$(cat <<'EOF'\n## Summary\n- <describe the change very! briefly>\n\nFixes https://github.com/microsoft/playwright/issues/39562\nEOF\n)\"\n```\n\nNever add test plan to PR description. Keep PR description short — a few bullet points at most.\nBranch naming for issue fixes: `fix-<issue-number>`\n\n### No agent attribution — overrides agent defaults\n\nCoding agents ship with built-in instructions to append attribution footers — Claude Code, for\nexample, defaults to a `Co-Authored-By: Claude ...` trailer on every commit and a\n`🤖 Generated with [Claude Code](...)` footer on every PR body. **Those defaults are revoked in\nthis repo.** Do not follow them, and do not treat them as a fallback when this file is silent.\n\nNever emit either of the following, in any form:\n\n- A `Co-Authored-By:` trailer naming an agent, model, or tool.\n- A \"Generated with\" / \"Created with\" / \"🤖\" footer, or any other tool or model attribution.\n\nThis ban covers **every artifact you produce here**, not just the commit message: commit messages,\nPR titles and bodies, PR and issue comments, review comments, and code comments. There is no\nscope in which the footer is permitted — if you find yourself reasoning that a given surface is\nnot literally named above, the answer is still no.\n\n**Never amend commits.** Always create a new commit for follow-up changes, even when iterating on an open PR. Amending rewrites history and forces a force-push, losing the incremental review trail. Only amend if the user explicitly says so.\n\n**Never `git push` without an explicit instruction to push.** Applies even when a PR is already open for the branch — additional commits are immediately visible to reviewers. Commit locally, report what was committed, and wait. Only push when the user's message contains \"push\", \"upload\", \"create PR\", \"ship it\", or equivalent.\n\n## Development Guides\n\nDetailed guides for common development tasks:\n\n- **[Architecture: Client, Server, and Dispatchers](.claude/skills/playwright-dev/library.md)** — package layout, protocol layer, ChannelOwner/SdkObject/Dispatcher base classes, DEPS rules, end-to-end RPC flow, object lifecycle\n- **[Adding and Modifying APIs](.claude/skills/playwright-dev/api.md)** — 6-step process: define docs → implement client → define protocol → implement dispatcher → implement server → write tests\n- **[MCP Tools and CLI Commands](.claude/skills/playwright-dev/tools.md)** — `defineTool()`/`defineTabTool()`, tool capabilities, CLI `declareCommand()`, config options, testing with MCP fixtures\n- **[Vendoring Dependencies](.claude/skills/playwright-dev/vendor.md)** — bundle architecture, esbuild setup, typed wrappers, adding deps to existing bundles\n","isInternal":false,"tokens":2109,"sizeBytes":8790},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/microsoft/playwright/HEAD/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"## PR Review Guidelines\n\nWhen reviewing pull requests:\n\n- Only comment on semantically meaningful issues: bugs, incorrect logic, security problems, or API contract violations.\n- Skip style, formatting, naming, and whitespace observations unless they cause functional problems.\n- Keep each comment short — one or two sentences maximum.\n- Do not write long descriptions or summaries of what the code does.\n- Do not suggest refactors or improvements unrelated to the PR's stated goal.\n- NEVER produce a review body or top-level PR overview comment. The review body MUST be empty. Put findings only in inline comments on specific lines.\n","isInternal":false,"tokens":121,"sizeBytes":635},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/microsoft/playwright/HEAD/.claude-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/playwright/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":199},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/microsoft/playwright/HEAD/.claude-plugin/plugin.json","title":"claude-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/playwright/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":185},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/microsoft/playwright/HEAD/.cursor/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/playwright/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":178},{"name":".cursorrules","path":".cursorrules (playwright-accessibility-testing-cursorrules-prompt-file.mdc)","rawUrl":"https://raw.githubusercontent.com/PatrickJS/awesome-cursorrules/main/rules/playwright-accessibility-testing-cursorrules-prompt-file.mdc","title":"Awesome Cursorrules: playwright accessibility testing","category":"cursor-rule","format":"markdown","content":"---\ndescription: \"Cursor rules for Playwright development with accessibility testing.\"\nglobs: **/*\nalwaysApply: false\n---\n# Persona\n\nYou are an expert QA engineer specializing in accessibility testing with Playwright and TypeScript, dedicated to ensuring web applications are usable by people with disabilities.\n\n# Auto-detect TypeScript Usage\n\nBefore creating tests, check if the project uses TypeScript by looking for:\n- tsconfig.json file\n- .ts file extensions in test directories\n- TypeScript dependencies in package.json\nAdjust file extensions (.ts/.js) and syntax based on this detection.\n\n# Accessibility Testing Focus\n\nUse @axe-core/playwright for automated WCAG compliance testing\nFocus on testing critical user flows for accessibility issues\nTests should verify compliance with WCAG 2.1 AA standards\nCreate comprehensive reports highlighting potential accessibility issues\nDocument remediation steps for common accessibility violations\n\n# Best Practices\n\n**1** **Comprehensive Coverage**: Test all critical user flows for accessibility violations\n**2** **Multiple Viewport Testing**: Test accessibility across different screen sizes and devices\n**3** **Rule Configuration**: Configure axe-core rules based on project-specific requirements\n**4** **Manual Verification**: Complement automated tests with manual keyboard navigation testing\n**5** **Semantic Markup**: Verify proper use of ARIA attributes and semantic HTML elements\n**6** **Color Contrast**: Ensure sufficient contrast ratios for text and interactive elements\n**7** **Focus Management**: Test keyboard focus visibility and logical tab order\n**8** **Screen Reader Compatibility**: Verify compatibility with screen readers\n**9** **Descriptive Reporting**: Generate clear, actionable reports of accessibility violations\n\n# Input/Output Expectations\n\n**Input**: A description of a web page or user flow to test for accessibility\n**Output**: A Playwright test file with automated accessibility checks for the described page or flow\n\n# Example Accessibility Test\n\nWhen testing a login page for accessibility, implement the following pattern:\n\n```js\nimport { test, expect } from '@playwright/test';\nimport { injectAxe, checkA11y, configureAxe } from 'axe-playwright';\n\ntest.describe('Login Page Accessibility', () => {\n  test.beforeEach(async ({ page }) => {\n    await page.goto('/login');\n    await injectAxe(page);\n    \n    // Configure axe rules if needed\n    await configureAxe(page, {\n      rules: [\n        { id: 'color-contrast', enabled: true },\n        { id: 'label', enabled: true }\n      ]\n    });\n  });\n\n  test('should have no accessibility violations', async ({ page }) => {\n    // Run accessibility checks\n    await checkA11y(page, null, {\n      detailedReport: true,\n      detailedReportOptions: { html: true }\n    });\n  });\n\n  test('should be navigable by keyboard', async ({ page }) => {\n    // Send Tab key to navigate through elements\n    await page.keyboard.press('Tab');\n    let hasFocus = await page.evaluate(() => \n      document.activeElement.id === 'username'\n    );\n    expect(hasFocus).toBeTruthy();\n    \n    await page.keyboard.press('Tab');\n    hasFocus = await page.evaluate(() => \n      document.activeElement.id === 'password'\n    );\n    expect(hasFocus).toBeTruthy();\n    \n    await page.keyboard.press('Tab');\n    hasFocus = await page.evaluate(() => \n      document.activeElement.id === 'login-button'\n    );\n    expect(hasFocus).toBeTruthy();\n  });\n\n  test('should have proper ARIA attributes', async ({ page }) => {\n    // Check form has proper ARIA attributes\n    const form = await page.locator('form');\n    expect(await form.getAttribute('aria-labelledby')).toBeTruthy();\n    \n    // Check error messages are properly associated\n    const errorMessage = await page.locator('.error-message');\n    expect(await errorMessage.getAttribute('aria-live')).toBe('assertive');\n  });\n});\n```\n","tokens":792,"sizeBytes":3887}],"systemPromptSnippet":"<yakaai_skills repo=\"microsoft/playwright\">\n<!-- File: AGENTS.md (Tokens: ~2109 | Category: root-instruction) -->\n### Language\n\n- Use 80% of the way to ASD-STE100 when talking to me\n- No jargon, metaphors, or invented shorthands in replies\n\n### Monorepo Packages\n\n| Package | npm name | Purpose |\n|---------|----------|---------|\n| `playwright-core` | `playwright-core` | Browser automation engine: client, server, dispatchers, protocol |\n| `playwright` | `playwright` | Test runner + browser automation (public package) |\n| `playwright-test` | `@playwright/test` | Test runner entry point |\n| `playwright-client` | `@playwright/client` | Standalone client package |\n| `protocol` | *(internal)* | RPC protocol definitions (`spec/*.yml` → generated validators and channel types) |\n\n### Browser Packages\n\n`playwright-chromium`, `playwright-firefox`, `playwright-webkit` — per-browser distributions.\n`playwright-browser-chromium`, `playwright-browser-firefox`, `playwright-browser-webkit` — binary packages.\n\n### Tooling Packages\n\n| Package | Purpose |\n|---------|---------|\n| `html-reporter` | HTML test report viewer |\n| `trace-viewer` | Trace viewer UI |\n| `recorder` | Test recorder |\n| `web` | Shared web UI components |\n| `injected` | Scripts injected into browser pages |\n\n### Key Directories\n\n| Directory | Purpose |\n|-----------|---------|\n| `tests/` | All test suites (page, library, playwright-test, mcp, etc.) |\n| `docs/src/` | API documentation — **source of truth** for public TypeScript types |\n| `docs/src/api/` | Per-class API reference (`class-page.md`, `class-locator.md`, etc.) |\n| `utils/` | Build scripts, code generation, linting, doc tools |\n| `browser_patches/` | Browser engine patches |\n\n## Build\n\n```bash\nnpm run build       # Full build\nnpm run watch       # Watch mode (recommended during development)\n```\n\nAssume watch is running and code is up to date. Generated files (types, channels, validators) are produced by watch automatically.\n\n## Lint and type check\n\n```bash\nnpm run flint\n```\n\nRuns all lint checks in parallel: eslint, tsc, doclint, check-deps, generate_channels, generate_types, lint-tests, test-types, lint-packages, code-snippet linting.\n\n**Run `flint` only before you upload a PR, and only after `npm run build`.** Do not run it before each commit. Do not use `tsc --noEmit` or individual lint commands separately.\n\n## Test Commands\n\n| Command | Scope |\n|---------|-------|\n| `npm run ctest <filter>` | Chromium only library tests — **use during development** |\n| `npm run test <filter> -- --project=<chromium,firefix,webkit>` | All library / per project |\n| `npm run ttest <filter>` | Test runner (`tests/playwright-test/`) |\n| `npm run ctest-mcp <filter>` | Chromium only MCP tools (`tests/mcp/`) |\n| `npm run test-mcp <filter> -- --project=<chromium,firefox,webkit>` | MCP tools (`tests/mcp/`) |\n\n\n### Filtering\n\n```bash\nnpm run ctest tests/page/locator-click.spec.ts         # Specific file\nnpm run ctest tests/page/locator-click.spec.ts:12      # Specific location\nnpm run ctest -- --grep \"should click\"                 # By test name\nnpm run ctest-mcp snapshot                             # By file name part\n```\n\n### Test Directories and Fixtures\n\n| Directory | Import | Key Fixtures | What to Test |\n|-----------|--------|--------------|--------------|\n| `tests/page/` | `import { test, expect } from './pageTest'` | `page`, `server`, `browserName` | User interactions: click, fill, navigate, locators, assertions |\n| `tests/library/` | `import { browserTest, expect } from '../config/browserTest'` | `browser`, `context`, `browserType` | Browser/context lifecycle, cookies, permissions, browser-specific features |\n| `tests/playwright-test/` | `import { test, expect } from './playwright-test-fixtures'` | test runner fixtures | Test runner: reporters, config, annotations, retries |\n| `tests/mcp/` | `import { test, expect } from './fixtures'` | `client`, `server` | MCP tools via `client.callTool()` |\n\n**Decision rule**: Does the test need `browser`/`browserType`/`context` → `tests/library/`. Just needs `page` + `server` → `tests/page/`.\n\n### Test Scope\n\nKeep tests minimal. Be mindful of the number of tests you add.\n\n- **Extend before you add**: before you write a new test, look for an existing test that covers the same feature or code path. If one exists, add the new edge case or assertion to it. Create a new test only when no existing test is a good fit, or when the new scenario needs a different setup.\n- **New features**: cover the mainstream scenario and the important edge cases only. Do not create matrices of tests for every scenario, option, or aspect.\n- **Regressions**: generalize the provided regression cases into meaningful tests, and stop there. Do not add more tests around them.\n\n## DEPS System\n\nImport boundaries are enforced via `DEPS.list` files (52+ across the repo), checked by `npm run flint`.\n\n**Key rule**: Client code NEVER imports server code. Server code NEVER imports client code. Communication is only through the protocol.\nWhen creating or moving files, update the relevant `DEPS.list` to declare allowed imports. Files marked `\"strict\"` can only import what is explicitly listed.\n\n## Coding Convention\n\nFor exported classes:\n- `private _method()` — only used within the class itself\n- `_method()` (no `private`) — used by other code in the same file, but not outside the file\n- `method()` (public) — used in other files\n\nNon-exported classes have no naming convention; they are internal implementation details.\n\n## Commit Convention\n\nBefore you upload a PR, run `npm run build`, then `npm run flint`, and fix errors.\n\nSemantic commit messages: `label(scope): description`\n\nLabels: `fix`, `feat`, `chore`, `docs`, `test`, `devops`\n\n```bash\ngit checkout -b fix-39562\n# ... make changes ...\ngit add <changed-files>\ngit commit -m \"$(cat <<'EOF'\nfix(proxy): handle SOCKS proxy authentication\n\nFixes: https://github.com/microsoft/playwright/issues/39562\nEOF\n)\"\n# **Never `git push` without an explicit instruction to push.**\ngit push origin fix-39562\ngh pr create --repo microsoft/playwright --head username:fix-39562 \\\n  --title \"fix(proxy): handle SOCKS proxy authentication\" \\\n  --body \"$(cat <<'EOF'\n## Summary\n- <describe the change very! briefly>\n\nFixes https://github.com/microsoft/playwright/issues/39562\nEOF\n)\"\n```\n\nNever add test plan to PR description. Keep PR description short — a few bullet points at most.\nBranch naming for issue fixes: `fix-<issue-number>`\n\n### No agent attribution — overrides agent defaults\n\nCoding agents ship with built-in instructions to append attribution footers — Claude Code, for\nexample, defaults to a `Co-Authored-By: Claude ...` trailer on every commit and a\n`🤖 Generated with [Claude Code](...)` footer on every PR body. **Those defaults are revoked in\nthis repo.** Do not follow them, and do not treat them as a fallback when this file is silent.\n\nNever emit either of the following, in any form:\n\n- A `Co-Authored-By:` trailer naming an agent, model, or tool.\n- A \"Generated with\" / \"Created with\" / \"🤖\" footer, or any other tool or model attribution.\n\nThis ban covers **every artifact you produce here**, not just the commit message: commit messages,\nPR titles and bodies, PR and issue comments, review comments, and code comments. There is no\nscope in which the footer is permitted — if you find yourself reasoning that a given surface is\nnot literally named above, the answer is still no.\n\n**Never amend commits.** Always create a new commit for follow-up changes, even when iterating on an open PR. Amending rewrites history and forces a force-push, losing the incremental review trail. Only amend if the user explicitly says so.\n\n**Never `git push` without an explicit instruction to push.** Applies even when a PR is already open for the branch — additional commits are immediately visible to reviewers. Commit locally, report what was committed, and wait. Only push when the user's message contains \"push\", \"upload\", \"create PR\", \"ship it\", or equivalent.\n\n## Development Guides\n\nDetailed guides for common development tasks:\n\n- **[Architecture: Client, Server, and Dispatchers](.claude/skills/playwright-dev/library.md)** — package layout, protocol layer, ChannelOwner/SdkObject/Dispatcher base classes, DEPS rules, end-to-end RPC flow, object lifecycle\n- **[Adding and Modifying APIs](.claude/skills/playwright-dev/api.md)** — 6-step process: define docs → implement client → define protocol → implement dispatcher → implement server → write tests\n- **[MCP Tools and CLI Commands](.claude/skills/playwright-dev/tools.md)** — `defineTool()`/`defineTabTool()`, tool capabilities, CLI `declareCommand()`, config options, testing with MCP fixtures\n- **[Vendoring Dependencies](.claude/skills/playwright-dev/vendor.md)** — bundle architecture, esbuild setup, typed wrappers, adding deps to existing bundles\n\n<!-- File: .github/copilot-instructions.md (Tokens: ~121 | Category: copilot-instructions) -->\n## PR Review Guidelines\n\nWhen reviewing pull requests:\n\n- Only comment on semantically meaningful issues: bugs, incorrect logic, security problems, or API contract violations.\n- Skip style, formatting, naming, and whitespace observations unless they cause functional problems.\n- Keep each comment short — one or two sentences maximum.\n- Do not write long descriptions or summaries of what the code does.\n- Do not suggest refactors or improvements unrelated to the PR's stated goal.\n- NEVER produce a review body or top-level PR overview comment. The review body MUST be empty. Put findings only in inline comments on specific lines.\n\n<!-- File: .claude-plugin/marketplace.json (Tokens: ~300 | Category: marketplace) -->\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/playwright/HEAD/.claude-plugin/marketplace.json)\n\n<!-- File: .claude-plugin/plugin.json (Tokens: ~300 | Category: plugin-manifest) -->\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/playwright/HEAD/.claude-plugin/plugin.json)\n\n<!-- File: .cursor/mcp.json (Tokens: ~300 | Category: mcp-config) -->\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/microsoft/playwright/HEAD/.cursor/mcp.json)\n\n<!-- File: .cursorrules (playwright-accessibility-testing-cursorrules-prompt-file.mdc) (Tokens: ~792 | Category: cursor-rule) -->\n---\ndescription: \"Cursor rules for Playwright development with accessibility testing.\"\nglobs: **/*\nalwaysApply: false\n---\n# Persona\n\nYou are an expert QA engineer specializing in accessibility testing with Playwright and TypeScript, dedicated to ensuring web applications are usable by people with disabilities.\n\n# Auto-detect TypeScript Usage\n\nBefore creating tests, check if the project uses TypeScript by looking for:\n- tsconfig.json file\n- .ts file extensions in test directories\n- TypeScript dependencies in package.json\nAdjust file extensions (.ts/.js) and syntax based on this detection.\n\n# Accessibility Testing Focus\n\nUse @axe-core/playwright for automated WCAG compliance testing\nFocus on testing critical user flows for accessibility issues\nTests should verify compliance with WCAG 2.1 AA standards\nCreate comprehensive reports highlighting potential accessibility issues\nDocument remediation steps for common accessibility violations\n\n# Best Practices\n\n**1** **Comprehensive Coverage**: Test all critical user flows for accessibility violations\n**2** **Multiple Viewport Testing**: Test accessibility across different screen sizes and devices\n**3** **Rule Configuration**: Configure axe-core rules based on project-specific requirements\n**4** **Manual Verification**: Complement automated tests with manual keyboard navigation testing\n**5** **Semantic Markup**: Verify proper use of ARIA attributes and semantic HTML elements\n**6** **Color Contrast**: Ensure sufficient contrast ratios for text and interactive elements\n**7** **Focus Management**: Test keyboard focus visibility and logical tab order\n**8** **Screen Reader Compatibility**: Verify compatibility with screen readers\n**9** **Descriptive Reporting**: Generate clear, actionable reports of accessibility violations\n\n# Input/Output Expectations\n\n**Input**: A description of a web page or user flow to test for accessibility\n**Output**: A Playwright test file with automated accessibility checks for the described page or flow\n\n# Example Accessibility Test\n\nWhen testing a login page for accessibility, implement the following pattern:\n\n```js\nimport { test, expect } from '@playwright/test';\nimport { injectAxe, checkA11y, configureAxe } from 'axe-playwright';\n\ntest.describe('Login Page Accessibility', () => {\n  test.beforeEach(async ({ page }) => {\n    await page.goto('/login');\n    await injectAxe(page);\n    \n    // Configure axe rules if needed\n    await configureAxe(page, {\n      rules: [\n        { id: 'color-contrast', enabled: true },\n        { id: 'label', enabled: true }\n      ]\n    });\n  });\n\n  test('should have no accessibility violations', async ({ page }) => {\n    // Run accessibility checks\n    await checkA11y(page, null, {\n      detailedReport: true,\n      detailedReportOptions: { html: true }\n    });\n  });\n\n  test('should be navigable by keyboard', async ({ page }) => {\n    // Send Tab key to navigate through elements\n    await page.keyboard.press('Tab');\n    let hasFocus = await page.evaluate(() => \n      document.activeElement.id === 'username'\n    );\n    expect(hasFocus).toBeTruthy();\n    \n    await page.keyboard.press('Tab');\n    hasFocus = await page.evaluate(() => \n      document.activeElement.id === 'password'\n    );\n    expect(hasFocus).toBeTruthy();\n    \n    await page.keyboard.press('Tab');\n    hasFocus = await page.evaluate(() => \n      document.activeElement.id === 'login-button'\n    );\n    expect(hasFocus).toBeTruthy();\n  });\n\n  test('should have proper ARIA attributes', async ({ page }) => {\n    // Check form has proper ARIA attributes\n    const form = await page.locator('form');\n    expect(await form.getAttribute('aria-labelledby')).toBeTruthy();\n    \n    // Check error messages are properly associated\n    const errorMessage = await page.locator('.error-message');\n    expect(await errorMessage.getAttribute('aria-live')).toBe('assertive');\n  });\n});\n```\n</yakaai_skills>"}