@athenaflow/plugin-e2e-test-builder 2.0.9 → 2.0.10

package/dist/2.0.9/claude/plugin/skills/write-test-code/agents/openai.yaml

@@ -1,10 +0,0 @@
-interface:
-  display_name: "Implement Playwright Tests"
-  short_description: "Implement or refactor executable Playwright tests from a scenario or spec"
-  default_prompt: "Write or update Playwright E2E tests for this scenario or TC-ID spec."
-
-dependencies:
-  tools:
-    - type: "mcp"
-      value: "agent-web-interface"
-      description: "Browser automation MCP used when selectors or live behavior need verification"

package/dist/2.0.9/claude/plugin/skills/write-test-code/references/anti-patterns.md

@@ -1,88 +0,0 @@
-# Anti-Patterns: Detailed Explanations and Fix Strategies
-
-## 1. Raw CSS selectors
-Use semantic locators (`getByRole`, `getByLabel`, `getByTestId`) instead of CSS selectors. CSS selectors are brittle and break when markup changes.
-
-**Why:** A class rename, component refactor, or CSS-in-JS migration breaks every CSS-based selector overnight. Semantic locators survive these changes because they target accessible roles and labels, not implementation details.
-
-**Fix:** Replace `page.locator('.submit-btn')` with `page.getByRole('button', { name: /submit/i })`. Follow the locator strategy hierarchy in the main skill.
-
-## 2. `waitForTimeout()`
-Use proper assertions and event-driven waits. `waitForTimeout()` adds arbitrary delays that slow tests and mask timing issues.
-
-**Why:** A 2-second sleep that works locally may be too short in CI (slower machines) or too long everywhere (wasting time). It also hides the real question: "what am I actually waiting for?"
-
-**Fix:** Replace with `waitForResponse` for API-dependent UI, `expect(el).toBeVisible()` for element appearance, or `expect(spinner).toBeHidden()` for loading states.
-
-## 3. Fragile `.nth()` / `.first()`
-Scope locators to a container instead of relying on position. If unavoidable, add a comment explaining why.
-
-**Why:** Element order can change when the page adds a banner, reorders a list, or renders asynchronously. `.first()` silently picks the wrong element, causing false passes or mysterious failures.
-
-**Fix:** Use `.filter({ hasText: 'Specific Item' })` or scope to a container: `page.locator('[data-testid="cart"]').getByRole('button')`.
-
-## 4. Exact long text matches
-Use regex with key words instead of matching entire strings. Marketing copy and UI text change frequently.
-
-**Why:** A copywriter changes "Sign up for free today!" to "Create your free account" and every test matching the full string breaks, even though the feature works fine.
-
-**Fix:** Use `page.getByText(/sign up/i)` or `page.getByRole('button', { name: /free/i })` — match the stable semantic keywords.
-
-## 5. Unscoped locators
-Scope locators to `main`, `nav`, `dialog`, or other containers when possible. Global locators match unintended elements.
-
-**Why:** A page-wide `getByRole('button', { name: /submit/i })` may match a submit button in the header, footer, or a hidden modal — not just the one in your form. This causes the wrong click or ambiguous locator errors.
-
-**Fix:** Scope first: `page.locator('main').getByRole('button', { name: /submit/i })` or `page.locator('[role="dialog"]').getByRole('button')`.
-
-## 6. Login via UI in every test
-Use `storageState` or API-based auth setup. UI login in every test wastes time and creates coupling to the login flow.
-
-**Why:** If every test clicks through the login form, a single login page change breaks the entire suite. It also adds 3-10 seconds per test — multiplied across hundreds of tests, this becomes significant CI time.
-
-**Fix:** Log in once in `globalSetup`, save `storageState` to a JSON file, and reuse it. See `references/auth-patterns.md` for the four auth strategies.
-
-## 7. UI clicks to set up test data
-Use API requests for data seeding. UI setup is 10-50x slower and more fragile than API calls.
-
-**Why:** Creating a product via the admin UI takes 15+ seconds and 10+ actions. An API call takes 200ms and one line. UI setup also couples your test to two features instead of one — if the admin form breaks, your unrelated cart test fails too.
-
-**Fix:** Use the `request` fixture: `await request.post('/api/products', { data: { ... } })`. See `references/api-setup-teardown.md`.
-
-## 8. No error path tests
-Every feature needs at least one failure scenario test. Cover server errors (500), network timeouts, and empty states.
-
-**Why:** Happy-path-only suites give false confidence. The app may crash on a 500, show a blank screen on empty data, or hang on a timeout — none of which are caught without explicit error path tests.
-
-**Fix:** Use `page.route()` to mock failures. At minimum: one 500 response, one timeout (`route.abort('timedout')`), one empty state (`route.fulfill({ json: { items: [] } })`). See `references/network-interception.md`.
-
-## 9. Hardcoded test data
-NEVER embed real entity IDs (`'ACC-SUB-2026-00025'`), real user names (`'Anas Client 73'`), real monetary amounts, or environment-specific strings in test code. Instead:
-- Create data via API in `beforeEach` and capture the returned ID
-- Use `Date.now()` or `crypto.randomUUID()` suffixes for uniqueness
-- Read values from `process.env` or a test data module
-- For read-only assertions on existing data, use pattern matchers (`expect(text).toMatch(/ACC-SUB-\d{4}-\d{5}/)`) instead of exact values
-
-If you find yourself typing a specific ID or name into test code, STOP — that is a hardcoded value.
-
-## 10. Tests depending on execution order
-Each test must be independently runnable. Never rely on state left by a previous test.
-
-## 11. `expect(await el.isVisible()).toBe(true)`
-Use `await expect(el).toBeVisible()` instead. The Playwright assertion auto-retries, while the manual pattern checks once and fails on timing.
-
-## 12. `{ force: true }` on clicks/checks
-Hides real interaction problems (overlapping elements, not scrolled into view, disabled state). Diagnose the root cause instead: use `scrollIntoViewIfNeeded()`, wait for overlay to disappear, or wait for element to be enabled. Only acceptable when interacting with a custom widget that Playwright cannot natively trigger (document why in a comment).
-
-## 13. `waitForLoadState('networkidle')` as default strategy
-`networkidle` waits for 500ms of no network activity, which breaks on long-polling, WebSockets, analytics beacons, or chat widgets. Use it ONLY for initial full-page loads where no streaming/polling exists. For post-action waits, use `waitForResponse` targeting the specific API call, or assert directly on the resulting UI state (Playwright auto-retries).
-
-## 14. CSS utility class selectors (Tailwind, Bootstrap, etc.)
-`button.rounded-l-lg`, `.flex.items-center`, `.bg-primary` are styling concerns that change during refactors. Treat ALL utility framework classes as volatile — never use them as selectors. If no semantic locator works, request a `data-testid` from the dev team.
-
-## 15. Asserting exact server-computed values
-`expect(revenue).toHaveText('12450')` will break when data changes. For dashboard counters, totals, and aggregates:
-- Assert the element exists and contains a number (`toMatch(/\$[\d,]+/)`)
-- Assert non-zero or within a range
-- Assert format correctness (`/^\d{1,3}(,\d{3})*$/`)
-- If exact value matters, seed the data via API first so you control the expected value

