Search Auto-Routing Plan

Search Auto-Routing Plan

Purpose

Produce a search routing plan before invoking multi-provider skills (web-search-plus, custom routers, or chained search tools). Routers execute automatically but rarely explain why a provider was chosen — this skill makes routing explicit, auditable, and tunable.

This skill does not call search APIs, store API keys, or fetch live results.

When to use

Use when the user mentions:

• Auto-routing across Serper, Tavily, Exa, Brave, Firecrawl, Perplexity, etc.
• Which search provider fits a query
• Web Search Plus or unified search skills
• Reducing search cost or improving result quality via smarter routing
• Fallback chains when the first provider returns thin results

Not for: routing LLM prompts between local/cloud models (see task-complexity skills).

Safety and boundaries

Do not request or echo API keys for any search provider.

Do not claim live search results — planning only.

Do not recommend circumventing robots.txt, paywalls, or provider ToS.

Privacy: If the query contains PII, recommend providers/modes that minimize logging and note user consent.

Required inputs

1. Search goal — what answer or artifact is needed.
2. Query or task description — the actual text to search for (or “generate from goal”).
3. Constraints — freshness, geography, max latency, budget sensitivity, offline/air-gapped.
4. Available providers (optional) — which keys/skills the user actually has; default to common stack: Serper, Tavily, Exa, Brave, Firecrawl.
5. Output need — snippets, full page text, structured JSON, citations only.

Signal scoring

Score each dimension 0–2 (0=low, 1=medium, 2=high):

Provider fit (default rubric)

Tie-breakers: cost ↑ with depth; latency ↑ with crawl/extract.

Workflow

1. Restate goal and score the five signals.
2. Rank providers 1–3 with short rationale.
3. Output plan (format below) including fallback chain (if #1 thin → try #2).
4. Suggest query tweaks per primary provider (keyword vs neural phrasing).

Output format

Search routing plan — {short goal}

Primary route

Fallback chain

1. If <condition> then <provider + query adjustment>
2. …

Executor hints

Optional YAML for downstream skills:

primary: serper|tavily|exa|brave|firecrawl
fallback: []
maxResults: 5-10
extractContent: true|false
freshness: null|ISO range

Post-route quality checks

• Top results match entity type and freshness
• Snippets are answer-bearing (not directory pages)
• Cost/latency within stated constraints
• Fallback triggered if <3 usable sources

Quality bar

• Every pick cites signals — no “use Tavily because it’s good.”
• Fallbacks are conditional — not a generic provider list.
• Queries differ by provider — Serper keywords ≠ Exa sentences.
• Respects available providers — don’t recommend Firecrawl if user only has Serper.

Examples

Good rationale: “Freshness=2 + Depth=2 → Tavily primary for synthesized recent coverage; Serper fallback for exact product name confirmation.”

Bad rationale: “Use Exa for better results.”

Good fallback: “If Exa returns <3 corporate homepages, retry Serper with site:linkedin.com/company {name}.”