---

name: oberweb description: Multi-dimensional web search orchestrator. Use when the user needs comprehensive web research that would benefit from parallel searches across different angles. Dispatches multiple fast subagents (haiku) to search in parallel, synthesizes results, and returns only relevant information with source URLs. Preserves main agent context by handling search complexity in subagents. Triggers on "research this", "find information about", "search the web for", "comprehensive search", or when a single search wouldn't capture all relevant aspects.

Skill: oberweb

Web search orchestrator that dispatches parallel subagents for multi-dimensional research while preserving main agent context.

The Iron Law

CopyGROUND IN LOCAL CONTEXT. RETURN ONLY RELEVANT RESULTS WITH SOURCE URLS.

Grounding is mandatory. Web results without local context are generic advice that may not apply.

The main agent's context is precious. Every search result returned must:

• Be grounded against local config/code
• Be directly relevant to the query
• Include the source URL for verification
• Be concise (no full page content)

---

Why oberweb?

A single web search often misses important angles:

• Different terminology for the same concept
• Multiple perspectives (docs, tutorials, discussions, issues)
• Related concepts that provide context

oberweb breaks a query into dimensions and searches them in parallel with fast, cheap subagents.

---

Required Workflow

Copy0. Ground in Local Context (check config/code FIRST)
      ↓
1. Analyze Search Request (identify dimensions)
      ↓
2. Invoke oberagent → Dispatch Orchestrator (haiku)
      ↓
3. Invoke oberagent → Dispatch Search Agents (parallel haiku)
      ↓
4. Invoke oberagent → Dispatch Synthesis Agent (haiku)
      ↓
5. Ground Results (validate against local context)
      ↓
6. Return Results (relevant info + URLs only)

Every agent dispatch goes through oberagent. oberagent invokes oberprompt, validates the prompt, and completes the checklist. This is not optional.

The chain: oberweb → oberagent → oberprompt → agent prompt

---

Step 0: Ground in Local Context

CRITICAL: Before ANY web search, check local context.

Web search results are useless if they don't apply to the user's actual setup. Check relevant local files FIRST.

What to Check

Grounding Pattern

CopyBEFORE searching, read the relevant local file(s):
- Read(~/.config/ghostty/config) for Ghostty issues
- Read(package.json) for Node.js library issues
- Read(tsconfig.json) for TypeScript issues
- etc.

Extract key facts:
- Current settings/versions
- What's already configured
- What's NOT configured (gaps)

Pass Context to Orchestrator

Include local context in the orchestrator prompt so search dimensions are grounded:

CopyLOCAL CONTEXT:
- Ghostty config shows: toggle_visibility bound to cmd+backtick
- No quick_terminal setting found
- Version: 1.0.1

USER QUERY: floating terminal creates new instance instead of reusing

Why This Matters

Skip grounding ONLY if:

• Query is purely conceptual ("what is X?")
• No local files are relevant
• User explicitly says "don't check my files"

---

Step 1: Analyze Search Request

Before searching, identify the search dimensions:

Not every query needs all dimensions. Select 2-5 based on the request.

Dimension Selection Heuristics

---

Step 2: Dispatch Orchestrator (via oberagent)

Invoke oberagent first:

CopyInvoke oberagent for oberweb orchestrator.
Skills identified: (none - pure coordination)
Objective: Plan search dimensions for multi-dimensional web search

oberagent will invoke oberprompt, then validate the prompt.

Then dispatch:

The orchestrator plans the search dimensions and dispatches search agents.

CopyTask(
  subagent_type="general-purpose",
  model="haiku",
  description="oberweb: plan search dimensions",
  prompt="OBJECTIVE: Plan a multi-dimensional web search.

  USER QUERY: [original query]

  TASK:
  1. Identify 2-5 search dimensions that would comprehensively cover this topic
  2. For each dimension, write a specific search query
  3. Return the search plan

  RETURN FORMAT:
  DIMENSIONS:
  - [dimension name]: [search query]
  - [dimension name]: [search query]
  ...

  Keep queries specific and varied to maximize coverage."
)

---

Step 3: Dispatch Search Agents (via oberagent)

Invoke oberagent for EACH search agent:

CopyInvoke oberagent for oberweb search agent.
Skills identified: (none - search/fetch only)
Objective: Search [dimension] and extract relevant information

Then dispatch all in parallel. Use haiku for speed and cost.

For each dimension from the orchestrator:

CopyTask(
  subagent_type="general-purpose",
  model="haiku",
  description="oberweb: search [dimension]",
  prompt="OBJECTIVE: Find relevant information for this search.

  SEARCH QUERY: [query from orchestrator]
  CONTEXT: Part of research on [original user query]

  TASK:
  1. Use WebSearch to find relevant results
  2. Use WebFetch on the top 2-3 most promising URLs
  3. Extract key information relevant to the query

  CONSTRAINTS:
  - MAX 2-3 sentences per URL
  - NO full page content or long quotes
  - NO more than 5 URLs total

  RETURN FORMAT:
  RESULTS:
  - [URL]: [2-3 sentence summary of relevant content]
  - [URL]: [2-3 sentence summary of relevant content]

  ONLY include results that are directly relevant. Skip generic or tangential content."
)