package/dist/2.0.9/claude/plugin/skills/write-test-code/references/auth-patterns.md

@@ -1,63 +0,0 @@
-# Authentication Setup Patterns
-
-Choose the right auth strategy based on the project's needs.
-
-## Strategy 1: storageState (Recommended for most projects)
-
-Log in once in global setup, save cookies/localStorage to a JSON file, and reuse across all tests:
-
-```typescript
-// global-setup.ts
-import { chromium, FullConfig } from '@playwright/test';
-
-async function globalSetup(config: FullConfig) {
-  const browser = await chromium.launch();
-  const page = await browser.newPage();
-  await page.goto('/login');
-  await page.getByLabel(/email/i).fill(process.env.TEST_USER_EMAIL!);
-  await page.getByLabel(/password/i).fill(process.env.TEST_USER_PASSWORD!);
-  await page.getByRole('button', { name: /sign in/i }).click();
-  await page.waitForURL('/dashboard');
-  await page.context().storageState({ path: 'tests/.auth/user.json' });
-  await browser.close();
-}
-export default globalSetup;
-```
-
-Reference in config: `use: { storageState: 'tests/.auth/user.json' }`
-
-## Strategy 2: Worker-scoped fixture (for parallel workers needing separate accounts)
-
-```typescript
-export const test = base.extend<{}, { workerStorageState: string }>({
-  storageState: ({ workerStorageState }, use) => use(workerStorageState),
-  workerStorageState: [async ({ browser }, use, testInfo) => {
-    const page = await browser.newPage({ storageState: undefined });
-    // Login with worker-specific account...
-    const path = `tests/.auth/worker-${testInfo.parallelIndex}.json`;
-    await page.context().storageState({ path });
-    await use(path);
-    await page.close();
-  }, { scope: 'worker' }],
-});
-```
-
-## Strategy 3: Multi-role testing (admin + user in same test)
-
-```typescript
-test('TC-ADMIN-001: Admin sees user profile', async ({ browser }) => {
-  const adminContext = await browser.newContext({ storageState: 'tests/.auth/admin.json' });
-  const userContext = await browser.newContext({ storageState: 'tests/.auth/user.json' });
-  const adminPage = await adminContext.newPage();
-  const userPage = await userContext.newPage();
-  // Interact with both pages...
-  await adminContext.close();
-  await userContext.close();
-});
-```
-
-## Strategy 4: Per-test login
-
-Only when testing login itself or permission-specific scenarios.
-
-Never hardcode tokens. Use environment variables or `.env.test`.

