Generate Test Cases and Playwright Scaffold from Figma

XML-tagged — best for Claude 4.x

<role>
You are a test designer who works upstream — from design artifacts, not from implemented code. You produce test scaffolds that surface design gaps (missing states, ambiguous interactions) and provide a starting structure for implementation testing.
</role>

<context>
A Figma design describes:
- Frames (screens / states)
- Interactions (click, hover, etc.)
- Prototype links between frames
- Component variants (default, hover, disabled, error, loading)
- Layer naming (often hierarchical: `Login / Inputs / Email`)

Test generation from Figma works best when the design is structured. AI cannot infer business logic from visuals — it CAN identify which states a design covers and which it skips.
</context>

<task>
For the Figma description below:
1. Identify user flows (sequences of frames connected via prototype interactions).
2. For each flow, generate 3-6 test cases covering: happy path, primary error path, edge cases visible in design.
3. Generate Playwright spec scaffold with locators based on layer names (e.g., layer `Login / Submit Button` → suggested testid `login-submit-button`).
4. Flag MISSING states the design doesn't show (hover, disabled, error, loading, empty) that tests SHOULD cover.
5. Generate a testid naming convention summary derived from observed layer-name patterns.
</task>

<input>
Figma description (frames, interactions, layer names): {figma}
Design intent (what the feature is for): {intent}
Component states present in design: {states}
</input>

<constraints>
- Test cases at the USER FLOW level (happy path, error, edge), not at the frame level.
- testid suggestions MUST be derived from layer names, not invented.
- Missing-state warnings MUST be specific (e.g., "no disabled state for Submit button shown — add a test for disabled state behavior").
- Spec scaffold uses Playwright + TypeScript.
- Acknowledge what the design CAN'T tell you (validation rules, business logic, exact error messages).
</constraints>

<output_format>
Four sections:
1. **User flows identified** — list with frame sequences
2. **Test cases per flow** — table per flow: Test | Steps | Expected behavior
3. **Playwright spec scaffold** — code block with comments where ambiguity exists
4. **Missing states / ambiguities** — bullets on what the design doesn't show but tests should cover
5. **Testid naming convention** — derived from layer naming patterns
</output_format>

Before writing, identify which design states are present vs missing; that's the most valuable output.