Navigates, clicks, types, scrolls, drags, queries DOM content, and captures screenshots.

<instruction>
- `"open"` starts a headless session (or implicitly on first action); `"goto"` navigates to `url`; `"close"` releases the browser
- The browser launches in **headless** mode by default (no visible window). If the user asks to "open Chrome", "show a browser", or needs to see the browser window, tell them to run `/browser visible` first — this switches to a visible Chrome window. Use `/browser headless` to switch back.
- `catalog_workflow_runner` always uses a visible Chrome session — it does not share this setting.
- **Not for the F5 XC console.** Driving F5 XC console CRUD from a natural-language request is a core, deterministic feature owned by the `catalog_workflow_runner` tool (extension-driven, catalog-defined steps from `xcsh://console/`).
  You **MUST NOT** use this generic `browser` tool for any F5 XC console page — it is headless/unauthenticated and lands on the Keycloak login wall. Read `xcsh://console/` and call `catalog_workflow_runner` instead.
- `"observe"` captures a numbered accessibility snapshot — prefer `click_id`/`type_id`/`fill_id` using returned `element_id` values; flags: `include_all`, `viewport_only`
- `"click"`, `"type"`, `"fill"`, `"press"`, `"scroll"`, `"drag"` for selector-based interactions — prefer ARIA/text selectors (`p-aria/[name="Sign in"]`, `p-text/Continue`) over brittle CSS
- `"click_id"`, `"type_id"`, `"fill_id"` to interact with observed elements without selectors
- `"wait_for_selector"` before interacting when the page is dynamic
- `"evaluate"` runs a JS expression in page context
- `"get_text"`, `"get_html"`, `"get_attribute"` for DOM queries — batch via `args: [{ selector, attribute? }]`
- `"extract_readable"` returns reader-mode content; `format`: `"markdown"` (default) or `"text"`
- `"screenshot"` captures images (optionally with `selector`); can save to disk via `path`
</instruction>

<critical>
**You **MUST** default to `observe`, not `screenshot`.**
- `observe` is cheaper, faster, and returns structured data — use it to understand page state, find elements, and plan interactions.
- You **SHOULD** only use `screenshot` when visual appearance matters (verifying layout, debugging CSS, capturing a visual artifact for the user).
- You **MUST NOT** screenshot just to "see what's on the page" — `observe` gives you that with element IDs you can act on immediately.
</critical>

<output>
Text for navigation/DOM queries, images for screenshots.
</output>
