alexei-led/browser-automation
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.
$ 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 5, 2026, 3:39 AM8.7s4 files scanned
SKILL.md
- name:
- browser-automation
- description:
- >-
- rendered DOM:
- inspect UI state, click/fill forms, debug frontend behavior,
Browser Automation
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.
Runtime Selection
- Prefer a platform built-in browser tool when available in the active tool
list. See
references/platform-browser-tools.md. - 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 the cheapest runtime that proves the claim.
Workflow
- Define the goal: explore, validate, screenshot, record, debug, or test.
- Read needed local context: start scripts, browser config, routes, fixtures, seed/reset docs, and auth notes.
- Detect or start the dev server. Reuse a reachable server.
- Use deterministic data: seeded users, fixed dates, stable IDs, reset state, and mocked external services.
- Drive with semantic targets first: role, label, text, test id; CSS last.
- Capture artifacts needed to support the result: screenshot, trace, console errors, network failures, accessibility snapshot, manifest, or report.
- Prefer screenshot/manifest evidence for visual checks in headless harnesses.
- Report pass, fail, or blocked. Do not imply success if the check did not run.
Playwright Fallback
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.
Script and Test Rules
- Write temporary scripts to
/tmp/playwright-<name>.jsor/tmp/playwright-<name>.spec.tswhen using the Playwright fallback. - Never use fixed sleep delays.
- Wait or assert on visible state, URL, selector, network state, or accessibility snapshot.
- Prefer headed mode only when the platform exposes a usable visible browser. In Pi or other headless harnesses, use headless screenshots plus manifests as visual evidence.
- Keep credentials, production data, and destructive actions out of browser automation unless the user explicitly approves.
Failure Handling
- No target URL: detect a local dev server; ask if none is found.
- Multiple reachable servers: ask which target to use.
- Missing auth or fixture data: ask for safe test credentials or report blocked.
- Runtime unavailable: report the missing tool/package and required enablement.
- Fix or re-run only when fixing is in scope.
- Failure after two scoped attempts: save evidence, quote the failing line or UI state, and stop.
Output Contract
## 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>
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