setup-browser-cookies
by garrytansetup-browser-cookies helps an agent import cookies from a real Chromium browser into a headless session. It supports authenticated QA and browser automation by reusing an existing login state, with an interactive domain picker to control which cookies are imported. Use it when you need setup-browser-cookies usage for logged-in pages, not a fresh credential flow.
This skill scores 68/100, which is enough to list but signals a modest-confidence install: it has a real, specific workflow for importing Chromium browser cookies into a headless browse session, yet users will still need to tolerate some setup opacity and missing companion documentation.
- Specific triggerability: the description and trigger phrases map directly to cookie import and authenticated-browser setup requests.
- Concrete operational intent: it opens an interactive picker UI to choose which cookie domains to import, reducing generic-prompt guesswork.
- Substantial workflow content: the SKILL.md body is large and includes headings, constraints, and code fences, suggesting more than a placeholder stub.
- No install command or support files are provided, so adoption may require users to infer setup and runtime dependencies.
- The file still contains placeholder markers, and the repository provides no references/resources/readme to help with edge cases or verification.
Overview of setup-browser-cookies skill
What setup-browser-cookies does
The setup-browser-cookies skill helps an agent import cookies from a real Chromium browser into a headless browsing session. It is aimed at authenticated QA and browser automation work where a site needs an already-logged-in state before testing can begin.
Who should install it
Install the setup-browser-cookies skill if you often need to:
- test pages behind login
- reproduce bugs in authenticated flows
- hand off a real browser session to automation
- avoid rebuilding auth state manually for every run
Why this skill is different
Unlike a generic prompt that says “log in first,” setup-browser-cookies adds an explicit cookie-import workflow and an interactive selection step. That matters when you need control over which domains are brought into the headless session, not just a vague instruction to authenticate.
When it is a good fit
setup-browser-cookies for Browser Automation is best when the browser state already exists in Chromium and your main job is to reuse it safely. It is less useful if you need full credential entry, MFA handling, or a brand-new auth flow from scratch.
How to Use setup-browser-cookies skill
Install the skill
Use the repo’s skill install flow for your environment, then confirm the skill is available under the setup-browser-cookies name. If your setup uses a skill manager, install the package, then verify the skill directory includes SKILL.md and SKILL.md.tmpl.
Start from the right task prompt
The skill works best when your request clearly says what authenticated browser state you need. Good inputs name:
- the target site or app
- the task to perform after login
- whether you want all cookies or only specific domains
- any browser constraints, such as Chromium-only access
A stronger prompt looks like: “Use setup-browser-cookies to import my Chromium cookies for example.com, then open the dashboard and verify the billing page loads as an authenticated user.”
What to read first
Before relying on the setup-browser-cookies usage flow, inspect:
SKILL.mdfor the exact operational stepsSKILL.md.tmplto see how the skill is generated and what is meant to be stable- the sections covering preamble, safe operations, and skill routing
Those parts matter more than a skim of the whole file because they tell you when the skill should run and what it expects from the session.
Practical workflow tips
For better results, tell the agent:
- which browser profile or machine holds the cookies
- whether you expect multi-domain auth
- what should happen if the cookie picker shows too many domains
- whether the goal is read-only verification or actions that mutate data
If the task is ambiguous, the skill may import the wrong domains or stop too early. Be explicit about the authenticated pages you care about, not just the site name.
setup-browser-cookies skill FAQ
Is setup-browser-cookies only for Chromium?
It is designed around importing cookies from a real Chromium browser into a headless session. If your browser state lives elsewhere, this skill may not be the best fit unless your workflow already bridges that gap.
Do I still need to provide login details?
Often no, if a valid browser session already exists. The setup-browser-cookies skill is for reusing authenticated state, not replacing an app’s login process with credentials entry.
Is this better than a normal prompt to “log in”?
Yes, when the bottleneck is session reuse. A normal prompt can ask for login behavior, but setup-browser-cookies install gives you a repeatable cookie-import pattern and a clearer trigger for authenticated browser work.
When should I not use it?
Do not use it if you need:
- a fresh account creation flow
- password reset steps
- manual MFA enrollment
- non-Chromium session transfer
In those cases, a broader browser automation skill or a task-specific login prompt is usually better.
How to Improve setup-browser-cookies skill
Give the skill the right session target
The best improvements usually come from better session targeting, not more instructions. State the exact site, the authenticated route, and the point at which the agent should stop after import. This reduces guesswork after the cookies are loaded.
Reduce ambiguity in cookie scope
If your environment spans multiple subdomains, say which ones matter. For example, “import cookies for app.example.com and api.example.com, but ignore marketing domains.” That helps avoid importing irrelevant domains that can clutter or confuse the session.
Plan for the first failure mode
The most common failure is incomplete auth state: the page loads but still shows a login wall, expired session, or partial access. When that happens, update the prompt with what was visible after import, which domain failed, and whether the browser profile already had a live session.
Iterate with outcome-based feedback
After the first run, refine the task with what the agent should verify:
- “confirm the account menu shows the logged-in user”
- “open the admin page and check that the session persists”
- “if import fails, ask before retrying with a different domain set”
That kind of feedback makes the setup-browser-cookies guide more effective than restating the original goal.