Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →chorus-aidlc/e2e-verification
Use when manually verifying a Chorus frontend change in a real browser — finding local login credentials, driving the running dev server with the Playwright MCP, logging in, navigating to a page, and capturing snapshots/screenshots for e2e acceptance.
Passed 13 of 18 test cases with the skill, and 4 of 18 without it.
and 10 more in the full report
12 fixed4 passed either way5 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 12 test cases the skill fixed. Same model, same prompt, with and without the skill.
I need to find a screenshot named `dashboard-lineage.png` that was generated earlier. Should I run a file search command across the entire filesystem?
| Checked | Without skill | With skill |
|---|---|---|
| Accesses the file directly at .playwright-mcp/dashboard-lineage.png without running a filesystem search | Missed | Passed |
The instructions your model reads when the skill loads.
Drive the running Chorus dev server in a real browser via the Playwright MCP to verify UI changes end-to-end. Core loop: log in with local credentials → navigate → snapshot to read state / act → screenshot for the human.
This is manual acceptance, not the automated Vitest suite (pnpm test). Use it when an AC says "the user sees X" and only a real browser can confirm it.
curl -s -o /dev/null -w "%{http_code}" http://localhost:8637/login # expect 200
200 (connection refused, 500, or anything else), the server isn't running or is broken — start it with pnpm dev:local and re-check until it returns 200 before driving the browser. (Plain pnpm dev works too, but pnpm dev:local brings up the full local stack.)ToolSearch("select:mcp__playwright__browser_navigate,mcp__playwright__browser_snapshot,mcp__playwright__browser_take_screenshot,mcp__playwright__browser_click,mcp__playwright__browser_fill_form")Local dev uses the default-auth path (plain email + password on /login). Read it from the .env file at the repo root:
grep -E "DEFAULT_USER|DEFAULT_PASSWORD" .env
# DEFAULT_USER="[email protected]"
# DEFAULT_PASSWORD="chorus"
DEFAULT_USER logs in as a regular workspace user (e.g. [email protected]). This is NOT the same as SUPER_ADMIN_EMAIL (the /login/admin panel) or the Cognito OIDC flow described in the older .claude/skills/oidc-login.md — for normal page verification you want default-auth.
When default-auth is enabled, /login shows the email+password form directly (no SSO redirect):
browser_navigate → http://localhost:8637/loginbrowser_snapshot → grab the ref of the Email box, Password box, and "Sign In" button.browser_fill_form with both fields:
[{ name: "Email", target: "<email-ref>", type: "textbox", value: "[email protected]" },
{ name: "Password", target: "<password-ref>", type: "textbox", value: "chorus" }]
test cases passed, vs 4 / 18 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.