Web Tool Decision Strategy

Problem Background

Web information retrieval is often treated as a fixed pipeline: search first, fetch next, then fall back to a browser on failure. In practice, the right tool depends on whether a URL is known, whether the page is static, and whether login or interaction is required. This skill treats web_search, web_fetch, opencli, and browser as branching decisions rather than a strict hierarchy, reducing unnecessary heavy browser use and avoiding silent failures.

How It Works

The core is a ReAct-style decision strategy:
- No explicit URL: start with web_search to collect clues, then inspect the returned URLs before choosing the next step.
- Known static URL: use web_fetch for articles, docs, API endpoints, or RSS feeds.
- Structured data needs: if search or fetch fails and the target is a common site, try opencli first because it is lighter than a full browser.
- Dynamic, login, interaction, or screenshot needs: escalate to browser for element waiting, CSS selector targeting, clicking, typing, or capture.

Important constraints include explaining why a tool is changed, requiring user confirmation for login and irreversible actions, and waiting for meaningful elements instead of fixed sleep delays. If web_search fails, the skill guides the user through the relevant configuration document and completes API setup only after user consent; otherwise it follows a limited fallback path.

Scope and Caveats

It fits public research, article extraction, structured reads on known sites, and restricted pages that need login state or interaction. For CAPTCHA, payment, posting, deletion, or other high-risk scenarios, it pauses for human intervention instead of bypassing protections automatically. If the target is not in the known-site list and web_fetch returns blank pages, 403 responses, or skeleton HTML, manual review or additional user-provided URLs and credentials are required.