src/skills/browser-automation/SKILL.md
Browser automation for rendered UI exploration, validation, screenshots, recordings, and end-to-end flows. Use when a task needs an actual browser or rendered DOM: inspect UI state, click/fill forms, debug frontend behavior, capture evidence, verify a feature, or run/generate browser tests. NOT for API checks or pure logic tests where curl, unit tests, or JSDOM is cheaper.
npx skillsauth add alexei-led/claude-code-config browser-automationInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Use a real browser only when rendered behavior matters: UI state, navigation, forms, auth, screenshots, recordings, accessibility, visual checks, or end-to-end flows.
Keep automation temporary unless the user asks for permanent tests. Do not use a browser for plain HTTP API checks or pure logic tests.
references/platform-browser-tools.md.playwright-skill only as the bundled fallback/runtime reference.Use the cheapest runtime that proves the claim.
Use Playwright when no built-in browser tool exists, the project already uses Playwright, or a repeatable script/test is the best artifact.
If using the bundled helper, load playwright-skill for exact setup and
invocation. Use its turnkey screenshot helpers before writing custom batch
scripts:
node scripts/screenshot-url.js --url <url> --selector <ready-selector> --json
node scripts/screenshot-sequence.js --url-template '<url/{n}>' --from 1 --to 10 --json
Do not write generated files into the helper directory or project unless creating permanent tests was requested.
/tmp/playwright-<name>.js or
/tmp/playwright-<name>.spec.ts when using the Playwright fallback.## Browser Automation Result
Target: <page, feature, or flow>
Runtime: <built-in browser | project runner | playwright-skill | blocked>
Actions: <commands or browser action summary>
Result: <pass | fail | blocked>
Evidence: <screenshot/trace/output path or key observation>
Next Fix: <only when failing or blocked>
tools
Use when planning, executing, checkpointing, finishing, or inspecting lightweight spec-driven work. Runs one task at a time using `.spec/` markdown files and the bundled `specctl` helper. NOT for broad product discovery beyond a short requirement interview. NOT for generic implementation planning that does not read or write `.spec/` files.
development
Simple web development with HTML, CSS, JS, and HTMX. Use when working with .html, .css, or .htmx files, web templates, stylesheets, or vanilla JS scripts. NOT for React/Vue/Angular (use writing-typescript) or Node.js backends.
tools
Idiomatic TypeScript development. Use when writing TypeScript code, Node.js services, React apps, or TypeScript design advice. Emphasizes strict typing, boundary validation, composition, fast feedback, behavior tests, and project-configured tooling. NOT for Go, Python, Rust, plain HTML/CSS/JS, or server-rendered templates (use writing-web).
tools
Idiomatic shell development for POSIX sh, Bash, Zsh, Fish, hooks, CI shell steps, and scriptable CLI glue. Use when writing or changing `.sh`, `.bash`, `.zsh`, `.fish`, `.bats`, shell functions, shell pipelines, CI `run:` shell bodies, or command-runner recipes. Emphasizes portability, quoting, safe filesystem/process handling, non-TUI CLI tools, ShellCheck, shfmt, Bats, and ShellSpec. NOT for Python, Rust, TypeScript, Go, web code, or GitHub Actions workflow/job/permissions semantics; use operating-infra.