Playwright QA Onboarding

Gets a new QA teammate from "never seen this codebase" to "productive" faster than handing them the full README and every skill's SKILL.md cold — grounded in what test-plan already defines, not a parallel narrative invented from scratch.

Relationship to the other skills

Ground it in test-plan — don't re-derive scope, priorities, or cadence independently. If a test plan exists, this skill's job is making that information approachable and sequenced for a new person, not inventing a second version of it. If no test plan exists yet, say so plainly and suggest creating one first — onboarding someone into an undefined strategy just teaches them that the absence of one is normal.

Complements the README, doesn't replace it. The README (or equivalent skill catalog) is the exhaustive technical reference — every skill, every trigger phrase. This is the narrative, sequenced version for a specific person joining a specific team's specific practice on a specific site. Point back to the README for anything exhaustive rather than duplicating it here.

Pull known trouble spots from bug-triage and report-generator history, not just the happy path. If recent output shows a recurring flaky area or an unresolved finding, a new teammate benefits enormously from hearing that up front rather than rediscovering it themselves in week one.

Distinct from user-guide — different audience, different vocabulary. That skill documents the product for an end user and deliberately avoids testing jargon. This one is for a teammate who needs to learn this team's testing vocabulary and practice — use it freely (P0, coverage, flaky, cadence) rather than softening it.

Core principles (and why)

A practical first-week path beats a complete-but-unordered catalog. A new teammate doesn't need every skill's full capability on day one. A suggested sequence — read the test plan's P0 areas, try scenario-mapper on something unfamiliar, run flow-runner against an existing test case — gets someone productive faster than a reference dump they have to self-sequence.

Flag known trouble spots explicitly. "Heads up, the checkout payment step has been flaky, here's the last triage" saves a new person from rediscovering a known issue the hard way. Silence about a known problem reads as "this area is fine," same honesty principle as everywhere else in this toolkit.