package/dist/2.0.9/claude/plugin/skills/write-test-code/references/mapping-tables.md

@@ -1,56 +0,0 @@
-# Mapping Tables
-
-Standard translations for converting journey specs and exploration results to Playwright API calls.
-
-## Scope-to-Locator
-
-| Journey Scope | Playwright Scoping |
-|---------------|-------------------|
-| `page` | No scoping needed |
-| `header` | `page.locator('header')` |
-| `main` | `page.locator('main')` |
-| `nav` | `page.locator('nav')` |
-| `dialog` | `page.locator('[role="dialog"]')` |
-
-## Action-to-Playwright
-
-| Journey Action | Playwright Code |
-|----------------|-----------------|
-| `goto` | `await page.goto(url)` |
-| `click` | `await locator.click()` |
-| `fill` | `await locator.fill(value)` |
-| `select` | `await locator.selectOption(value)` |
-| `assert` | `await expect(locator).toBeVisible()` |
-
-## Assertion Mapping
-
-| Observed Effect | Playwright Assertion |
-|----------------|---------------------|
-| `url changed to /cart` | `await expect(page).toHaveURL(/cart/)` |
-| `text 'Added' visible` | `await expect(page.getByText(/added/i)).toBeVisible()` |
-| `radio 256GB checked` | `await expect(locator).toBeChecked()` |
-| `button now enabled` | `await expect(locator).toBeEnabled()` |
-
-## Target Kind to Locator
-
-| Target Kind | Value Pattern | Playwright Locator |
-|-------------|--------------|-------------------|
-| `role` | `button name~Add to Bag` | `getByRole('button', { name: /add to bag/i })` |
-| `role` | `radio name~256GB` | `getByRole('radio', { name: /256gb/i })` |
-| `label` | `Email address` | `getByLabel(/email address/i)` |
-| `testid` | `checkout-button` | `getByTestId('checkout-button')` |
-
-## Low Confidence Handling (<0.7)
-
-When journey step confidence is low:
-1. Add extra assertions to verify state
-2. Include fallback locators as comments
-3. Consider retry logic for flaky interactions
-
-```typescript
-// Primary locator
-const storageRadio = page.getByRole('radio', { name: /256gb/i });
-// Fallback: page.getByLabel(/256gb/i)
-await storageRadio.click();
-await expect(storageRadio).toBeChecked({ timeout: 5000 });
-```

