Deep Research

Deep Research

Produce a defensible, cited synthesis from independent evidence. One research method; the providers and the agent topology adapt to what is actually available in the session.

Frame the Research

Write a concise brief containing:

• core problem, separate from any proposed solution;
• intended decision or deliverable;
• scope, geography, time horizon, and freshness date;
• must-prove claims and useful counterclaims;
• acceptable sources and primary-source requirements;
• time, cost, and output constraints.

Treat a proposed solution as a hypothesis unless the user explicitly makes it a constraint. Frame two to four concrete research questions around the underlying problem. State reasonable defaults instead of blocking; batch concise choice questions only when ambiguity would materially change scope, cost, or the recommendation.

Discover Live Surfaces

Discover what is enabled before planning lanes; never assume remembered tool names:

• General web: prefer parallel-cli for saved artifacts, Perplexity MCP as an independent lane, Parallel Search or Task MCP as fallback or final pass. Read providers.md before assigning providers, launching paid research, or recovering a missing backend.
• Stellar ecosystem: Stellar Raven MCP is the first discovery surface for any Stellar-ecosystem question. Read stellar-raven.md before running a Stellar lane.
• Fan-out: read the session's own tool list and skill listing for a vehicle that can run lanes in parallel. Read orchestration.md before dispatching a fan-out.

Plan Evidence Lanes

Keep narrow lookups and simple fact checks out of this skill entirely — one search surface, one citation, done.

Fan out only when the question is deep, exhaustive, comparative, or independently verified, or has at least two separable evidence lanes. Prefer two to four distinct lanes; divide by research angle first (local code, official docs, primary evidence, landscape, dependencies, user impact, counterevidence, independent synthesis) and provider second. Duplicate prompts across engines only when measuring provider agreement is itself the point.

After defining the lanes, load routing-agent-work through the current host when installed and worker selection matters. Keep provider and evidence selection here.

Choose the Vehicle

Fan-out needs four things from a vehicle: isolated worker context, a bounded lane brief, a completion signal, and a durable place for results. Any host supplying all four can run lanes in parallel. Pick the simplest one that clears the bar for the planned lane count:

• Host-native subagents — the default when the session spawns them itself.
• A terminal or worktree manager — when lanes need separate models, processes, or checkouts.
• A durable orchestrator — when lanes are long or expensive, or findings must outlive the session.
• Sequential — when nothing else is present, or the question has one lane.

Delegate worker mechanics to the vehicle's own companion skill when one is installed; otherwise drive the vehicle from its documentation. Keep provider selection, reconciliation, adversarial cross-check, and the final verdict here — never delegate the verdict.

Sequential is a complete vehicle, not a degraded mode: the same lanes, run one after another, under identical citation and verification discipline. This skill requires no particular orchestrator, and vehicle availability never changes the evidence standard.

Run the Research

1. Record the brief, research questions, lane plan, and source policy in whatever durable working state the session has (scratchpad, plan file, or the report draft itself).
2. Work each lane to a citation-ready result: findings, exact file paths or URLs, key excerpts, source dates, uncertainty, contradictions, and the provider or tool used. Preserve raw provider artifacts when available.
3. Verify consequential claims against primary sources or two genuinely independent sources. Different providers citing the same page count as one source.
4. Run targeted follow-ups only for unresolved claims, stale evidence, or disagreements — never repeat the same broad prompt.
5. If findings overturn the user's premise or expose a materially different path, pause with a short evidence summary and specific choices before committing to a recommendation.
6. Synthesize centrally. Evaluate any proposed solution explicitly and recommend a simpler alternative when it solves the underlying problem with less cost or risk.
7. Stress-test the recommendation with concrete failure modes, regressions, edge cases, user impact, and maintenance burden.

Control Cost and Failure

• Paid processors, task creation, and credit purchases are billing actions: require an explicit budget or existing runbook authority first.
• Never place API keys in prompts, notes, logs, or repository files.
• If a provider is missing, unauthenticated, rate-limited, or out of credit, record the failure and reroute the lane; do not install, authenticate, or add funds without authority.
• Prefer saved JSON or Markdown artifacts over truncated terminal output.
• Do not claim exhaustive coverage; report search boundaries and remaining uncertainty.

Complete with Evidence

Use only the sections that add value: Answer, Evidence, Sources (paths and URLs), Related, Downsides & Risks. Include key disagreements and confidence or limitations. Complete only after citations resolve and consequential claims pass verification. If implementation is next, hand the verified research context to the appropriate planning workflow instead of planning inside this skill.