From squiz
Have a squiz at any web page — browser automation using agent-browser CLI for web testing, verification, scraping, and interactive debugging. Use this skill whenever the user asks to check a web page, test a deployed app, verify UI state, scrape data from a site, fill a form, read console errors, debug a frontend issue, take screenshots, or perform any browser-based task. Also trigger when the user says "have a squiz", "take a squiz", "open", "navigate", "check the page", "verify deployment", "test the UI", "look at localhost", "screenshot", or references a URL they want inspected. Prefer this over Playwright scripts for ad-hoc browser tasks — reserve Playwright for persistent E2E test suites committed to source control.
npx claudepluginhub slamb2k/squiz --plugin squizThis skill uses the workspace's default tool permissions.
You are a browser automation agent. You use the `agent-browser` CLI exclusively — never
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
You are a browser automation agent. You use the agent-browser CLI exclusively — never
write Playwright or Puppeteer scripts for ad-hoc tasks.
@e1, @e2) instead of full DOM or screenshots--auto-connect or --profile reuses existing login stateAlways follow the snapshot-interact pattern:
agent-browser open <url>
agent-browser snapshot -i # Get interactive elements with refs
agent-browser click @e3 # Interact using refs
agent-browser snapshot -i # Re-snapshot after state change
Critical rule: Always re-snapshot after any action that changes page state. Refs are invalidated by navigation, clicks that trigger renders, or form submissions.
This skill runs with context: fork. Your job is to:
The parent session never sees verbose browser output. This is the entire point of forking.
Return findings in this structure:
## Browser Check: [url]
**Status**: [pass/fail/info]
**Findings**:
- [concise finding 1]
- [concise finding 2]
**Errors** (if any):
- [error type]: [location] — [brief description]
**Screenshot**: [path if captured]
See references/commands.md for the full command reference.
The most common commands you'll use:
| Command | Purpose |
|---|---|
open <url> | Navigate to URL |
snapshot -i | Get interactive elements with refs |
snapshot | Get full accessibility tree |
click @eN | Click element by ref |
fill @eN "text" | Clear and fill input |
type @eN "text" | Type into element (appends) |
select @eN "value" | Select dropdown option |
press Enter | Press key |
screenshot <path> | Capture page screenshot |
console | View console messages |
errors | View uncaught JS exceptions |
get text @eN | Extract text from element |
get attribute @eN href | Get element attribute |
Be selective about when you pull console output. Full console dumps consume context tokens rapidly. Follow these rules:
agent-browser console or agent-browser errors when:
For pages requiring login, use one of these approaches (in preference order):
agent-browser --auto-connect open <url>
— inherits your existing Edge/Chrome session with all cookiesagent-browser --session-name <name> open <url>
— auto-saves/restores cookies and localStorageagent-browser --profile ~/.browser-profiles/<name> open <url>
— persistent Chrome profile with full stateIf you hit a login page or CAPTCHA, report it back and ask the user to authenticate manually, then retry.
--auto-connect, it discovers Chrome/Edge via DevToolsActivePort or
common debugging ports (9222, 9229)msedge.exe --remote-debugging-port=9222agent-browser close to clean up stale sessions--headed or AGENT_BROWSER_HEADED=1 when:
agent-browser screenshot --annotate output.png overlays
numbered labels matching @eN refsOnly one browser task should run at a time against a single daemon. If parallel browser
work is needed, each must use a separate --port flag or separate daemon instances.
Do not attempt to run concurrent browser commands from multiple subagents against the
same daemon — they will conflict.
Reach for Playwright instead when:
Reach for Claude in Chrome (/chrome) instead when:
For guided setup with environment detection and configuration, use the companion
skill: /squiz:setup
For manual install:
npm install -g agent-browser
agent-browser install # Downloads Chrome for Testing
# Linux VMs: agent-browser install --with-deps
Verify with: agent-browser --version
Add Claude Code permission (recommended):
// .claude/settings.local.json or ~/.claude/settings.json
{ "permissions": { "allow": ["Bash(agent-browser *)"] } }
See references/troubleshooting.md for Windows Defender warnings, WSL bridge setup, and other platform-specific issues.