browser-qa
The browser-qa skill provides a structured methodology for validating, debugging, and reproducing issues within an embedded browser environment. Use it when you need to isolate product failures from environment issues, minimize browser interactions, and gather only the evidence required to confirm or explain a specific behavior, following a disciplined loop of reproduction, diagnosis, and targeted evidence capture.
git clone --depth 1 https://github.com/holaboss-ai/holaOS /tmp/browser-qa && cp -r /tmp/browser-qa/runtime/harnesses/src/embedded-skills/browser-qa ~/.claude/skills/browser-qaSKILL.md
# Browser QA Use this skill when the task is browser validation, repro, regression checking, or investigation in the workspace-embedded browser. ## Goals - reproduce the issue with the fewest browser calls possible - separate product failure from wait or locator failure - capture only the evidence needed to explain the result ## Repro Loop 1. State the exact starting page, tab, and account state you are testing. 2. Use the cheapest path that can reproduce the behavior. 3. After each page-changing step, use explicit waits rather than repeated broad state reads. 4. If a step fails, determine whether it is: - wrong target - stale target - missing wait - auth or session state - true product behavior 5. Capture evidence only after the failure is stable and reproducible. ## Tool Discipline - Prefer `browser_act` with `wait_for` over separate click then wait loops. - Use `browser_find` when the target is known but compact state did not include it. - Use `browser_get_state detail=compact` for orientation and `detail=standard` only when compact state is insufficient. - If the page should expose the fact directly, inspect targeted custom-element attributes, `data-*` attributes, `href`s, or hydration data with a narrow read-only `browser_evaluate` before treating the fact as unavailable. - Use `browser_get_console`, `browser_get_errors`, and `browser_list_requests` only after the cheaper orientation/action path failed or the issue is clearly runtime/network-related. - Use `browser_get_request` only for one suspect request after `browser_list_requests` narrowed the field. - Use `browser_storage_get` and `browser_cookies_get` to inspect auth or state flags before rerunning a long login flow. - Use `browser_storage_set` and `browser_cookies_set` only for controlled state repair, not as a default shortcut. ## Evidence Rules - Capture screenshots only for visual ambiguity, layout issues, or user-visible confirmation. - Read page text only when the task depends on the content itself. - Treat page-local DOM evidence as primary evidence when the target page appears to render the needed fact; use third-party proxies or alternate sites only as fallback evidence. - When a download is involved, prefer `download_started` and `download_completed` waits plus `browser_list_downloads`. - Preserve the exact failing condition in the final report: target, wait, URL, and observed result. ## Final Reporting - Report whether the behavior reproduced. - Report the smallest reliable repro path. - Report whether the failure appears to be locator, timing, session state, or product behavior. - Include only the minimum evidence needed to justify the conclusion.
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 working in the embedded browser and you want the cheapest reliable interaction 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.