alexei-led/browser-automation
dist/claude/plugins/browser/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.
$ install --global
skillsauthnpx skillsauth add alexei-led/claude-code-config browser-automationInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jun 4, 2026, 5:03 AM245.8s1 file scanned
SKILL.md
- argument-hint:
- [explore|verify|screenshot|record|test <target>]
- context:
- fork
- description:
- Browser automation for rendered UI exploration, validation, screenshots,
- DOM:
- inspect UI state, click/fill forms, debug frontend behavior, capture evidence,
- name:
- browser-automation
- user-invocable:
- true
Browser Automation
Use this for browser exploration, validation, screenshots, recordings, frontend debugging, accessibility checks, and E2E/user-flow testing. Do not delete, reset, or mutate non-test data without explicit user confirmation.
If the app cannot be started, auth is missing, or fixtures are unavailable, report BLOCKED instead of inventing passing results.
Runtime Order
- Use built-in browser tools first when they are visible in the current Claude
Code session. If the user wants Claude in Chrome and no browser tools are
visible, tell them to enable
claude-in-chromewith/mcp. - Use the project's configured browser runner when it exists.
- Use
playwright-skillonly as the bundled fallback/runtime reference. - If no runtime is available, report BLOCKED with the missing tool/package.
Use browser tools for rendered state: navigation, click/type/select, DOM or accessibility snapshots, screenshots, console logs, network inspection, and read-only page JavaScript. Use Bash for dev-server setup, project runners, and repeatable tests.
Arguments
explore <url|feature>→ inspect rendered page stateverify <feature>→ validate a feature in the browserscreenshot <url|feature>→ capture visual evidencerecord <flow>→ record or script a manual browser sessiontest [target]→ run or generate browser/E2E tests- empty → ask which browser task to run
If no argument is provided, ask one question:
- Action: What browser task should I run? Options: Explore, Verify, Screenshot, Record, Test.
Prepare App and Data
Before any browser action, include dev-server detection/startup and safe test data setup.
- Detect the app start command from browser config, package scripts, Makefile, README, or existing docs.
- If a running app is needed, check whether the configured
baseURLor target URL is reachable. Start it only when the command is known. - Use deterministic fixtures: seeded users, fixed dates, stable IDs, reset database state, and mocked external services when needed.
- Avoid production data, local user state, random order, wall-clock dependence, and previous-run state.
Execute
Built-in Browser Tools
When browser tools are visible, use them directly:
- Navigate to the target URL.
- Inspect snapshot/rendered state before interacting.
- Click, type, select, or submit using accessible targets.
- Capture artifacts needed to support the result.
- Verify user-visible outcomes.
Use read-only page inspection JavaScript only for diagnosis. Do not mutate app state through console scripts unless the user asked for that exact action.
Project Browser Runner
Run the project's configured browser command. Infer the package manager from the lockfile. Do not invent a runner.
Playwright Helper Fallback
Load playwright-skill for exact helper setup and invocation. Write temporary
scripts to /tmp/playwright-*.js; never write generated files into the helper
directory or project unless permanent tests were requested.
Browser Script Rules
- Prefer semantic locators: role, label, text, test id, CSS last.
- Never use fixed
waitForTimeoutdelays. - Use waits/assertions on visible UI state, URL, selector, network state, or accessibility snapshot.
- Prefer visible/headed mode for exploration and screenshots. Use headless for CI or when requested.
- Keep temporary scripts under
/tmp. - Keep permanent tests in the project's existing test layout only when the user asked to add tests.
Debugging Failed Checks
- Read the browser or runner error output.
- Capture current rendered state with a snapshot or screenshot.
- Check console logs and failed network requests.
- Fix the test or app only if fixing is in scope.
- Re-run the narrow check once.
- If still failing after two attempts, save evidence and stop.
HTMX and SPA Notes
- Verify DOM updates after swaps or client-side route changes.
- Test triggers, form submissions, partial updates, and history behavior.
- Assert user-visible changes rather than implementation internals.
- Check relevant response headers and network calls when diagnosing.
Output
## Browser Automation Result
Action: <explore | verify | screenshot | record | test>
Result: <PASS | FAIL | BLOCKED>
Runtime: <built-in browser | project runner | playwright-skill | unavailable>
Dev server: <reused | started | not needed | blocked: reason>
Fixtures/Auth: <deterministic setup summary or blocker>
Artifacts: <screenshot/trace/video/report/log paths or none>
Details: <key observations, commands, tool actions, or test results>
Next Fix: <only when failing or blocked>
Related Skills
alexei-led/writing-shell
tools
VerifiedTrustedCommunity
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, or command-runner recipes. Emphasizes portability, quoting, safe filesystem/process handling, non-TUI CLI tools, ShellCheck, shfmt, Bats, and ShellSpec. NOT for Python, TypeScript, Go, web code, or infrastructure operations.
33SKILL.mdUpdated Jun 5, 2026
alexei-led/spec-flow
tools
VerifiedTrustedCommunity
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.
33SKILL.mdUpdated Jun 5, 2026
alexei-led/operating-infra
testing
VerifiedTrustedCommunity
Author, inspect, troubleshoot, and review infrastructure across IaC, Kubernetes, cloud resources, containers, CI/CD, and Linux hosts. Use when changing Terraform/OpenTofu, Kubernetes, Helm, Kustomize, Dockerfiles, GitHub Actions, AWS, GCP, Cloud Run, BigQuery, IAM, logs, instances, or service health. NOT for deploy/apply/rollback workflows (see deploying-infra). NOT for shell scripts or generic command pipelines (see writing-shell).
33SKILL.mdUpdated Jun 5, 2026
alexei-led/configuring-git-hygiene
development
VerifiedTrustedCommunity
Configure safe git workflow hygiene: pre-commit/pre-push hooks, Gitleaks secret scanning, .gitignore rules, local git config, and guardrails. Use when setting up git hooks, gitleaks/git leaks, staged pre-commit checks, pre-push validation, core.hooksPath, .gitignore, or git config best practices. NOT for creating commits (use committing-code), cleaning branches/worktrees (use cleanup-git), or creating worktrees (use using-git-worktrees).
33SKILL.mdUpdated Jun 5, 2026