browser-core-efficient

name	browser-core-efficient
description	Use when working in the embedded browser and you want the cheapest reliable interaction loop.

Browser Core Efficient

Use this skill when operating the workspace-embedded browser and efficiency matters.

Goals

• reduce browser tool round trips
• reduce large state snapshots
• reduce unnecessary screenshots and page text reads
• prefer reliable one-call actions over browse-then-browse-again loops

Default Loop

1. If the target is already known, use browser_act directly with locator signals.
2. If the target is semantically known but the page is large, use browser_find.
3. Use browser_get_state only for orientation or when the target is still unclear.
4. After page-changing actions, use wait_for on the action itself when possible.
5. Re-read state only if the action result is ambiguous.

Tool Selection

• Prefer browser_act over index-based tools when text, label, role, selector, or ref can identify the target.
• Prefer browser_find before browser_get_state when you know what you want but not where it is.
• Use browser_click and browser_type only when you already have a stable index from a fresh state snapshot.
• Use browser_select_tab and browser_close_tab instead of spending extra calls re-orienting around tabs.
• Use browser_wait for explicit stabilization, especially for URL changes, DOM changes, and download completion.

State Discipline

• Default to browser_get_state with compact detail.
• Do not request page text unless the task is primarily about reading content.
• Do not request screenshots unless DOM-first signals are insufficient.
• If a page change likely invalidated earlier refs or indexes, treat them as stale and re-locate the target.

Wait Discipline

• Prefer action-local wait_for over a separate follow-up wait call.
• Use interactive or domcontentloaded after lightweight transitions.
• Use full load completion only when the page truly needs it.
• Use download_started and download_completed for browser-triggered downloads instead of manual polling through state reads.

Escalation Rules

• Escalate to browser_get_state detail=standard only when compact state is insufficient.
• Escalate to include_page_text=true only when the page content itself is the task output.
• Escalate to screenshots for visual ambiguity, layout validation, canvas/chart/PDF content, or explicit user-visible confirmation.
• Escalate to debug or observability tools only after the cheaper path fails.