--- name: effective-web-research version: "1.0.0" user-invocable: true description: "Effective web research discipline for AI agents — route first, then research with rigor. Step 0 triages whether a question needs external web lookup vs is answerable from the internal codebase/docs; when external, default mode auto-applies 4 maxims; on explicit 'strict/deep research' requests it runs a 7-dimension source-credibility evaluation (CRAAP + E-E-A-T) with an auditable report. When the static layer (WebSearch/WebFetch/curl) can't reach content (login-required / JS-rendered / anti-scraping like 小红书·公众号), it escalates to the real browser via the web-access skill (CDP, carries login state). Triggers: 「web 调研」「外部调研」「查资料」「有效调研」「严格调研」「深度调研」「严格查证」「登录态访问」「动态页面」「反爬」「这个库/框架怎么用」「有没有漏洞」「best practice 是什么」 / web research, look up, investigate, strict research, deep research, fact-check, login-state access, dynamic page, anti-scraping. Do NOT use for: searching the local codebase, reading repo files, grepping code." --- # effective-web-research Make every external web lookup **effective and credible**, and turn "deep research" requests into auditable, source-evaluated reports. Grounded in two established frameworks — **CRAAP** (decades of information-literacy science) and **Google E-E-A-T** (the web's dominant content-quality rubric) — so the rules are defensible, not opinionated. This skill is about the **external web**. It does not compete with internal code-search tools. ## When to use / When NOT to use **Use** when the agent is about to (or is asked to) gather information from the **external web** — official docs sites, third-party library docs, RFCs, reputable blogs, papers, real-world data. **Do NOT use** for: - Reading files inside the workspace/repo (`read`, `grep`, `ast-grep`) - Navigating the local codebase (`LSP`, `goto_definition`, `explore` agent) - Reading installed dependencies in `node_modules` / `venv` / `site-packages` - Creating or editing documents Those are internal search tasks with different tools and different quality bars. --- ## Step 0 — Triage: should this go external at all? Before any web search, decide whether external research is even the right move. Many questions agents reflexively google are answerable faster and more reliably from the internal codebase. Going external when the answer is local wastes effort and introduces uncertainty. | Task signal | Path | This skill's role | |-------------|------|-------------------| | Answer likely lives in the repo: our code logic, `AGENTS.md` conventions, existing skills, code comments, installed dependency source | **Internal first** — use `grep` / `read` / `LSP` / `explore`. Do not fire a web search. | Do not activate (a one-line "consider checking internal first" hint is fine) | | About a third-party library / framework / external API / tool behavior / version-specific quirk | **External** — web research | Default mode (4 maxims) applies | | Real-world information: news, market data, people, current events, papers | **External** | Default mode applies | | Hybrid — external concept + internal application ("is the X library we use vulnerable to Y", "apply pattern X to our code") | **External-then-internal** — research the concept externally, then verify/apply internally | External stage uses default/strict; internal stage uses internal tools | | Static layer can't reach the content (login required / JS-rendered / anti-scraping platform like 小红书·公众号) | **Escalate to CDP** via the `web-access` skill (runtime-checked; aborts with an install hint if web-access is absent) — real browser carries login state | web-access handles retrieval; this skill's credibility discipline still governs whatever is retrieved | **Triage signals**: - *Internal*: the question mentions "our / this project / this code / our convention", or the answer domain is clearly inside the repo. - *External*: the question names a third-party lib/framework/API/tool with a version, or asks "how to use / how it works / best practice / is there a vulnerability" about an external thing. - *Hybrid*: an external concept object + "our / apply to / check our" + an internal object. > If unsure, prefer internal first — it's faster and authoritative for "our own" questions. Escalate to external only when internal search comes up empty. --- ## Escalation — when the static layer can't reach the content (CDP via web-access) When WebSearch / WebFetch / curl / Jina return content that **lacks the target information** because the page refuses non-browser clients (login wall, JS-rendered shell, anti-scrape block on platforms like 小红书·公众号), load the **`web-access`** skill and follow its CDP guidance — it connects to the user's daily browser (login state native) and reaches the content via its curl HTTP API. This is a **runtime-local** dependency, not a frontmatter `dependencies` entry: the core research discipline works without `web-access`, and upstream workflows (known-issue-research → solve-workflow family) stay free of any external-plugin requirement. Verify `web-access` only when you actually escalate; if missing, abort and tell the user how to install it (no silent fallback). Retrieval is orthogonal to credibility — the 4 maxims / strict mode still evaluate whatever content CDP retrieves. For the escalation decision tree + curl API cheat sheet, see [reference.md · CDP upgrade](reference.md#cdp-upgrade). --- ## Default mode — 4 maxims (applied to every web search within an active task) When this skill is active for a task, apply these to every web search / `webfetch` you perform during that task. (Skills activate per-task when their description matches — these maxims then govern every search inside that task, not searches in unrelated tasks.) No extra artifact is produced. They exist because the web is full of outdated, low-authority, copied, and AI-generated content — without discipline, agents amplify the noise. ### 1. Authority-first **Source priority**: official docs/sites > authoritative secondary (MDN, official blogs, RFC/spec) > reputable community (high-vote StackOverflow answers, the official repo's issues/PRs) > general web. **Apply**: when web-search results come back, scan the **domain first** — is it the official site (`react.dev`, `developer.mozilla.org`, `nodejs.org`, `.`)? Read those before generic blogs. **Why it matters**: a 2019 blog's take on React Hooks is inferior to `react.dev`'s own documentation, yet search engines may rank the blog higher. ### 2. Currency check For **fast-moving topics** (frameworks, APIs, tools, security), find the page's publish/update date before trusting it. Content older than ~2 years is "possibly stale" — verify the claim against the official current-version docs. **Apply**: after `webfetch`, look for "Last updated" / article date / `