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

package/dist/2.0.8/claude/plugin/.claude-plugin/plugin.json

@@ -1,20 +0,0 @@
-{
-  "name": "e2e-test-builder",
-  "description": "Full-pipeline Playwright E2E test generation — explores your live site via browser, detects existing test conventions, plans coverage gaps, produces reviewed test specs, writes production-grade test code with quality gates, and stabilizes flaky tests",
-  "version": "2.0.8",
-  "author": {
-    "name": "Athenaflow"
-  },
-  "keywords": [
-    "playwright",
-    "e2e",
-    "testing",
-    "test-generation",
-    "test-automation",
-    "browser-exploration",
-    "quality-gates",
-    "coverage-planning",
-    "flaky-test-fix"
-  ],
-  "category": "testing"
-}

package/dist/2.0.8/claude/plugin/package.json

@@ -1,9 +0,0 @@
-{
-  "name": "@athenaflow/plugin-e2e-test-builder",
-  "version": "2.0.8",
-  "description": "Full-pipeline Playwright E2E test generation — explores your live site via browser, detects existing test conventions, plans coverage gaps, produces reviewed test specs, writes production-grade test code with quality gates, and stabilizes flaky tests",
-  "license": "MIT",
-  "publishConfig": {
-    "access": "public"
-  }
-}

package/dist/2.0.8/claude/plugin/skills/add-e2e-tests/SKILL.md

