band-play: Skill for Claude Code

Test review (Band Play)

Reviews one change to the Playwright test suite against the standard in references/rules.md and reports verified, severity-ranked findings in chat. Band Play is a browser extension with no backend of its own, tested in Chromium against Bandcamp page snapshots with a silent test audio.

• Writing, running and debugging tests: the playwright skill; test conventions: testing.md.
• The read-only e2e-reviewer agent runs this skill in a separate context.
• Changes under src/: the read-only code-reviewer agent, not this skill.
• The suite lives in playwright.config.ts, tests/unit/**, tests/helpers/**, tests/setup/** (the dist project that builds dist/), tests/e2e/** (including seed.spec.ts for the Playwright test agents) and tests/live/**. CI test steps: npm run test:unit in job build and job e2e in .github/workflows/build.yml, plus .github/workflows/markup.yml (daily snapshot refresh, e2e and live; it commits snapshots to master and opens a markup-drift issue on failure).
• GitHub: the repository is borbiuk/band-play; run gh as GH_TOKEN=$(gh auth token --user borbiuk) gh … -R borbiuk/band-play, never gh auth switch.

Hard rules

1. Read-only. Never edit, create or delete files; never stage, commit, push, fetch, check out or stash; never comment, review or approve on GitHub. The deliverable is the chat report. If asked to post or fix, say this skill only reviews: the user or the main session applies fixes.
2. Review the change, not the suite. Findings target lines the change adds or modifies, plus existing code the change makes wrong. A problem in untouched code is at most one "FYI (pre-existing)" line.
3. Every finding is verified against the full file, and by Grep when you claim something is missing, unused or duplicated. Drop what you cannot prove; never write "please verify that…".
4. One problem = one finding. The same rule with the same fix in several places is one finding, anchored at the first occurrence, listing the others. A different rule or a different fix is its own finding.
5. Budget: at most 8–10 standalone findings: every Critical and Major, plus Minor findings that repeat widely or touch the fixture architecture. Other Minor findings go into one grouped list. More than 10 Critical and Major findings → all of them are standalone anyway.
6. No nits. Formatting is Prettier's job.
7. Language: findings in English; the chat framing in the user's language.
8. Code from the change runs only with care. Lint, type check, --list and test runs execute the change's code (config, fixtures, specs at collection time). Run them only on the local working tree, and for a pull request only when the user has checked it out. For a pull request from a fork or an unfamiliar author, first read the diffs of package.json, package-lock.json, .npmrc, playwright.config.ts, eslint.config.mjs, tsconfig*.json, the fixtures and capture-pages.mjs; run nothing if they add lifecycle scripts, registries, git or tarball URLs, or code that runs at load, and say why in the header. Never npm install; run Playwright only as npx --no playwright …, so npx never downloads a package. Never run the live project or npm run test:snapshots (both use the network) unless the user asks.