Output:
  category: Standalone | feature-stage  # Based on how skill was invoked
  status: completed | blocked | skipped
  next_task_type: Feature Closing | null  # null if standalone
  require_human_review: No
  auto_proceed: {from input}
  task_output_links: [x-ipe-docs/requirements/FEATURE-XXX/acceptance-test-cases.md] | [{output_path}]
  
  # Feature-stage specific (only if category=feature-stage)
  feature_id: FEATURE-XXX
  feature_title: {title}
  feature_version: {version}
  feature_phase: Acceptance Testing
  
  # Acceptance test specific
  skip_reason: "No web UI" | null
  test_cases_created: {count}
  tests_passed: {count}
  tests_failed: {count}
  pass_rate: "{X}%"

1. QUERY feature board for Feature Data Model:
   - feature_id
   - specification_link
   - technical_design_link

2. READ technical design → Check "Technical Scope" section:
   
   IF scope includes [Frontend] OR [Full Stack]:
     - Proceed to Step 2
     
   ELSE (Backend, API Only, Database, CLI):
     - SET status = "skipped"
     - SET skip_reason = "No web UI"
     - RETURN to task-execution-guideline with:
       next_task_type: Feature Closing
       status: skipped

3. VERIFY feature is accessible:
   - Check if playground/demo URL exists
   - Confirm feature can be triggered via web UI

1. READ specification.md for feature:
   Location: x-ipe-docs/requirements/FEATURE-XXX/specification.md

2. EXTRACT all acceptance criteria (AC-X):
   - Note the exact wording of each criterion
   - Identify testable conditions
   - Note any edge cases mentioned

3. CREATE acceptance-test-cases.md:
   Location: x-ipe-docs/requirements/FEATURE-XXX/acceptance-test-cases.md
   Template: Use templates/acceptance-test-cases.md

4. FOR EACH acceptance criterion:
   - Create at least one test case (TC-XXX)
   - Map TC to AC reference
   - Define priority (P0/P1/P2)
   - Write high-level test steps (without selectors yet)
   - Define expected outcomes

5. PRIORITIZE test cases:
   P0 (Critical): Core functionality, must pass
   P1 (High): Important flows, should pass
   P2 (Medium): Edge cases, nice to pass

1. LOCATE UI implementation files:
   - Templates: src/x_ipe/templates/*.html
   - Static JS: src/x_ipe/static/js/*.js
   - Components: (project-specific paths)

2. FOR EACH test case, identify UI elements:
   
   ELEMENT IDENTIFICATION PRIORITY:
   1. data-testid attribute (preferred)
   2. id attribute
   3. aria-label for accessibility
   4. Unique class combinations
   5. CSS selector path (last resort)

3. UPDATE test steps with selectors:
   
   | Step | Action | Element Selector | Input Data | Expected Result |
   |------|--------|------------------|------------|-----------------|
   | 1 | Click | `[data-testid="submit-btn"]` | - | Form submits |
   | 2 | Enter | `#email-input` | "test@example.com" | Value appears |
   | 3 | Verify | `.success-message` | - | Contains "Saved" |

4. VERIFY selectors are:
   - Unique on the page
   - Stable (not dynamically generated IDs)
   - Descriptive of element purpose

PREFER:
- [data-testid="..."]     # Explicit test hooks
- #unique-id              # Stable IDs
- [aria-label="..."]      # Accessibility labels
- form[name="..."]        # Named forms

AVOID:
- .class1.class2.class3   # Fragile class chains
- div > div > span        # Position-dependent
- [id^="auto_"]           # Auto-generated IDs

IF auto_proceed = true:
   - SKIP this step
   - Use placeholder/generated test data
   - Proceed to Step 5

IF auto_proceed = false:
   - PAUSE and ask user for test data

1. ANALYZE each test case for data requirements:
   
   DATA TYPES (per test case):
   - Input: Values to enter in forms, fields
   - Selection: Options to select from dropdowns
   - Expected: Expected text, values to verify
   - Compare: Before/after values for validation

2. ASK user for each test case:
   
   "For TC-001 ({title}):
   - Input for '{field}': ___
   - Expected result: ___"

3. UPDATE Test Data table in each test case:
   
   | Type | Field/Element | Value | Notes |
   |------|---------------|-------|-------|
   | Input | email | "user@test.com" | Valid email |
   | Expected | success-msg | "Saved" | Contains |

FOR EACH test case:

1. VALIDATION CHECKLIST:
   □ Does test case cover the AC completely?
   □ Are preconditions clearly defined?
   □ Are all steps actionable?
   □ Are selectors verified to exist?
   □ Is expected result specific and measurable?
   □ Are edge cases covered?

2. REFLECTION QUESTIONS:
   - What could cause this test to fail incorrectly?
   - Are there missing steps between actions?
   - Is the expected result too vague?
   - Should this be split into multiple tests?

3. REFINE based on reflection:
   - Add missing steps
   - Clarify expected results
   - Add wait conditions if needed
   - Handle dynamic content loading

4. UPDATE acceptance-test-cases.md with refinements

1. CHECK MCP availability:
   
   IF Chrome DevTools MCP available:
     - Proceed with execution
   ELSE:
     - SET status = "blocked"
     - Document: "Test cases ready for manual execution"
     - RETURN results with test_cases_created count

2. FOR EACH test case (ordered by priority):
   
   a. SETUP:
      - Navigate to test URL
      - Verify page loaded
      
   b. EXECUTE steps:
      - Perform each action via MCP
      - Capture results after each step
      - Take screenshot on failure
      
   c. VERIFY expected outcomes:
      - Check element states
      - Validate text content
      - Confirm UI changes
      
   d. RECORD result:
      - Status: Pass | Fail | Blocked
      - Execution time
      - Failure reason (if any)
      - Screenshot link (if failure)

3. CONTINUE with remaining tests even if some fail

// Navigate
await page.goto('{URL}');

// Click element
await page.click('{selector}');

// Enter text
await page.fill('{selector}', '{value}');

// Verify text content
const text = await page.textContent('{selector}');
assert(text.includes('{expected}'));

// Wait for element
await page.waitForSelector('{selector}');

1. UPDATE acceptance-test-cases.md:
   
   - Set status for each test case (✅ Pass | ❌ Fail | ⬜ Not Run)
   - Add execution notes
   - Fill in Execution Results section:
     - Execution date
     - Environment
     - Pass/Fail counts
     - Pass rate percentage

2. DOCUMENT failures:
   
   | Test Case | Failure Reason | Recommended Action |
   |-----------|----------------|-------------------|
   | TC-003 | Button not found | Verify selector |
   | TC-007 | Timeout waiting | Check async loading |

3. CALCULATE metrics:
   - Total tests
   - Passed count
   - Failed count  
   - Blocked count
   - Pass rate = (passed / total) * 100

4. RETURN task output with results

1. Test empty form submission (validation)
2. Test invalid input formats
3. Test valid submission → success state
4. Verify success message/redirect

1. Test Create → verify appears in list
2. Test Read → verify data displayed correctly
3. Test Update → verify changes persisted
4. Test Delete → verify removed from list

1. Test direct URL access
2. Test navigation via links/buttons
3. Verify correct page renders
4. Test back/forward browser navigation