@@ -1,217 +0,0 @@
----
-name: add-e2e-tests
-description: >
-  THE DEFAULT ENTRY POINT for all Playwright / E2E test work. This skill should be used FIRST
-  whenever the user wants to add, create, or set up end-to-end tests for any feature, page, or
-  application. Runs the full pipeline: analyze codebase, explore the live site, plan coverage,
-  generate TC-ID specs, run quality-gate reviews, write production-grade test code, and execute.
-  Delegates to sub-skills (analyze-test-codebase, plan-test-coverage, generate-test-cases,
-  review-test-cases, write-test-code, review-test-code, fix-flaky-tests) internally — do NOT
-  skip to sub-skills directly unless the user explicitly requests a narrow activity.
-  Iterative and resumable via tracker file. Uses subagent delegation to save context.
-user-invocable: true
-argument-hint: "<url> <feature to test>"
-allowed-tools: Read Write Edit Glob Grep Bash Task
----
-
-# Add E2E Tests
-
-Go from zero to passing Playwright tests for the target feature in one interactive session.
-
-## Input
-
-Parse the target URL and feature description from: $ARGUMENTS
-
-Derive a **feature slug** from the feature description (e.g., "Login flow" → `login`, "Checkout with payment" → `checkout`). Use this slug for file naming throughout.
-
-## Session Protocol
-
-### 1. Orient: Understand the Project, the Product, and Your Capabilities
-
-Before planning any work, build deep situational awareness. This step determines the quality of everything that follows — rushed orientation leads to missed test cases and wasted effort.
-
-**Check for existing progress:**
-- If `e2e-tracker.md` exists in the project root, read it and resume from where you left off — skip to **step 2 (Plan)** with the remaining work.
-- If no tracker exists, this is a fresh start. Proceed with orientation below.
-
-#### First: create initial tasks and tracker
-
-As soon as you parse the user's request:
-
-1. **Create the tracker** — write `e2e-tracker.md` with the goal (URL, feature, slug) and a skeleton plan.
-2. **Create high-level tasks** for the work ahead — analyze codebase, explore the product, plan coverage, generate test specs, write tests, verify tests.
-
-These are your starting skeleton. As you work through orientation and discover the actual shape of the work, refine both the tasks and the tracker — break tasks into granular sub-tasks, add new ones, remove ones that don't apply.
-
-Treat the task list as a visible milestone log. Keep it concise, but update it continuously. Do not leave broad tasks open until the end and then mark everything complete in one batch.
-
-#### 1a. Understand the codebase
-
-- Does a Playwright config exist (`playwright.config.{ts,js,mjs}`)? If not, you will need to scaffold one (see Scaffolding section).
-- Are there existing tests? What conventions do they follow — naming, locators, fixtures, page objects, auth?
-- Load the `analyze-test-codebase` skill and follow its methodology.
-
-#### 1b. Understand the product
-
-This is the most important part of orientation. You cannot write good tests for a product you don't understand.
-
-- **Read existing test cases** — if `test-cases/*.md` files exist, read them to understand what journeys have been mapped. Look at what's covered AND what's missing.
-- **Browse the actual product** — load the `agent-web-interface-guide` skill and use the browser MCP tools to walk through the feature you're testing. Don't just skim the page — interact with it as a user would: fill forms, click buttons, trigger validation, navigate between pages, check error states.
-- **Map the user journey in detail** — understand the complete flow: entry points, happy paths, error paths, edge cases, what happens with invalid input, what happens when the user goes back, what conditional UI exists.
-
-Why this matters: absent explicit exploration, agents tend to write tests based on assumptions about how a product works rather than how it actually works. The result is tests that target imaginary behavior or miss critical real behavior. Spending time here prevents both.
-
-#### 1c. Know your skills
-
-You have access to specialized skills that contain deep domain knowledge. Load the relevant skill before performing each activity — skills prevent improvisation and encode best practices.
-
-| Activity | Skill |
-|----------|-------|
-| Analyzing test setup, config, conventions | `analyze-test-codebase` |
-| Deciding what to test, coverage gaps, priorities | `plan-test-coverage` |
-| Opening a URL, browsing, using browser MCP tools | `agent-web-interface-guide` |
-| Creating TC-ID specs from site exploration | `generate-test-cases` |
-| Reviewing TC-ID specs before implementation | `review-test-cases` |
-| Writing, editing, or refactoring test code | `write-test-code` |
-| Reviewing test code before execution signoff | `review-test-code` |
-| Debugging test failures, checking stability | `fix-flaky-tests` |
-
-Before doing a substantial activity, load the skill that covers that activity so you can follow its workflow rather than improvising.
-
-#### 1d. Update the tracker with orientation findings
-
-After orienting, update the tracker with what you learned about the codebase and product, conventions discovered, and your refined plan. The tracker must always answer these four questions for anyone reading it cold:
-
-1. What is the goal?
-2. What has been done?
-3. What is remaining?
-4. What should I do next?
-
-See [references/tracker-template.md](references/tracker-template.md) for a concrete template.
-
-### 2. Plan: Refine Tasks Into Granular Checkpoints
-
-By now you have initial tasks and a tracker from step 1. Refine tasks into granular checkpoints. The plan should flow from what you learned during orientation, not from a fixed template.
-
-#### Task granularity
-
-Think in small checkpoints, not big phases. Each task should represent a concrete, verifiable unit of progress.
-
-Too coarse: "Analyze codebase", "Write tests", "Verify tests"
-
-Right granularity:
-- "Read playwright.config.ts — extract baseURL, testDir, projects"
-- "Read 2 existing test files — identify locator strategy and naming pattern"
-- "Write conventions report to e2e-plan/conventions.md"
-- "Navigate to /login — catalog all form fields, buttons, and validation messages"
-- "Submit login form empty — record all validation error messages and their positions"
-- "Submit login with invalid email format — record inline validation behavior"
-- "Write TC-LOGIN-001: happy path login with valid credentials"
-- "Write TC-LOGIN-002: login with empty email shows required field error"
-- "Run login.spec.ts and record full output"
-- "Fix TC-LOGIN-003: selector not found — browse page and re-extract selector"
-- "Re-run login.spec.ts — verify fix didn't break other tests"
-- "Check all TC-IDs from spec are present in test files"
-
-**Never be conservative.** More tasks is better than fewer. If you discover new work mid-session (a test fails, a selector changed, a form has unexpected validation), add tasks dynamically. The task list is a living document that reflects the real state of the work.
-
-Create tasks for verification steps too (running tests, checking coverage, browsing to confirm selectors), not just implementation.
-
-Update task status as each checkpoint completes. A good pattern is: finish exploration and mark it complete, finish coverage/spec work and mark it complete, finish implementation and mark it complete, then finish review/execution and mark it complete. Do not keep all milestones open until session end.
-
-### 3. Execute
-
-Work through your tasks. Load the relevant skill before each activity.
-
-#### Planning uses the browser heavily
-
-When planning what to test (coverage planning, test case generation), use the browser extensively. Don't just catalog elements — interact with the product to discover:
-- What validation messages appear for each field?
-- What happens when you submit with missing data?
-- What error states exist (network errors, empty states, permission errors)?
-- What does the flow look like end-to-end, not just page-by-page?
-- What edge cases exist (special characters, long inputs, rapid clicks)?
-- What UI changes conditionally (loading states, disabled buttons, progressive disclosure)?
-
-Every test case you generate should trace back to something you actually observed or deliberately triggered in the browser. This is how you avoid introducing useless test cases (testing imaginary behavior) and avoid missing important ones (behavior you didn't think to check).
-
-#### Subagent delegation
-
-Delegate heavy browser exploration and test writing to subagents when that saves context for orchestration, verification, and debugging. When delegating:
-- Pass the relevant file paths (conventions, coverage plan, test specs)
-- Instruct the subagent to invoke the appropriate skill (subagents inherit access to plugin skills)
-- Specify concrete output expectations (file path, format, TC-ID conventions)
-
-#### Quality gates
-
-Two review gates and a test execution checkpoint are mandatory during execution. The review gates are review-only — they produce findings but do not modify files.
-
-**Gate 1: Review test case specs** (after `generate-test-cases`, before `write-test-code`)
-1. Load the `review-test-cases` skill and run it against `test-cases/<feature>.md`
-2. If verdict is **NEEDS REVISION** — address all blockers in the spec before proceeding to implementation
-3. If verdict is **PASS WITH WARNINGS** — address warnings if quick, otherwise note them and proceed
-4. Record the review verdict in the tracker
-
-**Gate 2: Review test code** (after `write-test-code`, before final test execution)
-1. Load the `review-test-code` skill and run it against the implemented test files
-2. If verdict is **NEEDS REVISION** — fix all blockers before running tests for signoff
-3. If verdict is **PASS WITH WARNINGS** — fix warnings that affect stability, proceed with execution
-4. Record the review verdict in the tracker
-
-**Checkpoint: Test execution**
-1. Run the tests: `npx playwright test <file> --reporter=list 2>&1`
-2. Record full output — green test output is the only proof of correctness
-3. If tests fail, load the `fix-flaky-tests` skill and follow its structured diagnostic approach. Do not guess-and-retry.
-4. Maximum 3 fix-and-rerun cycles per test. If stuck after 3 cycles, record the diagnostic output in the tracker and move on.
-
-**Test execution and coverage checks must never be delegated to subagents.** Run `npx playwright test` directly and record the output.
-
-#### Update the tracker as you work
-
-Do not wait until session end. After each meaningful chunk of progress (completing a step, discovering a blocker, producing an artifact), update the tracker. If your context window resets, only what's in the tracker survives.
-
-Keep the tracker and task list synchronized. If you record progress in the tracker, update the corresponding task status in the same phase of work.
-
-#### Error recovery
-
-If infrastructure failures occur (browser MCP unavailable, clone failures, npm install errors), see [references/error-recovery.md](references/error-recovery.md) for diagnostic steps. General pattern: diagnose, attempt one known fix, if still stuck record in tracker and ask the user.
-
-### 4. End of Session
-
-Before exiting:
-1. Ensure the tracker reflects all progress, discoveries, and blockers from this session
-2. Write clear instructions for what the next session should do
-3. If all work is complete and all tests pass with full TC-ID coverage: write `<!-- E2E_COMPLETE -->` as the last line of the tracker
-4. If an unrecoverable blocker prevents progress: write `<!-- E2E_BLOCKED: reason -->` as the last line
-
-Do not write terminal markers prematurely. Only after you are confident the work is truly done or truly stuck.
-
-## Scaffolding
-
-If Playwright is not set up in the target project, follow the procedure in [references/scaffolding.md](references/scaffolding.md) to clone the boilerplate, merge configuration, and install dependencies. Log all scaffolding steps in the tracker.
-
-## Authentication
-
-If the target feature requires login, follow [references/authentication.md](references/authentication.md). Key rule: never hardcode credentials — use environment variables or `storageState`.
-
-## Principles
-
-- **Skills carry the knowledge** — load the relevant skill before each activity; do not improvise
-- **Subagent-driven** — delegate heavy browser and writing work to subagents to save context
-- **Follow existing conventions** — match the project's test style, not a generic template
-- **Traceable** — every test links back to a TC-ID from the spec
-- **Use what the project provides** — if the scaffolded boilerplate includes Page Object Models (BasePage, pages/), path aliases (tsconfig paths), or utility modules, USE them in generated tests. Do not ship infrastructure that tests ignore. If a boilerplate file is unused after test generation, either integrate it or remove it — dead code in test infrastructure causes confusion.
-- **No arbitrary waits** — use Playwright's built-in auto-wait and event-driven waits
-- **API before UI for setup** — use API calls (`request` fixture) for test data; reserve UI for what you are verifying
-- **Test failures, not just success** — every feature needs error path coverage
-- **Artifacts live in standard locations** — `e2e-plan/` for analysis, `test-cases/` for specs, project test dir for test files
-
-## Example Usage
-
-```
-Claude Code: /add-e2e-tests https://myapp.com/checkout Checkout flow with cart, shipping, and payment
-Codex: $add-e2e-tests https://myapp.com/checkout Checkout flow with cart, shipping, and payment
-
-Claude Code: /add-e2e-tests https://myapp.com/login User authentication including social login
-Codex: $add-e2e-tests https://myapp.com/login User authentication including social login
-```

package/dist/2.0.8/claude/plugin/skills/add-e2e-tests/agents/claude.yaml

@@ -1 +0,0 @@
-{}

package/dist/2.0.8/claude/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.8/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.8/claude/plugin/skills/fix-flaky-tests/references/fix-patterns.md

@@ -1,91 +0,0 @@
-# Fix Patterns by Root Cause
-
-Code examples for each root cause category. Apply only after diagnosing the cause in Step 2.
-
-## Timing Fixes — Replace Sleeps with Event-Driven Waits
-
-```typescript
-// BAD: arbitrary sleep
-await page.waitForTimeout(2000);
-await expect(element).toBeVisible();
-
-// GOOD: wait for the network event that loads the content
-await page.waitForResponse(resp => resp.url().includes('/api/data'));
-await expect(element).toBeVisible();
-
-// GOOD: wait for loading indicator to disappear
-await expect(page.getByRole('progressbar')).toBeHidden();
-await expect(element).toBeVisible();
-
-// GOOD: wait for navigation to complete
-await page.goto('/page', { waitUntil: 'networkidle' });
-
-// GOOD: use auto-retrying assertion (retries until timeout)
-await expect(page.getByText(/loaded/i)).toBeVisible({ timeout: 10000 });
-```
-
-## State Isolation Fixes
-
-```typescript
-// Unique data per test
-const uniqueEmail = `test-${Date.now()}@example.com`;
-
-// Reset state via API before each test
-test.beforeEach(async ({ request }) => {
-  await request.post('/api/test/reset');
-});
-
-// Use fresh browser context (default in Playwright, but verify)
-// Do NOT share page or context between tests
-```
-
-## Race Condition Fixes
-
-```typescript
-// Wait for hydration/framework readiness
-await page.waitForFunction(() =>
-  document.querySelector('[data-hydrated="true"]')
-);
-
-// Use Promise.all for action + expected response
-const [response] = await Promise.all([
-  page.waitForResponse('**/api/submit'),
-  submitButton.click(),
-]);
-
-// Wait for animation/transition to complete
-await expect(modal).toBeVisible();
-await page.waitForFunction(() =>
-  !document.querySelector('.modal-animating')
-);
-```
-
-## Selector Fixes
-
-```typescript
-// BAD: position-dependent, matches wrong element if order changes
-page.locator('.item').first();
-
-// GOOD: scoped to container with unique content
-page.getByRole('listitem').filter({ hasText: 'Specific Item' });
-
-// GOOD: use test IDs for ambiguous elements
-page.getByTestId('cart-item-sku-123');
-
-// GOOD: scope to a region first, then find within
-page.locator('main').getByRole('button', { name: /submit/i });
-```
-
-## Environment Fixes
-
-```typescript
-// Set explicit viewport in test or config
-test.use({ viewport: { width: 1280, height: 720 } });
-
-// Use timezone-agnostic assertions
-await expect(dateElement).toContainText(/\d{4}/); // year, not full date string
-
-// Block third-party scripts that interfere
-await page.route('**/analytics/**', route => route.abort());
-await page.route('**/chat-widget/**', route => route.abort());
-```

package/dist/2.0.8/claude/plugin/skills/generate-test-cases/SKILL.md

@@ -1,184 +0,0 @@
----
-name: generate-test-cases
-description: >
-  Use when the user wants detailed TC-ID test case specifications for a web app feature, not executable code. It explores the target flow, covers happy paths, validation failures, edge cases, and required error states, then writes structured specs under `test-cases/`. Use it after coverage planning or when the user explicitly asks for test cases or TC-IDs. It does not write Playwright code.
-allowed-tools: Read Write Bash Glob Grep Task
----
-
-# Generate Test Cases
-
-Generate comprehensive, structured test case specifications for a web application by exploring it live in a browser.
-
-## Input
-
-Parse the target URL and user journey description from: $ARGUMENTS
-
-## Workflow
-
-### Step 1: Understand the Journey and Existing Coverage
-
-Parse the journey description to identify:
-- **Base URL** and target feature area
-- **Primary user goal** (what the happy path achieves)
-- **Key interaction points** (forms, buttons, navigation, selections)
-- **Implicit requirements** (validation, authentication, authorization)
-
-Check for existing test coverage before exploring:
-- Search for existing test files related to this feature (`Grep` for feature keywords in `**/*.spec.ts`, `**/*.test.ts`)
-- Read any existing `test-cases/*.md` spec files for this feature
-- Note existing TC-IDs to avoid conflicts — continue numbering from the highest existing ID
-- Focus on gaps in existing coverage
-
-### Step 2: Explore the Happy Path
-
-Use a subagent for browser exploration when that saves context. Pass it:
-- The URL and journey description
-- Instructions to walk through each step using `find`, `get_form`, `get_field`
-- Instructions to catalog all interactive elements, form fields, navigation options
-- Instructions to use `get_element` on key elements to capture the best Playwright selector
-- Instructions to return results in this structured format for each step:
-
-```
-Step: <what was done>
-URL: <current URL after action>
-Elements found:
-  - Submit button: getByRole('button', { name: /submit/i })
-  - Email field: getByLabel(/email/i)
-  - Error message: getByText(/required/i)
-Observations: <what appeared, validation messages, state changes>
-```
-
-This structured output ensures selectors survive the handoff to the spec file and ultimately to `write-test-code`.
-
-### Step 3: Explore Alternative and Failure Paths
-
-Launch another subagent, or continue in the main thread if the flow is small, to systematically probe beyond the happy path:
-
-**Validation & Error Handling:**
-- Submit forms with empty required fields
-- Enter invalid formats (wrong email, short passwords, letters in number fields)
-- Exceed field length limits, use special characters and Unicode
-
-**Boundary Conditions:**
-- Min/max values for numeric fields
-- Single character and max length strings
-- Zero quantities, negative numbers, date boundaries
-
-**State & Navigation:**
-- Browser back/forward during multi-step flows
-- Page refresh mid-flow
-- Accessing later steps directly via URL
-
-**UI & Interaction:**
-- Rapid repeated clicks on submit buttons
-- Dropdown default values, empty options
-- Loading states, disabled states, conditional visibility
-
-**Access & Authorization (observe only):**
-- Redirect behavior for unauthenticated users
-- Permission-related error messages
-
-### Step 4: Reason About Additional Scenarios
-
-After exploration, reason about scenarios that could not be directly triggered but must be covered:
-
-- **Network & Performance** — failure modes, slow responses, large data sets, offline behavior
-- **Accessibility (WCAG 2.1 AA)** — keyboard navigation, screen reader support, focus management, contrast
-- **Visual Consistency** — layout stability, responsive breakpoints, dark mode
-- **Cross-browser** — Safari/Firefox/mobile-specific behavioral differences
-- **Concurrent & Session** — session expiry, multi-tab conflicts, race conditions
-
-See [references/scenario-categories.md](references/scenario-categories.md) for detailed checklists within each category.
-
-### Step 5: Generate Test Case Specifications
-
-Write structured test cases to `test-cases/<feature-name>.md`.
-
-## Output Specification
-
-### Test Case Format
-
-```markdown
-### TC-<FEATURE>-<NUMBER>: <Descriptive title>
-
-**Priority:** Critical | High | Medium | Low
-**Category:** Happy Path | Validation | Error Handling | Edge Case | Boundary | Security | Accessibility | Visual | Performance | Network Error | UX
-**Preconditions:**
-- <What must be true before this test>
-
-**Steps:**
-1. <Action the tester performs>
-2. <Next action>
-
-**Expected Result:**
-- <What should happen>
-
-**Selectors observed:**
-- <element>: `getByRole('button', { name: /submit/i })` or `getByLabel(/email/i)` — from `get_element`/`find` during exploration
-- (Include selectors for key interactive elements so `write-test-code` doesn't have to rediscover them)
-
-**Notes:**
-- <Additional context discovered during exploration>
-```
-
-### Output Organization
-
-```markdown
-# Test Cases: <Feature Name>
-
-**URL:** <base URL>
-**Generated:** <date>
-**Journey:** <brief description>
-
-## Summary
-- Total test cases: <count>
-- Critical: <count> | High: <count> | Medium: <count> | Low: <count>
-
-## Happy Path
-## Validation & Error Handling
-## Edge Cases
-## Boundary Conditions
-## Security & Access
-## Network Error Scenarios
-## Visual & Responsive
-## Performance & Loading
-## Accessibility & UX
-```
-
-### File Naming Convention
-
-When generating specs that span multiple roles or test categories, recommend role-based file naming (`*.admin.spec.ts`, `*.user.spec.ts`) or Playwright tag annotations (`@admin`, `@smoke`) in the spec. This enables selective execution via `--grep @admin` or glob patterns instead of fragile `testIgnore` regex in playwright.config.ts. NEVER recommend a `testIgnore` regex that must be updated for every new test file.
-
-### TC-ID Convention
-
-- Format: `TC-<FEATURE>-<NNN>` where NNN is zero-padded to 3 digits
-- Feature abbreviation: short and clear (LOGIN, CHECKOUT, SEARCH, SIGNUP)
-- Start at 001, sequential, unique within the document
-- Happy path first, then validation, then edge cases
-
-## Quality Standards
-
-- Every test case must be **independently executable** — no hidden dependencies
-- Steps must be **concrete and unambiguous** — "click the Submit button" not "submit the form"
-- Expected results must be **observable and verifiable** — include actual error messages observed
-- Priority must be **justified** — Critical = blocks core journey, High = significant, Medium = secondary, Low = cosmetic
-- Every feature spec MUST include at minimum: one network error scenario (500/timeout), one empty state scenario, and one session/auth edge case (if the feature requires auth). These are non-negotiable — omitting them is a BLOCKER in the review-test-cases quality gate.
-- **Test case count guidance:** Aim for 15-30 test cases per feature area as a baseline. Fewer than 10 suggests missing error paths or edge cases. More than 40 suggests the feature should be split into sub-features with separate spec files. Prioritize breadth of category coverage over depth within a single category.
-
-## Blocking Conditions
-
-Report and work around:
-- **Login/auth walls**: Document as precondition, test observable behavior
-- **CAPTCHA**: Report, skip, note in preconditions
-- **Payment gateways**: Don't enter real data, document flow up to that point
-- **Rate limiting**: Slow down, note rate limit behavior as a test case
-
-## Example Usage
-
-```
-Claude Code: /generate-test-cases https://example.com/login User logs in with email and password, sees dashboard
-Codex: $generate-test-cases https://example.com/login User logs in with email and password, sees dashboard
-
-Claude Code: /generate-test-cases https://shop.example.com User searches for product, adds to cart, proceeds to checkout
-Codex: $generate-test-cases https://shop.example.com User searches for product, adds to cart, proceeds to checkout
-```