Skip to main content

browser-core-efficient

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

Informations de source

Dépôt
holaboss-ai/holaOS
Dernière activité de la source
26 juillet 2026 à 07:48
Langue détectée de SKILL.md
anglais
Étoiles
11 437
Forks
719

Options d'installation

Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.

Vérifiez les fichiers source

Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.

Affichage de SKILL.md

SKILL.md
Instructions source · Aperçu en lecture seule
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. - When a fact may live in custom-element attributes, `data-*` attributes, `href`s, 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.
Voir sur GitHub