Minimize tokens and maximize accuracy in web research

This skill is a protocol for token-efficient web research. It governs how an assistant accesses URLs, GitHub repositories, and search queries, and it prevents the waste of fetching full pages. The core principle is to fetch the minimum needed to answer, skim before diving in, and stop as soon as the question is answerable. Every unnecessary fetch wastes tokens and adds noise, so the skill escalates fetch depth only when shallower layers fail.

The first step is to classify the input and route it to one of five protocols: a GitHub repository URL, a specific page URL, a topic or query with no URL, multiple URLs, or a PDF or file link.

• GitHub protocol: parse the URL (repo root, directory, file, issue, or pull request) and prefer the GitHub API, which returns clean JSON, over scraping. Layer 1 fetches repo metadata and the README only, and stops if that answers the question. Layer 2 fetches the file tree and picks one to three relevant files. Layer 3 fetches only those specific files, never all of them. The README alone answers roughly 70 percent of what-does-this-repo-do questions. Never fetch more than three files in one turn, read only the top of files over about 300 lines, and decode base64 API content first.
• URL protocol: assess the site type. Static docs, news, blogs, and raw GitHub files work with a plain content reader, while single page apps and auth-gated pages need a browser subagent. Layer 1 skims headings and the first paragraph, layer 2 extracts a targeted section (200 to 500 tokens), layer 3 fetches the full page with boilerplate stripped and capped at 2000 tokens, and layer 4 uses the browser subagent only as a last resort for empty, garbled, or JavaScript placeholder content. Strip navigation, cookie banners, related-article blocks, footers, share buttons, and ads, and keep the main body, code blocks, data tables, and numbered procedures.
• Search protocol: never search the raw user query. Sharpen it by adding specificity such as versions, technology names, and tutorial, guide, or comparison, adding the current year if relevant, removing filler words, and naming the language and framework for code questions. Scan titles and snippets only, pick the top one or two results (three at most), skip forums when docs exist, aggregator blogs, and paywalled sites, and prefer official docs, GitHub repos, well-known tech blogs, and academic sources. Never read more than three URLs per query, and if a snippet already holds the answer, use it.
• Multi-URL protocol: skim all, group by relevance, deep-fetch the best one to three, summarize each in three to five sentences, and never dump raw content from several pages.
• File protocol: markdown, text, and CSV can be read in full; PDFs need a browser subagent or extraction tool; JSON and YAML are parsed and summarized; large files get the first 100 lines, the last 20 lines, and a targeted search.

Use it whenever the task involves accessing URLs, GitHub repositories, or running search queries and you want to control token cost. Avoid its anti-patterns: fetching a full page for a simple fact, using the browser subagent for static sites, searching with the raw query, fetching five or more results, dumping raw HTML into context, fetching just in case, re-fetching the same URL, and fetching an entire repository.

Know its limits. Standard fetching may not fully render single page applications, so fall back to the slower, costlier browser subagent. It cannot bypass CAPTCHAs, strict bot protections, or hard paywalls. Frequent unauthenticated GitHub API requests may hit rate limits.

The input is a URL, a list of URLs, or a question. The output is a structured answer in a fixed format with four fields: the source (a URL, or a web search and its query), a summary of two to five sentences on what was found, a direct answer to the user's question, and a confidence rating of high, medium, or low based on source quality.

For several sources, the output lists each source and then a combined answer. Never output raw HTML fragments, full page dumps, unattributed information, or more than needed.

The protocol names its tools: a URL content reader, a web search tool, a browser subagent, and the GitHub API endpoints for repository metadata, file trees, file contents, and the README.

The token budget guide gives approximate costs: a README fetch of 300 to 800 tokens, API metadata around 200, a headings skim 100 to 200, a targeted section 300 to 600, a stripped full page 1000 to 2000, a browser subagent 2000 to 5000, and a search snippet scan 300 to 500. The rule of thumb is to look for a cheaper path before spending more than 2000 tokens on a fetch.

It is for agents and developers who do frequent research and want accurate answers at the lowest token cost, without dumping whole pages or repositories into context.