CtrlK
BlogDocsLog inGet started
Tessl Logo

browser-core-efficient

Use when working in the embedded browser and you want the cheapest reliable interaction loop.

66

Quality

78%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./runtime/harnesses/src/embedded-skills/browser-core-efficient/SKILL.md
SKILL.md
Quality
Evals
Security

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.
  • When a fact may live in custom-element attributes, data-* attributes, hrefs, or hydration data rather than visible text, inspect that targeted page-local DOM source before concluding the fact is unavailable.
  • 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 browser_evaluate for narrow read-only extraction when the required fact is likely present in page-local attributes or hydration data but not exposed cleanly through visible text.
  • 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.
Repository
holaboss-ai/holaOS
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.