browser-core-efficient
The browser-core-efficient skill optimizes interactions with the embedded browser by minimizing API calls and state reads through direct action targeting, selective state inspection, and intelligent wait strategies. Use this skill when cost efficiency is critical and the browser task involves known or semantically identifiable targets that benefit from streamlined one-call actions rather than iterative browse-and-read loops.
git clone --depth 1 https://github.com/holaboss-ai/holaOS /tmp/browser-core-efficient && cp -r /tmp/browser-core-efficient/runtime/harnesses/src/embedded-skills/browser-core-efficient ~/.claude/skills/browser-core-efficientSKILL.md
# 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.
Build a new holaOS app using @holaboss/app-builder-sdk (5 backend primitives + optional shadcn dashboard UI). The canonical path for vibe-coded apps — integration modules AND dashboard apps both live here.
Use when validating or debugging a workflow in the embedded browser and you need a reproducible, evidence-first loop.
Build the visual layer of a holaOS dashboard app — TanStack Start + @holaboss/ui + workspace tokens. Use when an app has SDK primitives wired (via app-builder-sdk) AND needs a `src/client/` UI surface. NOT for marketing pages, NOT for snapshot HTML reports.
Provision a production-ready teammate only after its stable responsibilities, prerequisites, and reusable operating guidance are understood.
Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications. Generates creative, polished code that avoids generic AI aesthetics.
This skill is for interface design — dashboards, admin panels, apps, tools, and interactive products. NOT for marketing design (landing pages, marketing sites, campaigns).
Add or update workspace MCP servers using holaOS mcp_registry syntax.
Guide for creating effective skills. Use when creating or updating a skill.