agentleFS
Sign inStart free
Williamunpalatable7706Williamunpalatable7706/ai-life-skills-toolkit/skills/core/use-preferred-browser/SKILL.md

use-preferred-browser

Skill0 starsChanged 2 months agoMITView on GitHub

Keep signed-in, personal, form, checkout, and handoff browser work in the user's chosen browser on Windows or macOS. Use when a page must be opened, shown, reviewed, signed into, or left ready for the user; do not switch browsers without the user's explicit approval.

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 9 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    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
  1. Distinctive:

    Use available context and safe, reversible defaults before asking for input.

    line 12
  2. Distinctive:

    When no visible page or signed-in session is needed, prefer a direct data connection or command-line tool over opening any browser at all.

    line 19
  3. Distinctive:

    When the page must be visible, signed in, reviewed, or handed back, use the browser the user named in the current turn or their locally …

    line 21
  4. Distinctive:

    If no preference exists, use the operating system's default browser and say which browser was selected before any personal or account …

    line 24
  5. Distinctive:

    Use background or automated browsers only for public, non-personal research or local web testing.

    line 26
  6. Distinctive:

    Never switch from the preferred browser to another browser merely because automation is easier there.

    line 31
  7. Distinctive:

    If the preferred browser fails, retry safe transient recovery.

    line 33
  8. Distinctive:

    Before irreversible publication, purchase, deletion, submission, or account change, show the exact final state and obtain any approval the …

    line 41
  9. Distinctive:

    Do not treat a browser-sync account, remote-desktop tool, or automation engine as permission to change the user's browser choice.

    line 50

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Use the Preferred Browser

Honor the user's browser choice as part of the task, not as a suggestion.

Keep momentum

Use available context and safe, reversible defaults before asking for input. Bundle non-blocking questions and continue useful work. Interrupt only when a missing choice would change the result, privacy, cost, authority, safety, or something hard to undo. Never repeat an answered question.

Route the work

  1. When no visible page or signed-in session is needed, prefer a direct data connection or command-line tool over opening any browser at all.
  2. When the page must be visible, signed in, reviewed, or handed back, use the browser the user named in the current turn or their locally configured preference.
  3. If no preference exists, use the operating system's default browser and say which browser was selected before any personal or account interaction.
  4. Use background or automated browsers only for public, non-personal research or local web testing.

Protect the handoff

  • Never switch from the preferred browser to another browser merely because automation is easier there. Ask for explicit approval for that exact switch.
  • If the preferred browser fails, retry safe transient recovery. If it remains unavailable, leave it at the exact destination when possible, report the blocker, and stop.
  • Let the user enter passwords, passkeys, MFA codes, recovery codes, security answers, and protected operating-system prompts directly. Never read, copy, log, or store those values.
  • A filled field, submitted request, processing indicator, and confirmed final result are different states. Verify the exact state the user requested.
  • Before irreversible publication, purchase, deletion, submission, or account change, show the exact final state and obtain any approval the workflow requires.

Platform notes

  • macOS users may choose Safari, Chrome, Firefox, Edge, or another installed browser. Treat Safari as a hard requirement only when the user says so.
  • Windows users may choose Edge, Chrome, Firefox, or another installed browser.
  • Do not treat a browser-sync account, remote-desktop tool, or automation engine as permission to change the user's browser choice.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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.

Check your setup, free