write-e2e-testlisted

# Skill: write-e2e-test Add one browser spec that a reviewer would not be able to tell from the specs already in the repo. Matching the neighbours matters more than matching any external best practice. A spec that is individually elegant and structurally foreign is a maintenance tax on everyone who touches it next. ## Preconditions 1. `.claude/test-profile.md` exists. If it does not, run **probe-conventions** first — without it you would be inventing an import path, and a spec that cannot resolve `test` is worse than no spec. 2. The profile lists a `browser` group. If it does not, this repo has no browser tests; ask before creating the first one, because it needs a fixture/context decision the user owns. 3. You know which flow is under test and where it starts. If not, use **clarify-scope**. ## Procedure ### 1. Read the neighbour before writing anything Open the two specs closest to the feature you are adding. Note, concretely: - the exact import block, in order; - how the test is titled and whether titles carry tags; - whether the body is flat or divided into steps, and how those step descriptions are phrased; - how the test reaches its starting state — a navigation call, a stored session, a setup hook; - what it asserts on, and whether assertions live in the spec or behind a model method. You are going to copy all six decisions. Deviating from one of them needs a reason you can say out loud. ### 2. Decide reuse before creating Search the model layer name