e2e-check
starsforks
How to install e2e-check?
faizkhairi/claude-code-blueprint/e2e-check
$npx -y skills add faizkhairi/claude-code-blueprint --skill e2e-checkRun E2E tests or interactive browser verification. Triggers on: 'run e2e', 'e2e test', 'browser test', 'check in browser', 'verify UI', 'interactive test'.
SKILL.md
| 1 | Run E2E tests or perform interactive browser-based verification using Playwright. |
| 2 | |
| 3 | ## Mode Detection |
| 4 | |
| 5 | Parse `$ARGUMENTS` to determine mode: |
| 6 | - **Runner mode** (default): Run the Playwright test suite via CLI |
| 7 | - **Interactive mode**: If `--interactive` or `interactive` appears in args, use Playwright MCP tools for manual browser walkthrough |
| 8 | |
| 9 | --- |
| 10 | |
| 11 | ## Runner Mode |
| 12 | |
| 13 | ### 1. Detect project |
| 14 | |
| 15 | From `$ARGUMENTS` or current working directory: |
| 16 | - Match project name from cwd (e.g., `my-app` if cwd contains `my-app`) |
| 17 | - Check `CLAUDE.md` in the project root for the configured dev port and test command |
| 18 | - No match: ask which project to target |
| 19 | |
| 20 | ### 2. Pre-flight check |
| 21 | |
| 22 | Check if the dev server is running on the expected port (read from `CLAUDE.md` or the project manifest): |
| 23 | |
| 24 | Use: `bash -c "curl -s -o /dev/null -w '%{http_code}' http://localhost:{port}/ 2>/dev/null"` or equivalent. |
| 25 | |
| 26 | If the server is NOT running: |
| 27 | - Report: "Dev server not running on port {port}. Start it with your project's dev command (e.g. `yarn dev`/`npm run dev`, `python manage.py runserver`, `bundle exec rails s`, `go run`, etc.), then re-run /e2e-check." |
| 28 | - **Do NOT auto-start the dev server.** Stop here. |
| 29 | |
| 30 | ### 3. Run tests |
| 31 | |
| 32 | Run the E2E test command from `CLAUDE.md` or the project manifest (e.g., `yarn test:e2e` or `npm run test:e2e` for JS, or `pytest tests/e2e` for Python). |
| 33 | |
| 34 | If a test filter was provided (e.g., `auth`), resolve it to the spec file path: |
| 35 | - `auth` → `tests/e2e/auth.spec.ts` |
| 36 | - Full path → use as-is |
| 37 | |
| 38 | ### 4. Parse output |
| 39 | |
| 40 | Extract from Playwright output: |
| 41 | - Total, passed, failed, skipped counts |
| 42 | - Duration |
| 43 | - On failure: spec file name, test name, error message |
| 44 | |
| 45 | ### 5. Report |
| 46 | |
| 47 | ``` |
| 48 | E2E Test Results -- {project} |
| 49 | ================================ |
| 50 | Total: X | Passed: X | Failed: X | Skipped: X |
| 51 | Duration: Xs |
| 52 | Baseline: {expected from CLAUDE.md} tests |
| 53 | |
| 54 | [If failures:] |
| 55 | FAILURES: |
| 56 | - {spec-file} > {test-name}: {error summary} |
| 57 | |
| 58 | [If screenshots saved:] |
| 59 | Screenshots: test-results/{spec-file}/ |
| 60 | ``` |
| 61 | |
| 62 | ### 6. On failure |
| 63 | |
| 64 | - Check `test-results/` directory for saved screenshots |
| 65 | - Analyze failure type: timeout? Element not found? Assertion mismatch? Network error? |
| 66 | - Suggest fix based on the failure pattern |
| 67 | |
| 68 | --- |
| 69 | |
| 70 | ## Interactive Mode |
| 71 | |
| 72 | Use Playwright MCP tools to manually verify a user journey in the browser. |
| 73 | |
| 74 | ### 1. Navigate |
| 75 | |
| 76 | Use `mcp__playwright__browser_navigate` to open `http://localhost:{port}` (port from `CLAUDE.md`). |
| 77 | |
| 78 | **ALWAYS use `localhost`, NEVER `127.0.0.1`** (cookie domain mismatch issues). |
| 79 | |
| 80 | ### 2. Default journey (if no specific flow in args) |
| 81 | |
| 82 | 1. Navigate to login page |
| 83 | 2. Fill credentials using `mcp__playwright__browser_fill_form` (use dev test credentials from `.env` or `.env.test`) |
| 84 | 3. Submit login form via `mcp__playwright__browser_click` |
| 85 | 4. Wait for dashboard to load via `mcp__playwright__browser_wait_for` |
| 86 | 5. Take snapshot via `mcp__playwright__browser_snapshot` to verify dashboard renders data (not empty state) |
| 87 | 6. Navigate to a key page (e.g., main feature list, report list) |
| 88 | 7. Verify data is present (not loading spinner, not error) |
| 89 | 8. Take screenshot via `mcp__playwright__browser_take_screenshot` as evidence |
| 90 | |
| 91 | ### 3. Custom journey |
| 92 | |
| 93 | If args specify a flow (e.g., `--interactive reports`), walk through that specific flow step by step using: |
| 94 | - `mcp__playwright__browser_navigate` for page navigation |
| 95 | - `mcp__playwright__browser_snapshot` to read current page state (DOM) |
| 96 | - `mcp__playwright__browser_fill_form` for form inputs |
| 97 | - `mcp__playwright__browser_click` for button/link clicks |
| 98 | - `mcp__playwright__browser_select_option` for dropdowns |
| 99 | - `mcp__playwright__browser_wait_for` for loading/transition states |
| 100 | - `mcp__playwright__browser_take_screenshot` for visual evidence |
| 101 | |
| 102 | ### 4. Report |
| 103 | |
| 104 | Summarize: |
| 105 | - What pages were visited |
| 106 | - What was verified (data rendered, forms worked, navigation succeeded) |
| 107 | - Any issues found (errors, empty states, broken elements) |
| 108 | - Screenshot paths for evidence |
| 109 | |
| 110 | --- |
| 111 | |
| 112 | ## Rules |
| 113 | |
| 114 | - **Always `localhost`, never `127.0.0.1`**, due to cookie domain issues |
| 115 | - **Dev port**: read from `CLAUDE.md` or the project manifest for the active project |
| 116 | - **Package manager**: check `CLAUDE.md` or detect from lockfile (`yarn.lock` → yarn, `package-lock.json` → npm) (non-Node stacks: detect the build/install tool from the manifest type, e.g. Gemfile.lock, poetry.lock, Cargo.lock, go.sum, etc.) |
| 117 | - **Never auto-start dev servers**: report and stop if not running |
| 118 | - **E2E baselines**: compare against baseline documented in `CLAUDE.md` |
People who liked this also viewed
6 picksType
- tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026
- qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026
- webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026
- playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 2026
