| Mode |
Approach |
Best For |
search (default) |
1–2 WebSearch calls, summarize titles/snippets |
Quick facts, current events, quick lookups |
reason |
2–4 WebSearch calls + WebFetch top results, cross-reference |
Comparisons, problem-solving, multi-source analysis |
research |
Fan-out searches (different angles) + fetch primary sources + adversarial verification |
In-depth reports, market analysis, literature reviews |
Rule: Default to search. Escalate to reason when sources disagree. Reserve research for exhaustive analysis with citations.
search mode
- One targeted
WebSearch query.
- If results sufficient, synthesize answer with source URLs.
- If insufficient, run one refined query.
reason mode
- Run 2–4
WebSearch queries from different angles (technical docs, comparison articles, recent posts).
WebFetch the top 2–3 most authoritative URLs.
- Cross-reference claims; flag disagreements between sources.
- Synthesize with inline citations:
[per docs.example.com].
research mode
- Decompose question into 4–6 sub-questions.
WebSearch each sub-question in parallel.
WebFetch primary sources (official docs, vendor announcements, peer-reviewed where applicable).
- Adversarially verify key claims (search for counter-evidence). Prioritize verify budget on load-bearing claims — anything that would inform code, config, or an architectural decision. In practice, 15–20% of initial claims are wrong-but-plausible (the model's prior is strong; adversarial search is what surfaces the counter-evidence). Do NOT ship any claim that would drive code changes without a passing verify. Deprioritize verify on framing/context claims (definitions, dates, background) — they're cheaper to sanity-check inline.
- Produce structured report: findings, evidence, contradictions, citations.
- For very deep research, prefer the
deep-research slash command which orchestrates a multi-agent harness.
research mode (calibration variant)
When the task is a forecast and prior predictions exist:
- Extract prior predictions (match-by-match if possible).
- Score each against the actual outcome: exact / right-result-wrong-score / wrong.
- Identify systematic biases (e.g. "underestimates blowouts", "over-rates favorites").
- Re-predict future events with the bias correction explicitly applied.
Skip step 4's reasoning if the user only wants the delta. (from session feedback: "guss vs actuall -> apply on the future possible?")
Reject: SEO-spam content farms, AI-generated listicles, undated tutorials.
For version-specific questions, always verify the date — favor results from the last 12 months.
| Issue |
Solution |
| Conflicting sources |
Cite both, flag disagreement, prefer primary source |
| No relevant results |
Refine query (more specific terms, add domain filter) |
| Stale information |
Add year to query, prefer official changelogs/release notes |
| Paywall on key source |
Search for the same content on the publisher's preview, or accept the limitation and cite the abstract |
| WebFetch returns empty body or "unable to fetch" |
Fall back to the Playwright MCP plugin: browser_navigate then browser_evaluate to extract the rendered DOM. Common for FIFA.com, BBC, JS-heavy SPAs. (from session feedback: "use playwrute mcp plugine if wesearch does not work") |
|
|
1---2name: web-deep-search3description: Deep web research via WebSearch + WebFetch. Modes: search, reason, research. Use for facts or cited reports.4---56<objective>7Multi-source web research with three depth levels using Claude Code's built-in `WebSearch` and `WebFetch` tools. Use for fact-checking, technology comparisons, and current information beyond training data.8</objective>910<when_to_activate>11- Need current information beyond training data12- Technology comparison or evaluation13- Library/framework version-specific questions14- Market research or industry analysis15- Fact-checking before making architectural decisions16</when_to_activate>1718<prior_session_input>19When the user references a prior session, transcript, or "previous research," READ IT FIRST before doing fresh searches. Extract concrete artifacts (predictions, findings, decisions) and use them as inputs — do not redo the work from scratch. Path is usually under `~/.claude/projects/<project>/` as a `.jsonl` file. Check the `subagents/` subdir too. (from session feedback: "did you use the context and preview session that i gave you to compare?")20</prior_session_input>2122<modes>2324| Mode | Approach | Best For |25|------|----------|----------|26| `search` (default) | 1–2 `WebSearch` calls, summarize titles/snippets | Quick facts, current events, quick lookups |27| `reason` | 2–4 `WebSearch` calls + `WebFetch` top results, cross-reference | Comparisons, problem-solving, multi-source analysis |28| `research` | Fan-out searches (different angles) + fetch primary sources + adversarial verification | In-depth reports, market analysis, literature reviews |2930**Rule:** Default to `search`. Escalate to `reason` when sources disagree. Reserve `research` for exhaustive analysis with citations.31</modes>3233<workflow>3435### search mode361. One targeted `WebSearch` query.372. If results sufficient, synthesize answer with source URLs.383. If insufficient, run one refined query.3940### reason mode411. Run 2–4 `WebSearch` queries from different angles (technical docs, comparison articles, recent posts).422. `WebFetch` the top 2–3 most authoritative URLs.433. Cross-reference claims; flag disagreements between sources.444. Synthesize with inline citations: `[per docs.example.com]`.4546### research mode471. Decompose question into 4–6 sub-questions.482. `WebSearch` each sub-question in parallel.493. `WebFetch` primary sources (official docs, vendor announcements, peer-reviewed where applicable).504. Adversarially verify key claims (search for counter-evidence). Prioritize verify budget on **load-bearing claims** — anything that would inform code, config, or an architectural decision. In practice, 15–20% of initial claims are wrong-but-plausible (the model's prior is strong; adversarial search is what surfaces the counter-evidence). Do NOT ship any claim that would drive code changes without a passing verify. Deprioritize verify on framing/context claims (definitions, dates, background) — they're cheaper to sanity-check inline.515. Produce structured report: findings, evidence, contradictions, citations.526. For very deep research, prefer the `deep-research` slash command which orchestrates a multi-agent harness.5354### research mode (calibration variant)55When the task is a forecast and prior predictions exist:561. Extract prior predictions (match-by-match if possible).572. Score each against the actual outcome: exact / right-result-wrong-score / wrong.583. Identify systematic biases (e.g. "underestimates blowouts", "over-rates favorites").594. Re-predict future events with the bias correction explicitly applied.60Skip step 4's reasoning if the user only wants the delta. (from session feedback: "guss vs actuall -> apply on the future possible?")6162</workflow>6364<source_quality>65Prefer in this order:661. **Primary sources** — official docs, RFCs, vendor announcements, source code672. **Authoritative secondary** — well-maintained tech blogs, recognized publications683. **Aggregators** — Stack Overflow, Reddit (only when corroborated)6970Reject: SEO-spam content farms, AI-generated listicles, undated tutorials.7172For version-specific questions, always verify the date — favor results from the last 12 months.73</source_quality>7475<recency_filter>76`WebSearch` accepts no built-in recency flag, so add temporal hints to the query itself:77- `"FastAPI 2026 release notes"`78- `"Python 3.13 features site:python.org"`79- `"latest <topic> changelog 2026"`80</recency_filter>8182<error_handling>8384| Issue | Solution |85|-------|----------|86| Conflicting sources | Cite both, flag disagreement, prefer primary source |87| No relevant results | Refine query (more specific terms, add domain filter) |88| Stale information | Add year to query, prefer official changelogs/release notes |89| Paywall on key source | Search for the same content on the publisher's preview, or accept the limitation and cite the abstract |90| WebFetch returns empty body or "unable to fetch" | Fall back to the Playwright MCP plugin: `browser_navigate` then `browser_evaluate` to extract the rendered DOM. Common for FIFA.com, BBC, JS-heavy SPAs. (from session feedback: "use playwrute mcp plugine if wesearch does not work") |91</error_handling>9293<success_criteria>94- [ ] Mode matches query depth (don't fan out for a fact lookup)95- [ ] Every non-trivial claim has a source URL96- [ ] Conflicts between sources are surfaced, not hidden97- [ ] Primary sources preferred over aggregators98- [ ] No hallucinated facts — if the web didn't say it, don't claim it99</success_criteria>