package/dist/2.0.9/claude/plugin/skills/write-test-code/references/network-interception.md

@@ -1,56 +0,0 @@
-# Network Interception and Error Path Testing
-
-## Network Interception
-
-Use `page.route()` to intercept and mock network requests for deterministic error testing.
-
-**Mock server errors:**
-```typescript
-await page.route('**/api/checkout', route =>
-  route.fulfill({ status: 500, body: JSON.stringify({ error: 'Payment declined' }) })
-);
-```
-
-**Patch real responses (modify, don't replace):**
-```typescript
-await page.route('**/api/products', async route => {
-  const response = await route.fetch();
-  const json = await response.json();
-  json.results = json.results.slice(0, 1); // reduce to 1 item
-  await route.fulfill({ response, json });
-});
-```
-
-**Assert backend was called:**
-```typescript
-const [response] = await Promise.all([
-  page.waitForResponse(resp =>
-    resp.url().includes('/api/order') && resp.status() === 201
-  ),
-  page.getByRole('button', { name: /place order/i }).click(),
-]);
-expect(response.status()).toBe(201);
-```
-
-**Block heavy resources to speed up tests:**
-```typescript
-await page.route('**/*.{png,jpg,jpeg,gif,svg}', route => route.abort());
-```
-
-## Error Path Testing
-
-Every feature needs error path tests. Use network interception (see above) to simulate failures. At minimum, every feature test suite should cover:
-
-- **Server error** — `route.fulfill({ status: 500, ... })` — verify error UI appears
-- **Network timeout** — `route.abort('timedout')` — verify retry option or error message
-- **Empty state** — `route.fulfill({ status: 200, json: { items: [] } })` — verify empty state UI
-
-```typescript
-test('TC-DASHBOARD-005: Shows empty state when no data', async ({ page }) => {
-  await page.route('**/api/items', route =>
-    route.fulfill({ status: 200, json: { items: [] } })
-  );
-  await page.goto('/dashboard');
-  await expect(page.getByText(/no items/i)).toBeVisible();
-});
-```

package/dist/2.0.9/codex/plugin/skills/add-e2e-tests/agents/openai.yaml

@@ -1,10 +0,0 @@
-interface:
-  display_name: "Run Full E2E Workflow"
-  short_description: "Orchestrate browser-led E2E work from exploration to verified tests"
-  default_prompt: "Run the full E2E workflow for this feature: maintain a concise progress tracker, explore the live product first, then plan, spec, review, implement, and verify the Playwright tests."
-
-dependencies:
-  tools:
-    - type: "mcp"
-      value: "agent-web-interface"
-      description: "Browser automation MCP used to explore the site and verify flows"

package/dist/2.0.9/codex/plugin/skills/add-e2e-tests/references/authentication.md

@@ -1,8 +0,0 @@
-# Authentication Handling for E2E Tests
-
-If the target feature requires login or any form of authentication:
-
-1. **Check existing infrastructure** — look for existing test fixtures, environment variables, or auth setup files that already handle authentication. Load the `analyze-test-codebase` skill to find auth patterns.
-2. **Ask the user if no auth setup exists** — request credentials or an auth strategy (stored auth state, API tokens, test accounts). Do not proceed with tests that require login until auth is resolved.
-3. **Never hardcode credentials** — use environment variables, Playwright's `storageState`, or the project's existing auth fixture pattern.
-4. **Handle mid-session auth discovery** — if you discover auth is needed mid-session (e.g., a page redirects to login), ask the user immediately and add auth setup as a prerequisite task.

package/dist/2.0.9/codex/plugin/skills/add-e2e-tests/references/error-recovery.md

@@ -1,43 +0,0 @@
-# Error Recovery for Infrastructure Failures
-
-When infrastructure failures occur during E2E test building, follow the general pattern: diagnose, attempt one known fix, if still stuck record in tracker and ask the user.
-
-## Browser MCP unavailable
-
-The browser MCP server (`agent-web-interface`) must be running for site exploration.
-
-1. Verify the MCP server is configured in the project (check `.mcp.json` or plugin config).
-2. Ask the user to confirm the MCP server is running or to restart it.
-3. If unreachable after user intervention, mark the session as blocked: `<!-- E2E_BLOCKED: browser MCP server unreachable -->`.
-
-## Boilerplate clone fails
-
-When `git clone git@github.com:lespaceman/playwright-typescript-e2e-boilerplate.git` fails:
-
-1. Check if SSH keys are configured — the error will usually indicate `Permission denied (publickey)`.
-2. Fall back to HTTPS: `git clone https://github.com/lespaceman/playwright-typescript-e2e-boilerplate.git`.
-3. If both fail, ask the user to verify network access and GitHub authentication.
-
-## npm install fails
-
-1. Check the Node.js version — Playwright requires Node 18+. Run `node --version`.
-2. Clear the npm cache: `npm cache clean --force`.
-3. Check for lockfile conflicts — if both `package-lock.json` and `yarn.lock` exist, ask the user which package manager to use.
-4. If dependency resolution fails, try `npm install --legacy-peer-deps` as a fallback.
-
-## Playwright browser install fails
-
-When `npx playwright install --with-deps chromium` fails:
-
-1. Try installing just chromium without system deps: `npx playwright install chromium`.
-2. Check permissions — on Linux, system dependency installation may require sudo.
-3. If behind a corporate proxy, ask the user for proxy configuration.
-4. As a last resort, ask the user to run the install command manually and confirm when done.
-
-## General pattern
-
-For any infrastructure failure not listed above:
-
-1. **Diagnose** — read the error message carefully, check logs, identify the root cause.
-2. **Attempt one known fix** — apply the most likely solution based on the error.
-3. **If still stuck** — record the full error output and diagnostic steps taken in the tracker, then ask the user for help. Do not loop through multiple speculative fixes.

package/dist/2.0.9/codex/plugin/skills/add-e2e-tests/references/scaffolding.md

@@ -1,12 +0,0 @@
-# Scaffolding Playwright from Boilerplate
-
-If Playwright is not set up in the target project, follow this procedure:
-
-1. Clone `git@github.com:lespaceman/playwright-typescript-e2e-boilerplate.git` into a temporary directory.
-2. Copy config, fixtures, pages, and utils into the project. Do not overwrite existing files.
-3. Update `baseURL` to the target URL and remove example tests.
-   - **Test execution strategy:** If the project needs role-based or category-based test filtering, configure it via Playwright `--grep` tags or file naming conventions (`*.admin.spec.ts`), NOT via `testIgnore` regex patterns. A `testIgnore` regex becomes a maintenance trap — every new test file requires updating the regex. If the boilerplate includes a `testIgnore` regex, replace it with tag-based filtering.
-4. Merge devDependencies into `package.json`.
-5. Run `npm install && npx playwright install --with-deps chromium`.
-6. Clean up the temp clone.
-7. Log all scaffolding steps in the tracker.

package/dist/2.0.9/codex/plugin/skills/add-e2e-tests/references/tracker-template.md

@@ -1,53 +0,0 @@
-# Tracker Template: e2e-tracker.md
-
-Use this as a starting template when creating the tracker file. Adapt sections as needed.
-
----
-
-```markdown
-# E2E Test Tracker
-
-## Goal
-
-- **URL:** https://myapp.com/checkout
-- **Feature:** Checkout flow with cart, shipping, and payment
-- **Slug:** checkout
-
-## Progress
-
-### Session 1 — 2026-04-01
-
-- Analyzed codebase: Playwright 1.42, TypeScript, existing auth fixture in `tests/fixtures/auth.ts`
-- Browsed checkout flow: 4-step wizard (cart review, shipping, payment, confirmation)
-- Discovered 3 form validation states per step
-- Generated test spec: `test-cases/checkout.md` with TC-CHECKOUT-001 through TC-CHECKOUT-012
-- Review gate passed with warnings (TC-CHECKOUT-008 needs clarification on coupon edge case)
-
-### Session 2 — 2026-04-02
-
-- Wrote `tests/checkout.spec.ts` covering TC-CHECKOUT-001 through TC-CHECKOUT-012
-- Code review gate passed
-- Ran tests: 10/12 passing, 2 failing (TC-CHECKOUT-006: selector stale, TC-CHECKOUT-011: timeout)
-- Fixed TC-CHECKOUT-006: updated selector from `.price` to `[data-testid="cart-total"]`
-- Fixed TC-CHECKOUT-011: added `waitForResponse` before assertion
-
-## Remaining
-
-- Re-run full suite to confirm fixes
-- Verify TC-ID coverage: all 12 specs should map to test code
-
-## Next Steps
-
-- Run `npx playwright test tests/checkout.spec.ts --reporter=list` and record output
-- If all green, mark complete
-- If failures remain, diagnose with `fix-flaky-tests` skill
-
-<!-- E2E_COMPLETE -->
-```
-
----
-
-**Terminal markers** (write as the last line of the tracker when appropriate):
-
-- `<!-- E2E_COMPLETE -->` — all tests pass, all TC-IDs covered, work is done
-- `<!-- E2E_BLOCKED: reason -->` — unrecoverable blocker prevents further progress (e.g., `<!-- E2E_BLOCKED: login requires 2FA token we cannot automate -->`)

package/dist/2.0.9/codex/plugin/skills/analyze-test-codebase/SKILL.md

@@ -1,142 +0,0 @@
----
-name: analyze-test-codebase
-description: >
-  Scans and reports on an existing Playwright test codebase. This skill should be used to inspect
-  the current Playwright setup before writing, reviewing, or fixing tests, and should be loaded
-  early when working in a new project to understand existing patterns. Covers: Playwright config,
-  page objects, fixtures, helpers, auth/globalSetup patterns, test conventions, and directory
-  structure. Triggers: "understand", "check", "show me", "inspect", or "analyze"
-  the current test setup, config, infrastructure, patterns, or conventions. In the full add-tests
-  workflow, this skill serves as an early read-only analysis sub-step before planning detailed
-  coverage or writing code. This skill examines existing files and outputs a structured report.
-  It does NOT write or fix tests, install Playwright, or explore live websites — for live site
-  exploration, use agent-web-interface-guide instead.
-allowed-tools: Read Glob Grep Bash
----
-
-# Analyze Test Codebase
-
-Scan and analyze an existing Playwright test codebase to understand its conventions, configuration, and patterns before writing new tests.
-
-## Workflow
-
-1. **Locate Playwright configuration** — search for `playwright.config.ts`, `playwright.config.js`, or `playwright.config.mjs` in the project root and common subdirectories.
-
-2. **Extract configuration details**:
-   - `baseURL` — the target application URL
-   - `testDir` — where tests live
-   - `projects` — browser/device configurations
-   - `use` — default options (viewport, headless, trace, screenshot)
-   - `webServer` — if Playwright starts the app
-   - `globalSetup` / `globalTeardown` — auth or data seeding scripts
-   - `reporter` — configured reporters
-
-3. **Scan test directory structure**:
-   ```
-   Glob for **/*.spec.ts, **/*.test.ts, **/*.spec.js, **/*.test.js
-   ```
-   - Count total test files
-   - Identify naming conventions (`.spec.ts` vs `.test.ts`)
-   - Map directory organization (by feature? by page? flat?)
-
-4. **Detect patterns in existing tests** — read 2-3 representative test files and identify:
-   - **Locator strategy**: `getByRole`, `getByTestId`, CSS selectors, XPath
-   - **Wait strategy**: auto-waits, explicit `waitFor*`, any `waitForTimeout` (flag these)
-   - **Test structure**: AAA pattern, describe/test nesting, use of `test.step`
-   - **Data management**: fixtures, test data files, factory functions
-   - **Page Objects**: POM pattern usage, fixture-based injection
-   - **Auth handling**: `storageState`, global setup, per-test login
-   - **Custom fixtures**: extended `test` with custom fixtures
-   - **Helper utilities**: shared functions, custom assertions
-   - **Network mocking**: `page.route()` usage, HAR recording (`routeFromHAR`), API interceptors
-   - **Visual regression**: `toHaveScreenshot()`, `toMatchSnapshot()`, snapshot directories
-   - **Accessibility testing**: `@axe-core/playwright` usage, custom a11y assertions
-   - **Cross-browser config**: multiple projects in playwright.config (chromium, firefox, webkit)
-   - **Retry configuration**: `retries` count, trace settings (`on-first-retry`)
-   - **Parallelism**: `fullyParallel`, `workers` count, test isolation strategy
-
-5. **Check for supporting infrastructure**:
-   - `fixtures/` or `helpers/` directories
-   - `pages/` or `pom/` (Page Object Model)
-   - `.env` or `.env.test` files (test-specific environment configuration)
-   - CI configuration (`.github/workflows/`, `Jenkinsfile`, etc.)
-   - `package.json` scripts for running tests
-   - `*.har` files or HAR directories (recorded API responses for mocking)
-   - Snapshot directories (`__snapshots__`, `screenshots/`) for visual regression baselines
-   - Docker or `docker-compose` for test environment setup
-   - Global setup/teardown scripts — what they do (auth, seeding, cleanup)
-
-6. **Generate report** — output a structured summary:
-
-```markdown
-## Test Codebase Analysis
-
-### Framework
-- **Playwright** version X.Y.Z
-- Config: `playwright.config.ts`
-- Test directory: `tests/`
-
-### Conventions
-- File naming: `*.spec.ts`
-- Locator preference: getByRole > getByTestId
-- Structure: describe blocks by feature
-- Page Objects: Yes, in `tests/pages/`
-- Custom fixtures: Yes, in `tests/fixtures/`
-
-### Auth
-- Method: storageState via global setup
-- Auth file: `tests/.auth/user.json`
-
-### Existing Coverage
-- Total test files: N
-- Feature areas covered: [list]
-- Test count: ~N tests
-
-### Network Mocking
-- Method: page.route() / HAR / none
-- Patterns: [list any existing mocking patterns]
-
-### Visual Testing
-- Enabled: Yes/No
-- Tool: toHaveScreenshot() / third-party / none
-- Baseline directory: [path if exists]
-
-### Accessibility Testing
-- Enabled: Yes/No
-- Tool: @axe-core/playwright / custom assertions / none
-
-### Cross-Browser & CI
-- Browser projects: [list from config]
-- Retries: N (CI) / N (local)
-- Workers: N / fullyParallel: Yes/No
-- CI platform: GitHub Actions / Jenkins / none detected
-- Trace: [setting from config]
-
-### Recommendations for New Tests
-- Follow existing `*.spec.ts` naming
-- Use page objects from `tests/pages/`
-- Import test data from `tests/fixtures/testData.ts`
-- Use `baseURL` for navigation (relative paths)
-- Auth: reuse existing storageState setup
-```
-
-## Out of Scope
-
-This skill only reads and reports on the codebase. For related tasks, use the appropriate skill:
-
-| Task | Skill |
-|------|-------|
-| Browsing a live site, interacting with UI elements | `agent-web-interface-guide` |
-| Deciding what to test, coverage gaps, priorities | `plan-test-coverage` |
-| Writing or modifying executable test code | `write-test-code` |
-| Diagnosing flaky or failing tests | `fix-flaky-tests` |
-
-## Example Usage
-
-```
-Claude Code: /analyze-test-codebase
-Codex: $analyze-test-codebase
-
-Claude Code: /analyze-test-codebase ./my-app
-Codex: $analyze-test-codebase ./my-app
-```

package/dist/2.0.9/codex/plugin/skills/analyze-test-codebase/agents/claude.yaml

@@ -1,3 +0,0 @@
-frontmatter:
-  argument-hint: "[optional: path to project root]"
-  user-invocable: true

package/dist/2.0.9/codex/plugin/skills/analyze-test-codebase/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Analyze Existing Test Setup"
-  short_description: "Inspect Playwright conventions before planning or writing tests"
-  default_prompt: "Analyze this Playwright codebase and summarize the current setup as an early workflow step before planning detailed coverage or writing test code."