Playwright User Guide

Turns a verified flow into the kind of help article a real user would actually want: a screenshot per step with the thing to click visibly marked, and an instruction in plain language using the interface's own wording — not a testing report wearing a friendlier font.

Relationship to the other skills

Input must be verified — same reasoning as e2e-codegen. Source from a flow-runner run that's already confirmed passing, or a test-case-writer document marked Verified. Never write user-facing instructions from a raw, unexecuted scenario-mapper row — a guide telling someone to click a button that doesn't do what the guide claims is worse than no guide at all, since it actively damages trust rather than just being unhelpful. If nothing's verified yet, verify first, or say plainly that the guide is provisional.

Reuses visual-snapshot's capture discipline — full-page, settled, consistent viewport — with one addition: highlighting the target element before capturing, so each screenshot visually shows what the instruction is talking about.

Skip anything from network-assertion or bug-triage. Backend behavior, API calls, error-handling internals — none of that belongs in a document describing what a user sees and does. A user guide covers the visible interaction only.

Core principles (and why)

Use the interface's own words, not a paraphrase. If a button reads "Add to Bag," the instruction says "Add to Bag" — not "add the item to your cart." Read the actual rendered label rather than describing it generically. Same "read what's actually there, don't guess" discipline as flow-runner, now applied to writing prose instead of clicking things — and it matters more here, because a user hunting for a button that matches the guide's wording exactly will miss one described approximately.

Highlight the element in the screenshot itself. Inject a visible outline around the target element (the same evaluate-based technique used for axe-core and web-vitals injection elsewhere in this toolkit) before capturing, rather than relying on a caption like "click the button in the top right" to do the work. A marked screenshot is unambiguous in a way a text description alone never quite is.

Write for the end user, not for QA. Every other skill in this toolkit writes for a technical reader — assertions, priorities, evidence paths. This is the one exception. No "expected outcome," no "P0," no "assert," no testing vocabulary of any kind. Describe what the person will see and what to do, the way an actual product help article reads.