oriz.in / skills

← skills.oriz.in

$skill invoke use-my-browser

use-my-browser

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:

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:

  1. As soon as the target domain is known, check whether a matching note already exists under references/site-patterns/.
  2. If a note exists, read it before the first meaningful browser mutation on that domain.
  3. During the run, watch for verified site-specific facts that would change how a future run should operate.
  4. 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.
  5. If the run verified something reusable or disproved an existing claim, update the matching note before finishing.

Do not create a domain note for one-off noise. Do not skip the end-of-run review just because the task itself succeeded.

Writeback is expected when a run verifies any of the following:

Decision guide

Start with the outcome, not the tool. Make the user’s goal explicit, define what counts as done, and choose the cheapest route that can still produce the right evidence.

Use this routing order:

  1. Decide whether the task is static-capable or browser-required.
  2. If the task is static-capable, load references/task-routing.md and stay on the cheapest route that still satisfies the evidence target.
  3. If the task is browser-required, load references/browser-playbook.md.
  4. If browser-required capability is uncertain in a fresh host session, also load references/browser-capability-matrix.md.
  5. If the user already has an active browser debugging context, such as a selected inspector element or network request, also load references/debug-handoff.md.
  6. If the browser-required task touches a logged-in dashboard, admin surface, CMS, editor, or any save / publish / update flow, also load references/control-plane-workflows.md.
  7. If the current failure shape suggests a soft 404, content-unavailable state, suspicious no-op interaction, auth wall, rate limit, or anti-automation defense, also load references/anti-automation-friction.md.
  8. If the browser-required task includes iframe, Shadow DOM, collapsed content, or lazy-loaded evidence, also load references/deep-dom.md.
  9. If the important evidence lives in an image, audio clip, or video, also load references/media-inspection.md.
  10. If browser work can be divided across independent page owners or sub-agents, also load references/parallel-browser-ownership.md.
  11. If you already know a reliable selector but need an MCP-native uid target, also load references/selector-bridge.md.
  12. If page actions leave state ambiguous, a page unexpectedly navigates, an old uid may have gone stale, or console / network inspection is now needed to explain the next browser decision, also load references/browser-recovery.md.
  13. If the target site already has a matching domain note under references/site-patterns/, read that note before operating on the site.

Treat the following as browser-required by default:

The normal happy path for a common task is this entrypoint plus one or two references, not the entire reference set.

Hard rules

Reference index

edit on github  ·  back to toolbox