bosskuai-browser-automation · diff
git:20260716.6355db6 to git:20260813.53fd4ac
92 added, 19 removed. Audit A to A.
---
name: bosskuai-browser-automation
description: Use this skill for browser-level testing, UI verification, automated user flow testing, visual regression, and scraping JavaScript-rendered pages. Covers QA smoke tests through full user journey automation.
---
# BosskuAI Browser Automation
- Use this skill for browser-level testing, UI verification, automated user flow testing, visual regression, and scraping JavaScript-rendered pages. Covers QA smoke tests through full user journey automation.
+ ## When to use
- ## Fast Path
+ - Smoke-testing a web app after a deploy (console errors, network failures, CWV)
+ - Automated user flow testing (signup, checkout, onboarding)
+ - Visual regression checks at multiple breakpoints
+ - Verifying UI behavior that cannot be caught by unit or integration tests
+ - Scraping JS-rendered competitor or third-party pages
+ - Monitoring a live site for uptime or content changes
- 1. Confirm the requested outcome and constraints.
- 2. Use the smallest checklist needed; do not load the full playbook by default.
- 3. Produce the artifact, review, or decision in the user-requested format.
- 4. State verification performed and any remaining risk.
+ ## How this differs from nearby skills
- ## When To Open The Playbook
+ - **`bosskuai-integration-testing`**: covers API contracts, service-to-service calls, and backend integration correctness. Browser automation covers the browser layer — rendered UI, DOM interactions, network from the client perspective, visual output.
+ - **`bosskuai-rigorous-code-review`**: static analysis of code. Browser automation executes the running application.
+ - **`bosskuai-competitor-intelligence`**: strategic tracking of competitor changes. Browser automation is the execution layer that can serve that skill but has its own engineering focus (test stability, selectors, retries).
- Open `../../references/playbooks/bosskuai-browser-automation-playbook.md` only when the task needs detailed framework choices, longer checklists, examples, or implementation depth.
+ ## MCP requirements
- ## Default Output
+ | Tool | Role | Degradation |
+ |------|------|-------------|
+ | Playwright MCP | Browser automation (required) | Without Playwright MCP, provide script templates for manual execution; note Pencil is available in Cursor as an alternative |
+ | Chrome DevTools MCP (Google) | Runtime inspection, performance profiling, network analysis, accessibility audits (optional) | Without DevTools MCP, use Playwright's built-in tracing and Lighthouse CLI as alternatives |
- - Start with the answer or changed recommendation.
- - Use concise bullets for tradeoffs.
- - Avoid generic AI/SaaS phrasing.
- - For implementation work, include exact files, commands, tests, or review notes.
+ Note: When working in Cursor, Pencil (Cursor's built-in browser tool) can substitute for Playwright MCP for inspection tasks. For headless scripting and CI, Playwright is required.
- ## Verification
+ ## Workflow
- Before finalizing, check:
+ Choose one or more modes based on the task:
- - Did the output solve the actual request?
- - Are assumptions and risks visible?
- - Is there a concrete next action?
- - Did we avoid loading unnecessary specialist context?
+ ### Mode 1 — QA Smoke Test
+ 1. Navigate to the target URL and capture a full-page screenshot.
+ 2. Check browser console for errors (level: error, warn).
+ 3. Intercept network requests — flag any 4xx/5xx responses.
+ 4. Measure Core Web Vitals (LCP, CLS, FID/INP) if performance is in scope.
+ 5. Verify critical above-the-fold elements are visible.
+ 6. Output: pass/fail per check, screenshots, console log excerpt.
+
+ ### Mode 2 — Interaction Testing
+ 1. Map the user flow to test (e.g., signup → verify email → first use).
+ 2. Write Playwright steps: fill inputs, click, assert DOM state.
+ 3. Handle async waits with `waitForSelector` or `waitForResponse` — never fixed `sleep`.
+ 4. Test happy path first, then at least one error path (bad input, network failure).
+ 5. Output: step-by-step pass/fail, failure screenshots.
+
+ ### Mode 3 — Visual Regression
+ 1. Define breakpoints (mobile 375px, tablet 768px, desktop 1440px minimum).
+ 2. Take baseline screenshots if none exist; otherwise compare to stored baselines.
+ 3. Flag pixel diffs above threshold (default: 0.1% of pixels changed).
+ 4. Output: diff images, percentage change per breakpoint.
+
+ ### Mode 4 — Competitor / Third-Party Monitoring
+ 1. Confirm robots.txt allows crawling the target pages.
+ 2. Set a respectful request rate (minimum 2s between requests).
+ 3. Navigate and extract target data (pricing table, feature list, CTA copy).
+ 4. Store a timestamped snapshot for delta comparison.
+ 5. Output: extracted data, timestamp, diff from previous snapshot if available.
+
+ ### Mode 5 — DevTools Profiling (requires Chrome DevTools MCP)
+ 1. Open the target page in Chrome via DevTools MCP.
+ 2. Record a performance trace during the critical user action (page load, scroll, interaction).
+ 3. Capture memory snapshots to identify leaks or excessive allocations.
+ 4. Run Lighthouse audits (performance, accessibility, best practices, SEO).
+ 5. Inspect network waterfall for blocking resources, slow responses, or redundant requests.
+ 6. Check console for errors and warnings with source-mapped stack traces.
+ 7. Take responsive screenshots at mobile/tablet/desktop viewports.
+ 8. Output: performance metrics, Lighthouse scores, network waterfall summary, console errors, accessibility findings.
+
+ ## Output format
+
+ ```
+ ## QA Report — [Site/Flow] — [Date]
+
+ ### Summary
+ PASS / FAIL / PARTIAL — one-line verdict.
+
+ ### Results by section
+ | Check | Status | Notes |
+ |-------|--------|-------|
+ | Console errors | PASS | 0 errors |
+ | Network failures | FAIL | 2× 500 on /api/cart |
+ ...
+
+ ### Screenshots
+ [Attached / saved to path]
+
+ ### Recommended actions
+ Numbered list of issues requiring fix, ordered by severity.
+ ```
+
+ ## Guardrails
+
+ - Never automate login to third-party services (GitHub, Stripe, Google) without explicit user confirmation — credential exposure risk.
+ - Rate-limit all competitor or external scraping (minimum 2s between requests).
+ - Respect robots.txt — check before scraping any external domain.
+ - Do not commit credentials, session tokens, or cookies to any file or log.
+ - Prefer `data-testid` or semantic selectors over CSS class chains; document selector rationale.
+ - All Playwright scripts must handle timeouts gracefully — no infinite waits.
+ - Visual regression baselines must be stored and versioned; never auto-approve large diffs without human review.
+
+ ## Further reading
+
+ - `../../references/playbooks/browser-automation-detailed-playbook.md` — extended step-by-step workflow and detailed templates that complement this playbook.