Omar SobhandClaude Opus 5
4358964c05
55 of 85 role skill bindings pointed at skills that were never authored,
so 10 of 11 team templates bound a smaller context bundle than their role
prompts assumed. Three roles bound nothing at all (gpu.bench_engineer,
threejs.shader_author, threejs.perf_engineer) while their prompts described
procedures they had no way to read.
The loader comment at team_template_loader.rs:167 already diagnosed this —
snake_case slugs in TOML against kebab-case skill files — and it was
half-fixed: the kebab names were corrected, the snake_case ones left.
It was invisible because both existing tests assert authored ⊆ referenced
(30/30, green) and the second explicitly declines to check the other
direction. So the failing half was the half nobody asserted.
Resolved every name by one of three explicit choices:
- 23 skills authored where the role genuinely needed the procedure
(gpu, threejs, research, analysis, frontend, mobile, backend, platform)
- renames onto authored skills where one existed in substance, including
the four-near-duplicate cases that collapse onto one real skill
- 22 aspirational references deleted — a binding an agent cannot read is
a promise, not a capability
Two tests now hold it. The unit test checks referenced ⊆ authored against
the files. The new integration test runs both loaders in boot order and
asserts the bindings survive the trip through the database, which is a
different question: resolution goes through skills_catalog rows, so a skill
file that exists but fails to ingest still leaves the role empty.
Negative controls: the unit test failed naming all 55; the integration test
fails naming the exact role when one name is reverted.
threejs.shader_author and .perf_engineer gained a second and third skill
after the collapse — pin_in_context pins idx < 2, so a role left with one
skill silently pins less than the policy intends.
Co-Authored-By: Claude Opus 5 <[email protected]>
2.2 KiB
name, description, when_to_use, tags
| name | description | when_to_use | tags | ||
|---|---|---|---|---|---|
| playwright-e2e-patterns | Writing end-to-end tests that fail only when the product is broken — selectors, waiting, and isolation. | You are the tester on a frontend team writing or fixing browser tests. |
|
A flaky E2E test is worse than no E2E test
It trains the team to re-run rather than investigate, and the day it catches a real bug, nobody believes it. Everything below is about determinism.
Select by what the user sees
page.getByRole("button", { name: "Save" }) // best
page.getByLabel("Email")
page.getByTestId("mission-card") // when semantics genuinely absent
page.locator(".btn-primary > span:nth-child(2)") // never
Role and label selectors survive restyling and break when the UI genuinely changes meaning — which is exactly the failure you want. CSS-path selectors break on every refactor and pass while the button is invisible.
Never sleep
await page.waitForTimeout(2000); // flaky, always
await expect(page.getByText("Saved")).toBeVisible(); // waits for the condition
Playwright's assertions retry until timeout. A fixed sleep is either longer than needed (slow suite) or shorter than needed on a loaded CI box (flake). There is no correct constant.
For network, wait on the response rather than a duration:
const done = page.waitForResponse(r => r.url().includes("/api/missions"));
await page.getByRole("button", { name: "Create" }).click();
await done;
Each test creates what it needs
Tests that share a fixture pass in isolation and fail in parallel — or worse, pass in the order you wrote them and fail when one is skipped. Create the data in the test, key it with a unique id, and let cleanup be optional.
Assert the user-visible outcome
Assert the success message and the row in the table, not the POST that fired. A test asserting the request passes while the response is silently discarded — which is precisely the bug the test existed to catch.
When a test fails, look at the trace
--trace on records DOM snapshots, network and console for every step. Reading
the trace takes a minute and answers the question; re-running takes a minute and
answers nothing.