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

package/dist/2.0.8/codex/plugin/skills/write-test-code/references/api-setup-teardown.md

@@ -1,83 +0,0 @@
-# API-Driven Test Setup and Teardown
-
-## API-Driven Test Setup
-
-Use API calls to set up test data instead of clicking through UI. This is 10-50x faster and more reliable.
-
-**When to use API setup:** Creating test users, products, orders, seed data. Setting feature flags. Resetting state between tests.
-
-**When to use UI setup:** Only when the creation flow IS the test being verified.
-
-```typescript
-test('TC-CART-001: User sees items in cart', async ({ page, request }) => {
-  // Arrange: seed data via API (fast, deterministic)
-  await request.post('/api/cart/items', {
-    data: { productId: 'SKU-123', quantity: 2 }
-  });
-
-  // Act: navigate to verify UI
-  await page.goto('/cart');
-
-  // Assert
-  await expect(page.getByRole('listitem')).toHaveCount(2);
-});
-```
-
-**Reusable API fixture pattern:**
-```typescript
-export const test = base.extend<{ apiClient: APIRequestContext }>({
-  apiClient: async ({ playwright }, use) => {
-    const ctx = await playwright.request.newContext({
-      baseURL: process.env.API_BASE_URL,
-      extraHTTPHeaders: { Authorization: `Bearer ${process.env.API_TOKEN}` },
-    });
-    await use(ctx);
-    await ctx.dispose();
-  },
-});
-```
-
-## Test Data Teardown
-
-Tests that create persistent data (database records, uploaded files, user accounts) MUST clean up after themselves. Leaked test data accumulates across runs and causes false positives/negatives in other tests (pagination counts drift, filter results change, list assertions break).
-
-### Strategy 1: API teardown in afterEach (Recommended)
-
-```typescript
-let createdTicketId: string;
-
-test.beforeEach(async ({ request }) => {
-  const resp = await request.post('/api/tickets', {
-    data: { title: `Test ${Date.now()}` }
-  });
-  createdTicketId = (await resp.json()).id;
-});
-
-test.afterEach(async ({ request }) => {
-  if (createdTicketId) {
-    await request.delete(`/api/tickets/${createdTicketId}`);
-  }
-});
-```
-
-### Strategy 2: Fixture with automatic cleanup
-
-```typescript
-export const test = base.extend<{ testTicket: { id: string; title: string } }>({
-  testTicket: async ({ request }, use) => {
-    const resp = await request.post('/api/tickets', {
-      data: { title: `Test ${Date.now()}` }
-    });
-    const ticket = await resp.json();
-    await use(ticket);
-    // cleanup runs automatically when test finishes
-    await request.delete(`/api/tickets/${ticket.id}`);
-  },
-});
-```
-
-### Strategy 3: Bulk cleanup in globalTeardown
-
-For environments where individual deletion is impractical, tag test data (e.g., `title LIKE 'Test %'`) and delete in batch during `globalTeardown.ts`.
-
-If the cleanup API endpoint is unknown, do not invent one. Leave a clear `TODO` with the missing endpoint details, document the cleanup gap in the test file or tracker, and prefer fixture-scoped or environment reset strategies that you can verify. If cleanup is genuinely impossible (no API, no database access), document this as a known limitation in the test file header AND add an `afterEach` that logs a warning.

package/dist/2.0.8/release.json

@@ -1,18 +0,0 @@
-{
-  "schemaVersion": 1,
-  "pluginRef": "e2e-test-builder@athena-workflow-marketplace",
-  "pluginName": "e2e-test-builder",
-  "marketplaceName": "athena-workflow-marketplace",
-  "version": "2.0.8",
-  "artifacts": {
-    "claude": {
-      "type": "directory",
-      "path": "./claude/plugin"
-    },
-    "codex": {
-      "type": "marketplace",
-      "marketplacePath": "./.agents/plugins/marketplace.json",
-      "pluginPath": "./codex/plugin"
-    }
-  }
-}

package/dist/2.0.9/.agents/plugins/marketplace.json

