browser-automation

Name: browser-automation
Author: alexei-led

35stars5forks

How to install browser-automation?

alexei-led/cc-thingz/browser-automation

$npx -y skills add alexei-led/cc-thingz --skill browser-automation

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# Browser Automation
2
3	Use this for browser exploration, validation, screenshots, recordings, frontend
4	debugging, accessibility checks, and E2E/user-flow testing. Do not delete,
5	reset, or mutate non-test data without explicit user confirmation.
6
7	If the app cannot be started, auth is missing, or fixtures are unavailable,
8	report BLOCKED instead of inventing passing results.
9
10	## Runtime Order
11
12	1. Use built-in browser tools first when they are visible in the current Claude
13	Code session. If the user wants Claude in Chrome and no browser tools are
14	visible, tell them to enable `claude-in-chrome` with `/mcp`.
15	2. Use the project's configured browser runner when it exists.
16	3. Use `playwright-skill` only as the bundled fallback/runtime reference.
17	4. If no runtime is available, report BLOCKED with the missing tool/package.
18
19	Use browser tools for rendered state: navigation, click/type/select, DOM or
20	accessibility snapshots, screenshots, console logs, network inspection, and
21	read-only page JavaScript. Use Bash for dev-server setup, project runners, and
22	repeatable tests.
23
24	## Arguments
25
26	- `explore <url\|feature>` → inspect rendered page state
27	- `verify <feature>` → validate a feature in the browser
28	- `screenshot <url\|feature>` → capture visual evidence
29	- `record <flow>` → record or script a manual browser session
30	- `test [target]` → run or generate browser/E2E tests
31	- empty → ask which browser task to run
32
33	If no argument is provided, ask one question:
34
35	- Action: What browser task should I run? Options: Explore, Verify, Screenshot,
36	Record, Test.
37
38	## Prepare App and Data
39
40	Before any browser action, include dev-server detection/startup and safe test
41	data setup.
42
43	1. Detect the app start command from browser config, package scripts, Makefile,
44	README, or existing docs.
45	2. If a running app is needed, check whether the configured `baseURL` or target
46	URL is reachable. Start it only when the command is known.
47	3. Use deterministic fixtures: seeded users, fixed dates, stable IDs, reset
48	database state, and mocked external services when needed.
49	4. Avoid production data, local user state, random order, wall-clock dependence,
50	and previous-run state.
51
52	## Execute
53
54	### Built-in Browser Tools
55
56	When browser tools are visible, use them directly:
57
58	1. Navigate to the target URL.
59	2. Inspect snapshot/rendered state before interacting.
60	3. Click, type, select, or submit using accessible targets.
61	4. Capture artifacts needed to support the result.
62	5. Verify user-visible outcomes.
63
64	Use read-only page inspection JavaScript only for diagnosis. Do not mutate app
65	state through console scripts unless the user asked for that exact action.
66
67	### Project Browser Runner
68
69	Run the project's configured browser command. Infer the package manager from the
70	lockfile. Do not invent a runner.
71
72	### Playwright Helper Fallback
73
74	Load `playwright-skill` for exact helper setup and invocation. Write temporary
75	scripts to `/tmp/playwright-*.js`; never write generated files into the helper
76	directory or project unless permanent tests were requested.
77
78	## Browser Script Rules
79
80	- Prefer semantic locators: role, label, text, test id, CSS last.
81	- Never use fixed `waitForTimeout` delays.
82	- Use waits/assertions on visible UI state, URL, selector, network state, or
83	accessibility snapshot.
84	- Prefer visible/headed mode for exploration and screenshots. Use headless for
85	CI or when requested.
86	- Keep temporary scripts under `/tmp`.
87	- Keep permanent tests in the project's existing test layout only when the user
88	asked to add tests.
89
90	## Debugging Failed Checks
91
92	1. Read the browser or runner error output.
93	2. Capture current rendered state with a snapshot or screenshot.
94	3. Check console logs and failed network requests.
95	4. Fix the test or app only if fixing is in scope.
96	5. Re-run the narrow check once.
97	6. If still failing after two attempts, save evidence and stop.
98
99	## HTMX and SPA Notes
100
101	- Verify DOM updates after swaps or client-side route changes.
102	- Test triggers, form submissions, partial updates, and history behavior.
103	- Assert user-visible changes rather than implementation internals.
104	- Check relevant response headers and network calls when diagnosing.
105
106	## Output
107
108	```markdown
109	## Browser Automation Result
110
111	Action: <explore \| verify \| screenshot \| record \| test>
112	Result: <PASS \| FAIL \| BLOCKED>
113	Runtime: <built-in browser \| project runner \| playwright-skill \| unavailable>
114	Dev server: <reused \| started \| not needed \| blocked: reason>
115	Fixtures

People who liked this also viewed

6 picks

Type

browser-automation

35stars5forks

View on GitHub

How to install browser-automation?

alexei-led/cc-thingz/browser-automation

$npx -y skills add alexei-led/cc-thingz --skill browser-automation

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Browser Automation
2
3	Use this for browser exploration, validation, screenshots, recordings, frontend
4	debugging, accessibility checks, and E2E/user-flow testing. Do not delete,
5	reset, or mutate non-test data without explicit user confirmation.
6
7	If the app cannot be started, auth is missing, or fixtures are unavailable,
8	report BLOCKED instead of inventing passing results.
9
10	## Runtime Order
11
12	1. Use built-in browser tools first when they are visible in the current Claude
13	Code session. If the user wants Claude in Chrome and no browser tools are
14	visible, tell them to enable `claude-in-chrome` with `/mcp`.
15	2. Use the project's configured browser runner when it exists.
16	3. Use `playwright-skill` only as the bundled fallback/runtime reference.
17	4. If no runtime is available, report BLOCKED with the missing tool/package.
18
19	Use browser tools for rendered state: navigation, click/type/select, DOM or
20	accessibility snapshots, screenshots, console logs, network inspection, and
21	read-only page JavaScript. Use Bash for dev-server setup, project runners, and
22	repeatable tests.
23
24	## Arguments
25
26	- `explore <url\|feature>` → inspect rendered page state
27	- `verify <feature>` → validate a feature in the browser
28	- `screenshot <url\|feature>` → capture visual evidence
29	- `record <flow>` → record or script a manual browser session
30	- `test [target]` → run or generate browser/E2E tests
31	- empty → ask which browser task to run
32
33	If no argument is provided, ask one question:
34
35	- Action: What browser task should I run? Options: Explore, Verify, Screenshot,
36	Record, Test.
37
38	## Prepare App and Data
39
40	Before any browser action, include dev-server detection/startup and safe test
41	data setup.
42
43	1. Detect the app start command from browser config, package scripts, Makefile,
44	README, or existing docs.
45	2. If a running app is needed, check whether the configured `baseURL` or target
46	URL is reachable. Start it only when the command is known.
47	3. Use deterministic fixtures: seeded users, fixed dates, stable IDs, reset
48	database state, and mocked external services when needed.
49	4. Avoid production data, local user state, random order, wall-clock dependence,
50	and previous-run state.
51
52	## Execute
53
54	### Built-in Browser Tools
55
56	When browser tools are visible, use them directly:
57
58	1. Navigate to the target URL.
59	2. Inspect snapshot/rendered state before interacting.
60	3. Click, type, select, or submit using accessible targets.
61	4. Capture artifacts needed to support the result.
62	5. Verify user-visible outcomes.
63
64	Use read-only page inspection JavaScript only for diagnosis. Do not mutate app
65	state through console scripts unless the user asked for that exact action.
66
67	### Project Browser Runner
68
69	Run the project's configured browser command. Infer the package manager from the
70	lockfile. Do not invent a runner.
71
72	### Playwright Helper Fallback
73
74	Load `playwright-skill` for exact helper setup and invocation. Write temporary
75	scripts to `/tmp/playwright-*.js`; never write generated files into the helper
76	directory or project unless permanent tests were requested.
77
78	## Browser Script Rules
79
80	- Prefer semantic locators: role, label, text, test id, CSS last.
81	- Never use fixed `waitForTimeout` delays.
82	- Use waits/assertions on visible UI state, URL, selector, network state, or
83	accessibility snapshot.
84	- Prefer visible/headed mode for exploration and screenshots. Use headless for
85	CI or when requested.
86	- Keep temporary scripts under `/tmp`.
87	- Keep permanent tests in the project's existing test layout only when the user
88	asked to add tests.
89
90	## Debugging Failed Checks
91
92	1. Read the browser or runner error output.
93	2. Capture current rendered state with a snapshot or screenshot.
94	3. Check console logs and failed network requests.
95	4. Fix the test or app only if fixing is in scope.
96	5. Re-run the narrow check once.
97	6. If still failing after two attempts, save evidence and stop.
98
99	## HTMX and SPA Notes
100
101	- Verify DOM updates after swaps or client-side route changes.
102	- Test triggers, form submissions, partial updates, and history behavior.
103	- Assert user-visible changes rather than implementation internals.
104	- Check relevant response headers and network calls when diagnosing.
105
106	## Output
107
108	```markdown
109	## Browser Automation Result
110
111	Action: <explore \| verify \| screenshot \| record \| test>
112	Result: <PASS \| FAIL \| BLOCKED>
113	Runtime: <built-in browser \| project runner \| playwright-skill \| unavailable>
114	Dev server: <reused \| started \| not needed \| blocked: reason>
115	Fixtures

People who liked this also viewed

6 picks

Type