Playwright Test Case Writer

Fills the gap between scenario-mapper's terse one-line quick_steps and flow-runner's detailed-but-throwaway execution plan: a full test-case document that exists as its own artifact, reviewable and sign-off-able before anyone runs it.

Relationship to the other skills

Upstream: takes a scenario-mapper row (or a plain-language description) as its starting point — reuse its priority and scenario name rather than re-deriving them.

Downstream — this is the important part: once written, this document is the step plan flow-runner would otherwise write inline and discard. If a test-case document already exists for a scenario, flow-runner should execute directly from it rather than writing a new throwaway plan from scratch. And when flow-runner runs it successfully, the document's own status should be updated from "inferred" to "verified" — that update is what makes it trustworthy input for e2e-codegen later, which should only work from verified test cases, never inferred ones.

That gives the full pipeline a real shape: scenario-mapper (discover) → test-case-writer (detail it into a spec) → flow-runner (execute against the spec, flip it to verified) → e2e-codegen (only touches verified specs, makes them permanent code).

Core principles (and why)

This is a document, not an execution. No browser or MCP tool access needed — this is specification writing. The value is entirely in being precise and reviewable before a session runs it, whether that session is flow-runner, a human QA tester, or a future automated run.

Expected result per step, not just at the end. This is the single biggest structural difference from a terse scenario row or a quick conversational plan. A document that only states the final expected outcome leaves every intermediate step's correctness to interpretation — if step 3 of 7 does something subtly wrong but the final assertion happens to still pass, an end-only format would never catch it. Give every step its own expected result.

Precision over prose. Steps should be specific enough that two different people — or two different Claude sessions — executing the same document would do the exact same thing: name the actual button label or field, not "fill out the form"; name the actual test value, not "enter valid data." Ambiguity in a test case is itself a defect in the document.