@@ -1,14 +0,0 @@
-{
-  "schemaVersion": 1,
-  "name": "athena-workflow-marketplace",
-  "plugins": [
-    {
-      "name": "e2e-test-builder",
-      "version": "2.0.9",
-      "source": {
-        "source": "local",
-        "path": "./codex/plugin"
-      }
-    }
-  ]
-}

package/dist/2.0.9/claude/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/claude/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/claude/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/claude/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/claude/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/claude/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."

package/dist/2.0.9/claude/plugin/skills/fix-flaky-tests/agents/claude.yaml

@@ -1,3 +0,0 @@
-frontmatter:
-  argument-hint: "<path to flaky test file or test name>"
-  user-invocable: true

package/dist/2.0.9/claude/plugin/skills/fix-flaky-tests/agents/openai.yaml

@@ -1,10 +0,0 @@
-interface:
-  display_name: "Fix Flaky Playwright Tests"
-  short_description: "Diagnose unstable Playwright tests and fix the root cause"
-  default_prompt: "Diagnose this flaky Playwright test, reproduce the failure, and fix the root cause."
-
-dependencies:
-  tools:
-    - type: "mcp"
-      value: "agent-web-interface"
-      description: "Browser automation MCP used to reproduce and inspect unstable flows"

package/dist/2.0.9/claude/plugin/skills/generate-test-cases/agents/claude.yaml

@@ -1,3 +0,0 @@
-frontmatter:
-  argument-hint: "<url> <user journey description>"
-  user-invocable: true

package/dist/2.0.9/claude/plugin/skills/generate-test-cases/agents/openai.yaml

@@ -1,10 +0,0 @@
-interface:
-  display_name: "Write TC-ID Specs"
-  short_description: "Explore the feature and write detailed TC-ID test case specs"
-  default_prompt: "Explore this feature and generate detailed TC-ID test case specifications."
-
-dependencies:
-  tools:
-    - type: "mcp"
-      value: "agent-web-interface"
-      description: "Browser automation MCP used to inspect the live flow before writing specs"

package/dist/2.0.9/claude/plugin/skills/generate-test-cases/references/scenario-categories.md

@@ -1,36 +0,0 @@
-# Scenario Categories — Detailed Checklists
-
-These checklists support Step 4 of the generate-test-cases skill. Each category covers scenarios that may not be directly triggerable during browser exploration but must be included in comprehensive test specifications.
-
-## Network & Performance
-
-- Network failure during form submission (mock 500, timeout)
-- Slow API response (loading states, skeleton screens, spinners)
-- Large data sets (pagination, infinite scroll, 100+ items)
-- Offline behavior (if PWA or service worker is present)
-
-## Accessibility (WCAG 2.1 AA)
-
-- Keyboard-only navigation through the entire flow (Tab, Enter, Escape)
-- Screen reader announcements for dynamic content (ARIA live regions)
-- Focus management after modal open/close, page transitions
-- Color contrast for error states and disabled elements
-- Form error association (`aria-describedby` linking errors to fields)
-
-## Visual Consistency
-
-- Layout stability (no unexpected content shifts after load)
-- Responsive behavior at standard breakpoints (mobile 375px, tablet 768px, desktop 1280px)
-- Dark mode rendering if supported
-
-## Cross-browser Considerations
-
-- Safari-specific behavior (date inputs, smooth scrolling, storage quirks)
-- Firefox form validation differences
-- Mobile browser touch targets and gestures
-
-## Concurrent & Session
-
-- Session expiry mid-flow (cookie cleared during multi-step)
-- Concurrent access (two tabs, same user)
-- Race conditions (double-click submit, rapid navigation)

package/dist/2.0.9/claude/plugin/skills/plan-test-coverage/agents/claude.yaml

@@ -1,3 +0,0 @@
-frontmatter:
-  argument-hint: "<url> <feature or area to test>"
-  user-invocable: true

package/dist/2.0.9/claude/plugin/skills/plan-test-coverage/agents/openai.yaml

