search-boost-parallel-research

Parallel research

Antigravity: use MCP server search-boost from global or workspace mcp_config.json, rather than search_web/read_url_content for these workflows. Use authorized cloud tools, not web search, for live account state.

This is a workflow, not an additional MCP tool or an installed subagent definition. The parent owns the research plan and final acceptance, and runs it using the chosen host runner's existing capabilities and permissions. A workflow load does not authorize delegation; no Pi installation or CLI is needed.

Host execution

Capability-gated Antigravity workflow: the presence of an Agent Manager UI does not establish that this conversation has a callable subagent API. Inspect actual registered tools and use only a native, authorized delegation mechanism with retrievable child results. Do not invent a spawn tool or assume UI-level agents can be controlled from a skill.

Children must have access to the active global/workspace search-boost MCP connection, not merely the parent's visible tool list. Pass actual tool names and the shared role instructions explicitly, keep returned IDs, and use available wait/stop controls. No shell-spawned Pi runtime or permission changes. If native delegation or child MCP access is absent, use the shared workflow's disclosed serial path; keep synthesis in the parent.

Shared workflow

Use direct search for one lookup. Use this workflow only for independent research angles and only when delegation is authorized by the current request or applicable instructions and permitted by host policy. Loading this text is not authorization to spawn agents, enable features, or change permissions.

1. Define the question, scope, relevant version/date, sufficient evidence, and budget. Before splitting, check: independent questions, integrable reports, and verifiable acceptance. Keep shared reasoning and final synthesis in the parent; usually 2–4 searchers suffice, within the selected runner's limits. Keep research read-only.
2. Give each searcher the question context, one bounded task, the shared searcher instructions (injected by the native runner, or copied below from the skill), the actual search/read tool names, required report format, and a stopping condition. Do not assume a child sees this skill or the parent's tools/context.
3. Start one wave through the chosen host runner, following its own launch/lifecycle contract; preserve run IDs and track completion, failure, timeout, and cancellation separately. Wait through the host's supported notification/wait mechanism, not repeated polling. Cancel remaining children on user cancellation and release owned child resources when supported.
4. Fast mode: one wave, then the parent synthesizes and stops. Complex mode: pass all reports and their statuses to a no-search summarizer (or do that reasoning in the parent). Default 1–2 waves, at most 3. Launch only material new gap tasks, within the original budget; stop earlier when evidence is sufficient.
5. The parent checks important claims against supplied evidence, resolves conflicting versions/dates, and produces the final cited answer. A URL list or domain count is not proof of corroboration. Keep single-source claims and remaining uncertainty explicit. Disclose failed tasks, partial/truncated reports, and any serial fallback.