browser-access
Skill1 starsChanged 20 days agoApache-2.0View on GitHub
Decide whether browser access is needed and keep authorised checks narrow. Use for frontend or UI diagnosis, before proposing or using Chrome DevTools or other browser automation, and when the user explicitly requests browser interaction.
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 8 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 15
If the user explicitly requested browser interaction, proceed within that request.
- Distinctive: line 22
Do not ask to use the browser at the start of an ordinary investigation.
- Distinctive: line 28
If non-browser evidence establishes a real blocker or a fix that needs browser validation, explain:
- Distinctive: line 35
Ask through the question tool when available and wait for agreement before any browser tool call.
- Distinctive: line 46
Keep work on the agreed task and target.
- Distinctive: line 51
Use Lighthouse or performance traces only when needed for the authorised audit or performance investigation.
- Distinctive: line 53
If a materially different check becomes necessary, explain it and obtain agreement before widening the browser work.
- Distinctive: line 56
Stop when the required question is answered.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Browser Access
Browser tools require an explicit user request or agreement to a specific check. This includes listing tabs and taking snapshots. A URL, UI bug, named service, available tool, or loaded browser skill does not grant permission.
1. Gather The Right Evidence
- If the user explicitly requested browser interaction, proceed within that request. Do not ask them to authorise the same action again.
- For ordinary investigations, start with focused source and configuration reads, logs, existing tests, configured CLI/API access, or existing SSH routes. Choose the tool from the requested action and the evidence needed.
- A frontend or service mention does not imply opening its web UI. Use the existing non-browser access when it answers the question.
- Do not ask to use the browser at the start of an ordinary investigation.
Continue without browser access when the gathered evidence is sufficient.
2. Establish A Specific Need
If non-browser evidence establishes a real blocker or a fix that needs browser validation, explain:
- What remains unknown.
- Why the existing access cannot answer it.
- The smallest browser check needed and its target.
Ask through the question tool when available and wait for agreement before any browser tool call. Loading a browser skill or debugging entrypoint does not replace this permission step.
3. Run Only The Agreed Check
- Apply the chosen browser driver's skill or current documentation for tool mechanics. Prefer Chrome DevTools for browser diagnostics.
- The Chrome DevTools MCP is not always loaded. If its tools are unavailable, ask the user to enable it and wait. Do not work around it with another browser driver, a headless browser, or scripted CDP access.
- Keep work on the agreed task and target. Reuse gathered evidence rather than repeating navigation, snapshots, polling, or broad audits.
- Gather only the page state, console messages, or network requests needed for the specific issue. When reloading through Chrome DevTools, bypass the cache unless the user explicitly wants cached behaviour.
- Use Lighthouse or performance traces only when needed for the authorised audit or performance investigation.
- If a materially different check becomes necessary, explain it and obtain agreement before widening the browser work.
Stop when the required question is answered. Report the result and any remaining uncertainty without extending the session into an unrelated audit.
In this repository50 other files it gives its agents.
- AGENTS.mdAGENTS.md
- agentic-workflowsSkill
- asking-questionsSkill
- broSkill
- change-review-handoffSkill
- changeset-scopeSkill
- check-skill-updatesSkill
- chillSkill
- cleanup-unnecessary-variablesSkill
- code-reviewSkill
- decision-modelsSkill
- diagnoseSkill
- effect-principlesSkill
- evidence-firstSkill
- gh-stackSkill
- git-contextSkill
- github-development-rulesetsSkill
- github-repository-setupSkill
- grillingSkill
- handoffSkill
- herdr-workflowsSkill
- home-assistant-frontendSkill
- home-assistant-lit-renderingSkill
- human-step-guideSkill
- import-external-skillSkill
- lit-renderingSkill
- maintain-docsSkill
- npm-jsr-first-publishSkill
- opencode-effectSkill
- pitchfork-dev-serversSkill
- pkexec-rootSkill
- planSkill
- release-oxlint-rulesSkill
- remove-single-use-functionsSkill
- researchSkill
- retroSkill
- safe-process-signalsSkill
- session-coordinationSkill
- shared-workflowsSkill
- show-meSkill
- skill-prefixesSkill
- staged-implementationSkill
- task-focusSkill
- task-runnersSkill
- testingSkill
- to-questionnaireSkill
- types-enforce-tsSkill
- wranglerSkill
- writing-dot-skillsSkill
- writing-styleSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.