@@ -1,10 +0,0 @@
-interface:
-  display_name: "Plan Coverage Priorities"
-  short_description: "Identify coverage gaps and prioritize what to test first"
-  default_prompt: "Review this feature and produce a prioritized E2E coverage plan without writing specs or code."
-
-dependencies:
-  tools:
-    - type: "mcp"
-      value: "agent-web-interface"
-      description: "Browser automation MCP used for lightweight site inspection"

package/dist/2.0.9/claude/plugin/skills/review-test-cases/agents/claude.yaml

@@ -1,3 +0,0 @@
-frontmatter:
-  argument-hint: "<path to test-cases/*.md spec file>"
-  user-invocable: true

package/dist/2.0.9/claude/plugin/skills/review-test-cases/agents/openai.yaml

@@ -1,10 +0,0 @@
-interface:
-  display_name: "Review TC-ID Specs"
-  short_description: "Review TC-ID specs for gaps, duplication, and weak assertions"
-  default_prompt: "Review these TC-ID test case specifications before implementation and flag quality issues."
-
-dependencies:
-  tools:
-    - type: "mcp"
-      value: "agent-web-interface"
-      description: "Browser automation MCP used to spot-check observed behavior claims against live site"

package/dist/2.0.9/claude/plugin/skills/review-test-code/SKILL.md