Dispatch Pattern:

Copy// Single message with multiple Task calls
Task(haiku, "search dimension 1", ...)
Task(haiku, "search dimension 2", ...)
Task(haiku, "search dimension 3", ...)

---

Step 4: Dispatch Synthesis Agent (via oberagent)

Invoke oberagent:

CopyInvoke oberagent for oberweb synthesis agent.
Skills identified: (none - filtering/organizing only)
Objective: Synthesize search results into concise summary with source URLs

After all search agents return, synthesize the results:

CopyTask(
  subagent_type="general-purpose",
  model="haiku",
  description="oberweb: synthesize results",
  prompt="OBJECTIVE: Synthesize search results into a coherent summary.

  ORIGINAL QUERY: [user's original query]

  SEARCH RESULTS:
  [aggregated results from all search agents]

  TASK:
  1. Remove duplicates and low-relevance results
  2. Organize by theme or importance
  3. Create a summary that answers the original query
  4. Preserve all source URLs

  RETURN FORMAT:
  SUMMARY:
  [2-4 paragraph synthesis answering the query]

  KEY FINDINGS:
  - [finding 1]
  - [finding 2]
  ...

  SOURCES:
  - [URL 1]: [what it covers]
  - [URL 2]: [what it covers]
  ..."
)

---

Handling Failures

Don't fail silently. If searches return nothing useful, tell the main agent what was attempted.

---

Step 5: Ground Results

After synthesis, validate results against local context.

Validation Checklist

Grounding Output

Add a GROUNDING section to the synthesis:

CopyGROUNDING (based on your config):
- Your config uses toggle_visibility, not toggle_quick_terminal
- This is likely the root cause of new window spawning
- Recommendation: Replace toggle_visibility with toggle_quick_terminal

CONFLICTS:
- None found

VERIFIED:
- Version 1.0.1 matches recommended version

When Results Don't Apply

If web results don't match local context:

CopyWARNING: Web results may not apply to your setup.
- Web assumes: toggle_quick_terminal
- Your config: toggle_visibility (different keybind)
- Action needed: [specific change]

Never return generic advice when you have specific local context.

---

Step 6: Return Results

Return the synthesis to the main agent. The main agent receives:

• A concise summary answering their query
• Key findings as bullet points
• Source URLs for verification or deeper reading

Do NOT return:

• Full page contents
• Raw search results
• Duplicate information
• Tangential findings

---

Model Selection

Why haiku throughout:

• Web search is I/O bound, not reasoning bound
• Parallel execution benefits from fast response
• Cost scales with number of dimensions
• Results are validated by source URLs, not model reasoning

---

Context Budget

Compare to naive approach: 5 WebFetch calls = 5000+ tokens of raw content.

---

Example Execution

User query: "How do I implement authentication in Next.js 14 App Router?"

Orchestrator Output:

CopyDIMENSIONS:
- official: "Next.js 14 App Router authentication docs"
- tutorial: "Next.js 14 authentication tutorial NextAuth"
- patterns: "Next.js App Router auth middleware patterns"
- issues: "Next.js 14 authentication common issues site:github.com"

Search Agents (parallel):

Each returns 2-3 relevant URLs with summaries.

Synthesis Output:

CopySUMMARY:
Next.js 14 App Router authentication is typically implemented using NextAuth.js
(now Auth.js) with the new App Router patterns. The key changes from Pages Router
include using route handlers in app/api/auth/[...nextauth]/route.ts and middleware
for protecting routes...

KEY FINDINGS:
- NextAuth.js v5 (Auth.js) has native App Router support
- Middleware-based protection is recommended over page-level checks
- Server Components can access session via auth() helper
- Client Components use useSession() hook

SOURCES:
- https://nextjs.org/docs/app/building-your-application/authentication: Official docs
- https://authjs.dev/getting-started/introduction: Auth.js setup guide
- https://github.com/nextauthjs/next-auth/issues/...: Known migration issues

---

Red Flags - STOP

---

Integration

With oberagent

Invoke oberagent before EVERY dispatch:

• Once for orchestrator
• Once for each search agent (can be same prompt template)
• Once for synthesis agent

oberagent invokes oberprompt in Step 1, then validates the prompt.

With oberprompt

Invoked transitively through oberagent. Each dispatch benefits from:

• Constraint budget validation
• Outcome-focused prompt structure
• Checklist completion

With main agent

oberweb returns a context-efficient summary. Main agent can use source URLs to dive deeper if needed.