- name
- use-my-browser
- description
- Use when work depends on the user's live browser session or visible rendered state rather than static fetches, especially for browser debugging contexts or DevTools-selected elements or requests, logged-in dashboards or CMS flows, localhost apps, forms, uploads, downloads, media inspection, DOM or iframe inspection, Shadow DOM, or browser failures that look like soft 404s, auth walls, anti-bot checks, or rate limits.
Do not treat this skill as a generic browsing default. Route from the evidence you need, not from tool preference.
Every task must be classified before you choose a route:
static-capable: the evidence can be produced without live browser state, visible confirmation, or page interactionbrowser-required: the evidence depends on rendered state, interaction, live session behavior, or browser-only structures
Only static-capable tasks may fall back to static retrieval, curl, or other non-browser paths. Once a task is browser-required, stay on the browser path and mark missing capability as blocked instead of silently downgrading.
Prerequisite check
This skill is for work inside the user's live browser session, not for launching a separate fresh automation browser.
Before doing browser automation, confirm that your environment already has access to a live browser stack that can provide the capabilities the task depends on, such as page inventory, task-owned page creation, page selection, snapshots or visible-state reads, DOM inspection, text or form input, uploads, dialogs, console inspection, and network inspection. The exact stack does not matter here: confirm capability, not brand.
If the live browser stack is unavailable, do not attempt browser automation through this skill. Only static-capable work may fall back to static retrieval.
Live browser automation can trigger anti-bot or anti-automation defenses on some sites. Use browser interaction only when the task truly needs it, and avoid unnecessary repetitive actions once the needed evidence has been obtained.
Experience loop
Treat site patterns as part of the browser protocol, not as optional background reading.
For browser-required work, run this loop:
- As soon as the target domain is known, check whether a matching note already exists under
references/site-patterns/. - If a note exists, read it before the first meaningful browser mutation on that domain.
- During the run, watch for verified site-specific facts that would change how a future run should operate.
- Before you consider the task complete, decide whether the run produced a reusable fact, disproved an existing fact, or produced no reusable site-specific learning.
- If the run verified something reusable or disproved an existing claim, update the matching note before finishing.