@@ -1,189 +0,0 @@
----
-name: review-test-code
-description: >
-  Quality review of Playwright test code before final execution signoff. This skill should be used
-  when implementation review of executable Playwright tests is needed, not for diagnosis of runtime flakiness.
-  Triggers: "review test code", "review Playwright tests", "check test quality",
-  "audit test implementation", "review my tests before merging", "check test code for issues",
-  "review e2e tests", "code review Playwright", "are my tests stable",
-  "check for brittle selectors", "review before running tests". Quality gate
-  after write-test-code — catches brittle selectors, force:true misuse, networkidle overuse, Tailwind
-  utility class selectors, exact numeric assertions, missing teardown, parallel-unsafe mutations,
-  hardcoded data, missing assertions, test coupling, and convention divergence. Review-only — does NOT
-  rewrite tests, does NOT run tests. Use fix-flaky-tests for fixing, write-test-code for rewriting.
-allowed-tools: Read Glob Grep Task
----
-
-# Review Test Code
-
-Review Playwright test code for stability, correctness, and adherence to project conventions before final execution signoff. This is a quality gate — catch structural issues in code before running tests, not after flaky failures.
-
-## Input
-
-Parse the test file path or directory from: $ARGUMENTS
-
-If no argument provided, search for recently modified `*.spec.ts` or `*.test.ts` files and review those.
-
-## Workflow
-
-### Step 1: Load Context
-
-1. Read the test file(s) to review
-2. Read project conventions for comparison:
-   - `playwright.config.ts` or `playwright.config.js` — extract `baseURL`, `testDir`, projects, timeouts, `fullyParallel`, `workers`
-   - 2-3 existing test files (not the ones under review) to establish the project's conventions
-   - `e2e-plan/conventions.md` if it exists
-3. Read the corresponding test case spec (`test-cases/<feature>.md`) if it exists — needed for traceability check
-4. Note the project's locator strategy, fixture patterns, auth approach, and naming conventions
-
-### Step 2: Run the Review Checklist
-
-Evaluate the test code against each criterion. Track findings by severity:
-
-- **BLOCKER** — will cause test failures or false passes (missing assertions, wrong selectors, broken isolation)
-- **WARNING** — will cause flakiness or maintenance burden (brittle selectors, arbitrary waits, poor structure)
-- **SUGGESTION** — style or convention improvement (naming, organization, minor readability)
-
-#### 2a. Locator Quality
-
-| Check | What to Look For |
-|-------|-----------------|
-| Semantic locators preferred | `getByRole`, `getByLabel`, `getByPlaceholder` over CSS selectors |
-| No fragile positional selectors | `.first()`, `.nth()`, `.last()` without documented justification |
-| No dynamic IDs or classes | Selectors containing generated hashes, UUIDs, or auto-incremented values |
-| No utility framework classes | Selectors must not contain Tailwind (`rounded-lg`, `flex`, `bg-*`), Bootstrap (`btn-primary`, `col-md-*`), or similar utility classes — these are styling, not identity |
-| Scoped to containers | Locators narrowed to `main`, `nav`, `[role="dialog"]` where needed |
-| No exact long text matches | Use regex with key words instead of full marketing copy |
-
-When a locator appears suspicious, delegate verification to a subagent (Task tool): instruct it to open the target URL, locate the element using the browser MCP tools (`find`, `get_element`), and report back whether the element exists and is unique.
-
-#### 2b. Waiting and Timing
-
-| Check | What to Look For |
-|-------|-----------------|
-| No `waitForTimeout()` | Arbitrary sleeps mask real timing issues |
-| Proper action-response waits | `waitForResponse` before asserting API-dependent UI |
-| Auto-retrying assertions used | `await expect(el).toBeVisible()` not `expect(await el.isVisible()).toBe(true)` |
-| Reasonable explicit timeouts | Custom timeouts (`{ timeout: 10000 }`) have a comment explaining why |
-| No `networkidle` overuse | `networkidle` is fragile; prefer specific response waits |
-
-#### 2c. Assertions
-
-| Check | What to Look For |
-|-------|-----------------|
-| Every test has assertions | No test blocks without `expect()` calls |
-| Assertions test user outcomes | Visible text, URL changes, element states — not internal state or CSS classes |
-| Assertions are specific | `toHaveText('Welcome, John')` not just `toBeVisible()` |
-| Error paths have assertions | Error scenario tests verify the error message, not just that "something happened" |
-| No exact server-computed values | Dashboard counters, totals, and aggregates must not assert exact numbers — use patterns, ranges, or seed data first |
-| No `toBeTruthy()` on locators | Use Playwright-specific matchers (`toBeVisible`, `toBeEnabled`, `toHaveText`) |
-
-#### 2d. Test Isolation and Structure
-
-| Check | What to Look For |
-|-------|-----------------|
-| No shared mutable state | Tests do not depend on execution order or modify shared variables |
-| Proper setup/teardown | `beforeEach`/`afterEach` for shared setup, not duplicated in each test |
-| AAA structure | Clear Arrange → Act → Assert sections (comments optional but structure required) |
-| No test coupling | Test B does not depend on side effects from Test A |
-| Auth handled correctly | `storageState` or fixture, not UI login in every test (unless testing login itself) |
-| Test data is unique | Uses `Date.now()`, factories, or unique IDs — not hardcoded shared data |
-| Parallel-safe (if `fullyParallel: true` or `workers` > 1 found in config) | Tests that create data must not assert on unscoped lists or counts — filter assertions to the specific data created. If parallelism is disabled, note as SUGGESTION rather than WARNING |
-| Data cleanup present | Tests that create persistent records (API POST/PUT) must have corresponding teardown (`afterEach`, fixture cleanup, or `globalTeardown`) |
-
-#### 2e. Convention Adherence
-
-| Check | What to Look For |
-|-------|-----------------|
-| TC-ID in test title | Every test has `TC-<FEATURE>-<NNN>: Description` format |
-| File naming matches project | Follows existing `*.spec.ts` or `*.test.ts` convention |
-| Import style matches project | Imports from project fixtures file if one exists, not raw `@playwright/test` |
-| baseURL used | `page.goto('/')` not `page.goto('https://example.com/')` |
-| POM pattern followed (if used) | Page objects for interactions, tests for assertions |
-| Consistent locator strategy | Same locator approach as existing tests |
-
-#### 2f. TC-ID Traceability
-
-If a test case spec file exists for this feature:
-- Verify every TC-ID from the spec has a corresponding test
-- Flag TC-IDs in the spec with no implementation
-- Flag tests with TC-IDs not present in the spec (orphaned tests)
-- Note: not every spec TC-ID must be implemented — but missing ones should be acknowledged
-
-#### 2g. Anti-Pattern Detection
-
-Flag any instances of these known anti-patterns:
-1. Raw CSS selectors where semantic locators would work
-2. `waitForTimeout()` used as a fix
-3. `.first()` / `.nth()` without justification
-4. Exact long text matches (fragile to copy changes)
-5. Login via UI in every test (should use storageState)
-6. UI clicks to set up test data (should use API)
-7. No error path tests in the suite
-8. Hardcoded test data
-9. Tests depending on execution order
-10. `expect(await el.isVisible()).toBe(true)` instead of `await expect(el).toBeVisible()`
-11. Missing `await` on Playwright calls (easy to miss, causes silent failures)
-12. `{ force: true }` on interactions without documented justification (masks actionability issues — overlapping elements, disabled state, not scrolled into view)
-13. `waitForLoadState('networkidle')` as default wait strategy — breaks on long-polling, WebSockets, analytics beacons; use specific `waitForResponse` or UI assertions instead
-14. CSS utility class selectors (Tailwind `rounded-lg`, `flex`, Bootstrap `btn-primary`, `col-md-*`) — styling classes are volatile, never use as selectors
-15. Asserting exact server-computed values (`toHaveText('12450')`) — use pattern matchers, ranges, or seed data to control expected values
-
-### Step 3: Produce the Review Report
-
-Output a structured review with this format:
-
-```markdown
-# Test Code Review: <file or feature>
-
-**Files reviewed:** <list>
-**Total tests:** <count>
-**Review date:** <date>
-
-## Verdict: PASS | PASS WITH WARNINGS | NEEDS REVISION
-
-## Blockers (<count>)
-- **<file>:<line>** `<test name>`: <issue description>
-
-## Warnings (<count>)
-- **<file>:<line>** `<test name>`: <issue description>
-
-## Suggestions (<count>)
-- **<file>:<line>**: <issue description>
-
-## Convention Divergences
-- <How this code differs from the project's established patterns>
-
-## TC-ID Traceability
-- **Implemented:** <count> / <total in spec>
-- **Missing from implementation:** <list of TC-IDs>
-- **Orphaned (no spec):** <list of TC-IDs>
-
-## Summary
-<2-3 sentences on overall code quality and what to address before test execution>
-```
-
-### Step 4: Verdict Rules
-
-- **PASS** — no blockers, 2 or fewer warnings. Proceed to test execution.
-- **PASS WITH WARNINGS** — no blockers, 3+ warnings. Can proceed but should address warnings for long-term stability.
-- **NEEDS REVISION** — 1+ blockers. Do not run tests expecting stable results until blockers are resolved.
-
-## Principles
-
-- **Review-only** — never modify test files; report findings for the author to act on
-- **Evidence over opinion** — cite specific file paths, line numbers, and code snippets when flagging issues
-- **Spot-check selectors** — delegate to a subagent with browser access to verify 2-3 suspicious locators against the live site
-- **Convention-first** — compare against the project's existing test patterns, not an abstract ideal
-- **Bounded output** — the review should be actionable and finite, not a full rewrite specification
-- **Severity matters** — a missing `await` is a blocker; a naming style preference is a suggestion
-
-## Example Usage
-
-```
-Claude Code: /review-test-code tests/e2e/login.spec.ts
-Codex: $review-test-code tests/e2e/login.spec.ts
-
-Claude Code: /review-test-code tests/e2e/
-Codex: $review-test-code tests/e2e/
-```

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

@@ -1,3 +0,0 @@
-frontmatter:
-  argument-hint: "<path to test file or directory>"
-  user-invocable: true

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

@@ -1,10 +0,0 @@
-interface:
-  display_name: "Review Playwright Test Code"
-  short_description: "Review Playwright test implementation for stability and correctness"
-  default_prompt: "Review this Playwright test implementation before execution and flag quality issues."
-
-dependencies:
-  tools:
-    - type: "mcp"
-      value: "agent-web-interface"
-      description: "Browser automation MCP used to verify selectors against the live site"

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

@@ -1,3 +0,0 @@
-frontmatter:
-  argument-hint: "<test description or path to test case spec file>"
-  user-invocable: true