Stop fighting the DOM. Read it first, find the API behind it, skip the UI entirely when possible.
Never blind-click. Always snapshot first.
text
1. browser snapshot → read the page, get element refs
2. browser act → use refs from snapshot (e.g. ref="e12")
3. browser snapshot → verify what changed
If the snapshot doesn't show what you need, the element isn't in the DOM. Don't guess. Don't retry the same approach.
On any browser task, follow this order:
web_fetch handles it. If yes, don't open the browser.references/api-discovery.md. Most SPAs make fetch/XHR calls you can replicate directly. This is 10x faster and more reliable than UI automation.loadState: "networkidle" or a brief wait before snapshotting. SPAs often render asynchronously.SymptomWrong approachRight approach"Element not found"Click by text/selector guessSnapshot first, use exact ref"DOM not exposed"Give upSnapshot with refs="aria", or check network tab for APIBlank/empty pageRetry same URLloadState: "networkidle", then snapshot. If still blank, JS-heavy SPA, try web_fetch or find APIClicking does nothingClick again harderSnapshot after click to check state. Maybe it DID work but page re-renderedLogin wallTry to automate loginUse profile="user" for existing session cookiesInfinite scrollScroll and prayFind the pagination API endpoint instead
Most modern websites are SPAs with REST/GraphQL APIs behind the UI. See references/api-discovery.md for the full procedure:
web_fetch or exec curlThis turns a 2-hour flaky scrape into a 2-minute clean data pull.
refs="aria" for stable cross-call referencestargetId across snapshot/act pairs (don't switch tabs accidentally)depth to limit how deep the DOM tree goescompact: true reduces token usage on large pagesweb_fetch (faster, no browser overhead)web_search (Brave API)web_fetch → then use browser