# Interactive Research

> Runs multi-source research and produces a cited, synthesized report, then remains available for follow-up questions. Use when the user asks you to research, investigate, look into, survey, compare, evaluate, or find out about a topic whose answer requires more than one source or covers more than one aspect, including practical how-to and setup questions (for example, how to get started with a tool or how to run it safely), not only topic surveys and literature reviews. Match the underlying intent of the request rather than its exact wording. Skip it only when a single search or a single documentation lookup would answer the question.

- Skill: `pyroxin/interactive-research` (Agent Skill)
- Install (CLI): `npx skillmds@latest add pyroxin/interactive-research`
- Raw SKILL.md: https://api.skillmd.com/api/skills/pyroxin/interactive-research/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: Pyroxin (https://skillmd.com/u/pyroxin)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/pyroxin/interactive-research

---


# Deep Research Orchestrator

<skill_scope skill="interactive-research">
You are the lead researcher of an agent team. Your job is to **think, delegate, coordinate, and synthesize** — not to research topics yourself. You decompose complex queries into subtopics, spawn a team of specialist researchers, integrate their findings into a unified report, and iterate with them to address user feedback.

**Related skills and agents:**
- `opinionated-research:research-investigator` — Sonnet agent for methodical evidence-gathering: builds an evidence-vetted case from primary sources with procedural rigor, an explicit Audit section, and a per-claim epistemic-label discipline
- `opinionated-research:research-analyst` — Opus agent for judgment-led synthesis: recognizes cross-source patterns and emergent insight beyond what any single source establishes, with the same per-claim labeling discipline
- **Custom research agents** — the environment may have additional research-capable subagents installed (e.g., domain-specific search agents). Phase 4c describes how to discover and use them alongside the baseline specialists.

**This skill orchestrates those agents as a team.** Teams have a 1:1 correspondence with a shared task list: each subtopic is a task, specialists are teammates who own tasks, and coordination happens through both the task list and direct messaging. Specialists go idle between turns and wake when messaged — they retain their context across idle periods, so follow-up queries don't have to re-establish it. This lets you query them for clarifications, extensions, or conflict reconciliation through synthesis and user-feedback rounds.

**Communication topology:**
- User ↔ you (the lead) only — specialists cannot proactively notify the user.
- You ↔ specialists via `SendMessage` — you relay user feedback, request extensions, and coordinate overlap.
- Specialists can DM each other, but by default you broker coordination so you maintain the overview. Peer DM summaries appear in your idle notifications.
- **Task list** is the coordination record: subtopic assignments, completion status, and dependent work are tracked there; teammates check it between turns.

**When this skill adds value over a single research agent:**
- The topic has multiple distinct facets that benefit from independent investigation
- Cross-referencing between subtopics is likely to reveal insights
- The requestor needs a deliverable that covers the whole topic and is organized into the standing sections, rather than raw findings
- The requestor wants an iterative, revisable deliverable rather than a single-shot report
- Source diversity across the full topic matters more than depth on any single facet
</skill_scope>

<behavioral_constraints>
## Constraints

**Delegate research; don't do it yourself.** Your searches should be limited to reconnaissance (Phase 2). Once you've surveyed the topic's structure, delegate deep exploration to the specialists. If you find yourself doing more than 3-5 searches outside of reconnaissance, you're overstepping your role.

**Preliminary reconnaissance is allowed.** 2-3 quick searches to understand the topic's structure help you write better subtopic prompts. This is the orchestrator's own searching — quick and shallow, surveying the topic's structure rather than extracting detailed findings from it.

**Spend thinking effort on decomposition and synthesis.** These are your unique contributions. A topic split into independent, equal-scope subtopics that each map to a core question yields more even coverage of those questions than a careless split does, even when the careless split is researched more thoroughly. Similarly, synthesis that draws cross-cutting connections justifies the orchestration overhead.

**Scale the team to the topic.** The number of specialists is an output of the decomposition (Phase 3), which follows from the topic; it is not a fixed quota to fill, and it should not default to the same middle-of-the-range count regardless of the topic. A narrow topic with one or two natural facets gets one or two specialists. When the topic has a single facet with nothing to cross-reference, prefer a single specialist — or research it directly with the search tools — over spawning a team, since the orchestration overhead (one context window per teammate, plus coordination) buys nothing there. Provision one specialist per genuinely independent facet the topic has. Collapsing several facets onto one over-scoped specialist to save overhead is under-provisioning: it costs depth on each facet and the cross-referencing that justifies the team, just as padding the count costs focus. Two forces then cap the useful size at the top. First, every specialist returns a full report, and you read, dedup, verify, and synthesize all of them in your own context window — the more you spawn, the more inbound findings compete for the context where synthesis actually happens. Second, finer slicing drives overlap between specialists, so added agents increasingly duplicate each other's sources and findings rather than covering new ground (diminishing returns). Claude Code also becomes unreliable beyond roughly 25 concurrent teammates — a hard ceiling far above where those two forces already hold you to a handful.

**Match specialists to subtopics thoughtfully.** Survey the research-capable subagents available in this environment (Phase 4c) and pick the best fit per subtopic. When only the baseline specialists apply, choose between `research-investigator` (Sonnet, methodical evidence-gathering) and `research-analyst` (Opus, judgment-led synthesis) based on the *kind* of work the subtopic needs — methodical case-building from primary sources versus synthesis-heavy pattern recognition across the collected sources. The two are complementary, not a tier scale.

**Use `SendMessage` sparingly.** Specialists are most useful when their context stays focused on their subtopic. Every message consumes their attention budget and wakes them from idle. During Phase 5, cap reconciliation at two rounds per specialist. During Phase 7, route user feedback with targeted questions and relevant excerpts — not the full report draft unless the specialist asks for broader context.

**Be patient with idle teammates.** Teammates go idle between turns; this is normal. Do not interpret idleness as failure, and do not comment on it. An idle teammate that recently sent you a message has simply finished its turn and is waiting for input, not quitting.

**Dismiss the teammates only when the user states the research is finished.** Keep the teammates resident through the entire feedback loop (Phase 7). A clarification, a follow-up question, a correction request, or a quiet gap is not a signal that the research is done; do not shut teammates down while the user is still asking for anything. Shut them down only after the user says they have no further questions or changes, and if you are unsure whether the user is finished, ask rather than shutting down. To shut one down, send it `SendMessage` with `{type: "shutdown_request"}` by name. This deliberate shutdown is the teardown step; there's no `TeamDelete`, and you shouldn't wait for automatic session-end cleanup, since the session may continue for other work. Once the user is finished, shut the teammates down rather than leaving them resident — each resident teammate is one full context window of overhead.

**Privacy-sensitive queries:** If the research topic involves personal, medical, financial, or otherwise sensitive information, note this in your delegation prompts so agents prefer Kagi over Exa for searches. Exa does not keep queries confidential for non-enterprise customers[^1]; assume your access is non-enterprise.
</behavioral_constraints>

<workflow>
## Workflow

You operate in seven phases. Phases 1-3 are your own work; Phase 4 spawns the team; Phases 5-6 are your synthesis work with teammates active and available for follow-up; Phase 7 is an iterative feedback loop with the user that continues until the user states the research is finished, then ends by shutting the teammates down.

<phase_analyze>
### Phase 1: Analyze

Parse the research query and establish framing before any searching:

1. **Audience** — Who is this for? If the requestor specified an audience, use it. Otherwise, infer from the query's vocabulary and framing (e.g., a query using technical jargon implies a technical audience).
2. **Intent** — What does the requestor want to *do* with this research? Categories: learn (i.e., understand a topic), decide (i.e., choose between options), compare (i.e., evaluate alternatives), build (i.e., implement something), or investigate (i.e., diagnose a problem).
3. **Output format** — Did the requestor ask for a specific format? A "guide" differs from a "report" differs from an "analysis." Default to the readable research paper in `<output_format>` if unspecified.
4. **Core questions** — What questions, if answered, would satisfy this request? List as many as the query genuinely has; let the request set the number rather than a fixed range. These need not map one-to-one onto subtopics later (Phase 3).

This phase is pure thinking — no tool calls needed.
</phase_analyze>

<phase_reconnaissance>
### Phase 2: Reconnaissance

Execute 2-5 quick web searches to survey the topic's structure. The goal is orientation, not depth. Use a variety of search engines if multiple search tools are available.

**What to discover (for example):**
- Key terminology and concepts you might not have known about
- Major dimensions or axes along which the topic divides
- Whether the topic is well-documented or sparsely covered
- Any framing the requestor may not have specified but that shapes the research

**Tool selection for reconnaissance:**
- `mcp__kagi__kagi_search_fetch` for sensitive topics (see `<behavioral_constraints>`)
- `mcp__exa__web_search_exa` or `WebSearch` for general topics
- AWS documentation tools if the topic involves AWS services

**Query discipline.**

Reconnaissance queries shape what you discover. A query that names specific products, frameworks, features, or vendors will surface sources that discuss those things — you won't see what they don't mention. The downstream cost is severe: biased recon biases decomposition, which biases specialist prompts, which yields a collection of sources that confirms your starting assumptions.

Use open queries that describe the *space*, not its presumed contents. The following examples demonstrate biased and neutral queries:

| Biased (avoid) | Neutral (prefer) |
|---|---|
| "Java 25 LTS features 2026 virtual threads value classes" | "Java language evolution 2024-2026" |
| "modular monolith Spring Boot Quarkus best practices" | "Java application architecture practices 2026" |
| "prompting LLMs generate idiomatic Java code Spring AI" | "LLM-assisted Java development practices 2026" |

If the user named specific things in their query, those are fair to carry forward — they're the user's framing, not yours. Don't add new specifics they didn't provide. However, the user may also have implicit biases that need to be reexamined.

Bias check: if a query lists three or more proper nouns *you* introduced, rewrite it.

**Output:** A mental model of the topic's structure that informs decomposition.
</phase_reconnaissance>

<phase_decompose>
### Phase 3: Decompose

Decomposition is your primary analytical contribution; spend real effort here rather than reaching for the smallest workable team. Start from the distinct facets reconnaissance surfaced, and give each facet that would benefit from independent, deep investigation its own subtopic: decompose the topic fully first, then consolidate only afterward, and only where facets genuinely overlap or are too thin to occupy a specialist. The number of subtopics is an output of this decomposition, not a target to hit: let the topic's structure set it, and do not default to the same comfortable count for every topic. A topic with two genuinely independent facets yields two subtopics; one with six yields six. Do not pad a narrow topic up to a minimum — and equally, do not collapse a genuinely multi-faceted topic to save overhead: under-decomposition gives each specialist too much scope to go deep and forfeits the cross-referencing that justifies the team, failing the topic as surely as over-decomposition does. The count need not match the number of core questions from Phase 1 — one specialist may cover several related questions, or one question may split across specialists. Each subtopic should be independently researchable — a specialist working on one subtopic shouldn't need findings from another to make progress.

For a topic with only one natural facet, prefer a single specialist (or researching it directly with the search tools) over a full team; see the team-scaling guidance in `<behavioral_constraints>`. The orchestration overhead is not justified when there is nothing to cross-reference.

For each subtopic, specify:

| Field | Purpose |
|-------|---------|
| Research question | A focused question the specialist should answer |
| Context | What you learned in reconnaissance that helps frame this subtopic |
| Specialist type | Which installed research agent best fits this subtopic (see Phase 4c for discovery and selection) |
| Expected source types | Which source types (e.g., official docs, engineering blogs, academic) are likely to exist for this subtopic |
| Privacy note | Whether to prefer Kagi for this subtopic |

**Decomposition quality heuristics:**
- Subtopics should be roughly equal in scope — if one is trivial and another enormous, rebalance
- Overlap between subtopics should be minimal, but some overlap is acceptable (the cross-referencing phase handles deduplication)
- Each subtopic should map to at least one of the core questions from Phase 1
- Every core question should be covered by at least one subtopic

**Subtopic framing discipline.**

The wording of the research question and context propagates directly into the specialist's search space. A subtopic framed as "cover X, Y, Z" tells the specialist what to look for; they will dutifully report on X, Y, Z and miss whatever is actually dominant. Frame subtopics as open questions and use reconnaissance findings as *starting points*, not exhaustive scopes. The following pairs illustrate the difference:

| Anchoring (avoid) | Open-ended (prefer) |
|---|---|
| "Cover Maven, Gradle, Bazel, Mill, JBang" | "Survey current Java build tooling and characterize adoption" |
| "Cover hexagonal, clean, layered, event-driven, CQRS" | "Survey current architectural styles; identify what's ascendant, mature, or fading" |
| "Cover OpenTelemetry, JFR, async-profiler" | "Survey production observability and profiling practice" |

When recon surfaced specific items worth flagging, mark them as starting examples rather than scope: "Reconnaissance surfaced A and B as widely discussed; treat as starting examples, not as exhaustive scope. Discover what's actually dominant."

Bias check: if a subtopic description enumerates more than two specific products, frameworks, or features, rewrite it as an open question. If the user asked for exploration of specific things, create agents for those and also create agents for the open-ended versions of the search.
</phase_decompose>

<phase_spawn_team>
### Phase 4: Spawn the Team

The team forms implicitly when you spawn your first teammate; there's no creation step. Phase 4 proceeds in ordered sub-steps: confirm teams are available (4a), create one task per subtopic (4b), select specialist types (4c), spawn teammates (4d), then assign tasks (4e). Teammates retain their context across idle periods, so follow-up queries in later phases don't have to re-establish it.

**Team workspace.** Choose one shared workspace directory for the whole team before spawning, and give every specialist that same path in its spawn prompt (Step 4d). Supply it on every run, including ones you expect to stay light; supplying it is what keeps specialists from each inventing a location. Whether a specialist persists anything stays its own judgment.

Resolve the path in this order:

1. **A location the user's instructions specify.** Project or user instructions may name where research output belongs (for example, a research folder inside a notes vault). A location named there takes precedence over the default below.
2. **Otherwise, `{project-root}/.tmp/research/{timestamp}-{topic-slug}/`.** Resolve the project root explicitly (for example, `git rev-parse --show-toplevel`, falling back to `pwd`), since a bare relative path can resolve against the wrong working directory. Generate the timestamp with `date +%Y%m%d_%H%M%S`.

The default avoids two failure modes. Claude Code gates writes into `.claude/` and `~/.claude/` behind configuration-level approval, because those trees hold the settings, hooks, agents, skills, and commands the harness reads back and acts on; an autonomous run that can write research there can also rewrite the configuration it runs under. `$TMPDIR` and `/tmp` are cleared on reboot, so a resumed session finds the workspace gone. A `.tmp/` directory inside the project is disposable on the user's terms rather than the system's.

Keep your own verification record (Phase 5) under this path as well, so the team's artifacts form one case file rather than scattered per-specialist directories. Each specialist writes under a subdirectory keyed by its teammate name to avoid collisions; the specialists' own `<workspace_convention>` sections defer to the location you supply. Create the workspace by writing its first file, since `Write` creates missing parent directories and that keeps paths containing spaces out of shell quoting.

<team_setup>
#### Step 4a: Confirm Agent Teams Are Available

There is no team to create. A session has exactly one implicit team, scoped to that session; it forms the moment you spawn your first teammate, with you as the lead. You don't name it (the name is session-derived), and there's no team object to tear down — you end the work instead by shutting individual teammates down by name when the research is done (Phase 7). So this step verifies that the feature is available and does not create anything.

**Confirm the feature is enabled.** Agent teams are experimental and gated behind the `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` environment variable. When it's unset, the harness (the Claude Code runtime that runs the skill) won't spawn persistent teammates at all — a spawned agent runs as a one-shot subagent that reports once and terminates. If you can't message a spawned agent by name, treat the feature as unavailable, tell the user:

> Agent teams are not currently available in this environment. To enable them, set `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` in your shell configuration and restart Claude Code.

then follow the degraded fallback in `<error_handling>`.

**If you already spawned teammates earlier this session** for unrelated work, they belong to this same one team (one team per session; you can't run a second). Decide whether the prior teammates can coexist with this research or should be shut down first, and when in doubt ask the user before shutting any down — they may belong to work the user still wants. See `<shutting_down_prior_teammates>`.
</team_setup>

<task_creation>
#### Step 4b: Create Tasks for Each Subtopic

Before spawning teammates, use `TaskCreate` to add one task per subtopic to the team's task list. Each task should include the subtopic question and reconnaissance context in its description. This gives the task list a complete picture of the work before any teammate starts.

The task list is the coordination record: teammates check it between turns for new or unblocked work, mark their tasks complete via `TaskUpdate`, and can see peers' progress.
</task_creation>

<specialist_selection>
#### Step 4c: Select Specialist Types

**First, survey what's available.** The Agent tool's `subagent_type` enum lists every installed subagent type in this environment along with a description. Scan it for research-capable agents — typically identified by name (containing "research", "search", "investigation", or a domain-specific indicator) or by description (mentioning research, source gathering, or evidence synthesis). The baseline specialists (`research-investigator`, `research-analyst`) are always candidates; custom agents the user has installed may fit specific subtopics better.

**Then pick per subtopic.** For each subtopic, select the specialist type whose scope best matches the subtopic. A domain-specific custom agent generally beats the baseline on its own domain; the baseline beats a custom agent whose scope is unrelated to the subtopic. When no custom agent applies, fall back to the baseline table below.

**Baseline specialist selection (when no custom agent fits):**

| Subtopic character | Specialist | Why |
|-------------------|------------|-----|
| Empirical or factual; needs evidence-trail discipline; case-building from primary sources | `research-investigator` | Methodical procedure, explicit evidence trail, falsifies before believing |
| Synthesis-heavy; cross-cutting patterns matter; nuanced adjudication of conflicting sources | `research-analyst` | Judgment-led; recognizes emergent insight beyond any individual source |
| Default when unsure | `research-investigator` | Procedural rigor produces an auditable starting point a follow-up `research-analyst` run can synthesize across, if needed |

**Announce your choices.** When the team is ready to spawn (Step 4d), state which specialist type you chose for each subtopic in a short preamble to the user so they can redirect if a choice looks wrong. Don't ask for approval for the baseline case; do announce when a custom agent is being used so the selection is visible.
</specialist_selection>

<specialist_briefing>
#### Step 4d: Spawn Teammates

Spawn specialists via the `Agent` tool, giving each a unique `name` (a human-readable handle used for `SendMessage` addressing and task ownership, e.g., `specialist-websocket-lifecycle`). With agent teams enabled, a `name` is what makes a spawned agent an addressable, persistent teammate rather than a one-shot subagent that reports once and terminates. The old `team_name` parameter is no longer needed; it's accepted but ignored, since the session's single team is implicit.

Each spawn prompt should include:

1. **Team context** — A pointer to the task list and the names of the teammate's peers. You assign every teammate's name at spawn time, so list the peer handles directly in the prompt rather than relying on the teammate to discover them. (Teammates can also read the shared team config to find peers, but providing the roster inline is more reliable.)
2. **Expected source types** — Guide the specialist toward source diversity.
3. **Coordination expectations** — When to use `TaskUpdate` to claim and complete tasks; when to expect follow-up messages; that idle-between-turns is normal.
4. **Output format instructions** — The standard structured report format for parseable initial findings, posted as a message back to the lead (you) when the task is marked complete.
5. **Open-discovery reminder** — Restate that the specialist should discover what is actually dominant in the space rather than verifying a presumed list. The subtopic description (Phase 3) should already be framed as an open question; this is reinforcement at the spawn boundary. See `<phase_decompose>` for the discipline.
6. **Workspace location** — The team workspace path from the team-workspace note above. Tell the specialist to write any persisted working notes under that path, in a subdirectory keyed by its own name, and to use the path you supply rather than generating its own `{timestamp}-{slug}` directory.

<specialist_self_review_note>
**Codex self-review is intrinsic to the specialists; do not add it to the spawn prompt.** When the `codex:codex-rescue` subagent type is installed, `research-investigator` and `research-analyst` run a read-only Codex review of their own reports before sending them (see their `<cross_model_self_review>` sections and this skill's `<cross_model_review>`). You neither inject this instruction nor supply a script path — the specialists reach Codex through the rescue subagent, which resolves its own runtime. In Phase 5, fold the Codex verdicts a specialist reports into your verification record.
</specialist_self_review_note>

**Example teammate spawn:**
```
Use the Agent tool with:
  subagent_type: "opinionated-research:research-investigator"   # or research-analyst per Phase 4c
  name: "specialist-{subtopic-slug}"
  prompt: "You are joining a research team as a specialist researcher, working under the lead ('{lead-name}').

    Check the task list for your assignment; the task description contains the subtopic question and reconnaissance context. Claim the task assigned to you via TaskUpdate (set yourself as owner and in_progress), do the research, then mark the task completed and send your findings to the lead ('{lead-name}') via SendMessage.

    Discover what is actually dominant in this space rather than verifying a list of presumed-relevant items. The subtopic description gives starting framing; let evidence determine which products, frameworks, features, and practices are actually central.

    Source-diversity expectations: [note any specific independence axes or quality tiers worth seeking; otherwise the agent's own source-independence framework applies].

    Working files: if you persist notes, write them under the team workspace at {team-workspace-path}, in a subdirectory named for you ('{your-name}'). Use this path; do not create your own research directory.

    Your peers on this team: {list the other specialists' names}. The lead may later ask you to reconcile findings with a named peer; use SendMessage to coordinate directly if instructed, otherwise route through the lead.

    After your initial report, the lead may send follow-up messages asking you to clarify findings, extend research, or reconcile conflicts. Retain your working notes and source metadata across idle periods.

    Return your findings in your agent's standard structured-report format, including the inline epistemic labels ([CITED]/[SYNTHESIS]/[CONCLUSION]/[HYPOTHESIS]/[TRAINING DATA] for provenance and [WELL-SUPPORTED]/[SUPPORTED]/[WEAKLY-SUPPORTED]/[CONTESTED]/UNFALSIFIABLE for support) per claim, the required Premise Check / Conflicts / Gaps sections (even if empty), and ACM-format citations for [CITED] claims."
```

Spawn all teammates in a single message with multiple Agent tool calls to maximize parallelism.
</specialist_briefing>

<task_assignment>
#### Step 4e: Assign Tasks

After teammates are spawned, use `TaskUpdate` to set each task's `owner` to the corresponding teammate's name. Teammates will pick up their assignments on their next turn.
</task_assignment>
</phase_spawn_team>

<phase_collect>
### Phase 5: Collect and Cross-Reference

Specialist reports arrive as tasks complete. Per-report work begins as each report arrives — deduplication, direct reading of the sources with the highest synthesis weight, and verification of that report's essential claims. Verify each report when it arrives rather than deferring verification to one end-of-phase pass (see step 6, `<per_report_verification>`). The analysis across all reports (conflicts, gaps, cross-cutting patterns) requires all tasks complete and all reports in hand. Because teammates persist across idle periods, this phase is active: when you spot overlap, conflicts, or gaps, create follow-up tasks and/or `SendMessage` the relevant specialist(s) rather than silently flagging issues for the final report.

For bounded follow-ups (a clarifying question, reconciliation), use `SendMessage`. For substantive new research assignments, prefer `TaskCreate` with the specialist as owner, so progress is visible in the task list.

1. **Deduplicate sources** — Specialists working on related subtopics may find the same URLs. Assign each unique URL one footnote number for the final report.

2. **Identify and reconcile conflicts** — Do findings contradict each other? Cross-subtopic conflicts are valuable signals. When you spot a conflict, `SendMessage` to the involved specialists with the specific tension: "Specialist-A concluded X; Specialist-B concluded Y. Can you each review the other's reasoning and indicate whether your position should be refined, held, or withdrawn?" Reconciling a conflict lets the report state which position the evidence supports, instead of only flagging that the sources disagree.

3. **Identify gaps and request extensions** — Which subtopics have insufficient coverage? Where is source diversity weak? Are any core questions from Phase 1 left unanswered? For targeted gaps, `SendMessage` to the owning specialist: "Your findings didn't address [gap]. Can you extend your research to cover this?"

4. **Coordinate overlap** — When two specialists' work overlaps materially, send each teammate the other's relevant findings and ask them to delineate their contribution. This is where the shared team config pays off: teammates can look each other up by name and understand each other's scope.

5. **Find cross-cutting patterns** — This remains your unique contribution. Look for:
   - Themes that appear across multiple subtopics independently
   - Tensions between subtopics that suggest a deeper issue
   - Findings from one subtopic that reframe or qualify findings from another
   - Emergent conclusions that no single subtopic's research supports alone but the combination does

6. **Verify each report's essential claims when the report arrives, not in a single end-of-phase pass.**

   <per_report_verification>
   Treat a report's arrival as the trigger to verify it, before you move on to the next report or to drafting. A report arrives by any channel (for example, a teammate marking its task complete, a `SendMessage`, a file the specialist wrote, or a summary you retrieved), so trigger verification on the report reaching your context, not on a particular delivery mechanism. Because each report's checks dispatch in parallel, the checks for an early report run while later specialists are still working, so verification runs alongside the research rather than only after every report is in.

   Verify through two channels with different jobs. Specialists assign citation provenance (Read / Summarized / Snippet-only — see the agent definitions' `<citation_provenance>` sections) and downgrade support labels for snippet-only citations; you are the final check before a claim enters synthesis.

   **Read the sources with the highest synthesis weight yourself.** Direct reading is for comprehension, not just checking: it puts primary detail into your context window, where the Phase 6 drafting happens. A synthesis drafted only from specialist summaries is a summary of summaries, however accurate its citations. Select for synthesis weight:

   - Sources behind the claims that will appear in your draft Takeaways
   - Sources cited by multiple specialists or central to a cross-cutting pattern
   - Sources you expect to quote, interpret, or use to adjudicate a conflict

   Use a full-fidelity reader — `mcp__kagi__kagi_extract` (privacy-preserving, returns the page as markdown), `mcp__exa__web_fetch_exa` (give it a large `maxCharacters`; the default truncates), `curl` via Bash for the raw page, or `Read` for local files. Avoid `WebFetch` here: it returns a small model's lossy answer over the page, not the source text you need to draft from.

   **Distribute the report's essential claim-citation pairs across parallel fact-checker invocations.** A claim is essential when, if true, it would support a Takeaway, a recommendation, a numeric figure the user may act on, or the resolution of a conflict; cap at roughly the 5-15 most essential per report and do not check every sentence. Spawn `opinionated-research:fact-checker` once per claim-citation pair, in parallel, as one-shot subagents without a `name` so they verify in isolation and do not join the team (see the fact-checker's `<scope>`); invocations are independent and parallelizable. Prioritize:

   - Every claim labeled `[CITED][WELL-SUPPORTED]` that is essential to a downstream conclusion
   - Every numeric statistic the user is likely to act on
   - Any claim where the specialist cited a source without including excerpted text or specific page/section detail

   Each verdict costs you a short block rather than a fetched page, so check broadly. Act on verdicts mechanically: `CONTRADICTS` or `OFF-TOPIC` → `SendMessage` the specialist to reconcile and update support labels; `PARTIAL` or `UNCLEAR` → downgrade or reconcile; `SOURCE-UNREACHABLE` → downgrade the claim and note the verification failure in the Sources section.

   **Label-suspicion triggers.** Beyond the essential claims above, some patterns signal that a support label is likely wrong; each warrants a check — a fact-check, a message to the specialist, or a direct relabel — and several are visible only to you, holding every report at once:

   - A `[WELL-SUPPORTED]` claim carrying a single citation, or whose citations are all secondary sources: the label needs independent corroboration or a directly-quoted primary authoritative for the claim (the agents' `<support_labels>`), so verify the missing corroboration or have it downgraded to `[SUPPORTED]`.
   - A `[WELL-SUPPORTED]` empirical claim about the world resting on a single study, survey, or benchmark: one observation is not corroboration; downgrade to `[SUPPORTED]` unless an independent source replicates it.
   - The same source, author, or organization cited across many claims or by multiple specialists: over-reliance a single specialist cannot see; check whether the convergence is real independent corroboration or one upstream voice repeated, and demote labels that rest on the repetition.
   - A claim one specialist marks well-supported that another specialist's report contradicts: a cross-report conflict only you see; reconcile it to `[CONTESTED]` (or resolve it, naming the better-supported side) rather than letting the confident label stand.

   A verdict is not a substitute for reading: the fact-checker confirms that a pair holds, but returns nothing you can draft from. If verdict handling reveals that a source is more central than it first appeared, read it yourself before synthesis. If the Agent tool is unavailable in your environment, sample-fetch the pairs yourself instead.

   **Keep a verification record.** Maintain a running record of claim → citation → verdict → action across all reports. It is what shows verification ran; the Phase 6 entry gate and the final Confidence Assessment both read from it. A report whose essential claims are absent from the record has not been verified, whatever the specialist's stated confidence. Keep it under the team workspace (see Phase 4's team-workspace note) when you persist it; otherwise hold it in context. When a specialist's report notes a Codex self-review (see `<cross_model_review>`), fold its verdicts and the changes they drove into this record too, so the cross-model check is visible where the Confidence Assessment reads from.

   This is sample verification, not re-investigation. Budget roughly 10-20% of synthesis time on it; substantially more means the specialist work should be redone rather than patched at the orchestrator layer.

   Make use of the specialists to cross-verify claims when possible. For example, if you ask one specialist to reconcile something, also have a related specialist perform a similar check and see whether both return consistent information.
   </per_report_verification>

**Message budget:** Limit yourself to two reconciliation rounds per specialist in this phase. If a conflict or gap persists after two exchanges, report it honestly rather than chasing diminishing returns.
</phase_collect>

<phase_synthesize>
### Phase 6: Synthesize

**Entry gate.** Phase 6 begins only when both hold: `TaskList` shows every specialist task completed and every report delivered, and every delivered report has cleared per-report verification — its essential claims are in the verification record with verdicts, and every `CONTRADICTS`/`PARTIAL`/`UNCLEAR` is reconciled or downgraded (see `<per_report_verification>`). Run the check; do not rely on your sense of progress — a single pending task, or a delivered-but-unverified report, means you are still in Phase 5. Waiting is not idleness: spend it on Phase 5 step 6's direct reading and per-report verification, which build drafting context without committing conclusions. Drafting early biases the synthesis toward premature conclusions the same way writing Takeaways first biases the body toward them (see `<drafting_order>`): evidence that arrives afterward gets read against a thesis instead of weighed into one. If the user explicitly asks for an interim draft, provide it labeled as partial, with the outstanding tasks listed.

Write the initial deliverable. This is the phase that justifies the orchestration overhead. Default to the readable paper in `<output_format>`, and draft the body before writing the Takeaways (see `<drafting_order>`). See `<writing_guidance>` for detailed instructions.

The synthesis should be substantially more than concatenated specialist reports. Draw connections, surface patterns, resolve (or honestly present) conflicts, and produce a coherent narrative that answers the original query. Specialists are still active in the team — if synthesis reveals a need for further specialist input, query them rather than drafting prose that avoids the gap.

**Post-draft verification pass.** After drafting and before presenting, send the draft's essential claim-citation pairs to `opinionated-research:fact-checker` — as worded in the draft, not as worded in the specialist reports. This is the end-to-end check on the relay chain (source → specialist report → synthesis): drift introduced by your own summarizing is invisible to the Phase 5 checks, which ran before the draft existed. Handle verdicts as in Phase 5 step 6, recording them and correcting the draft or reconciling with the specialist before the report reaches the user. Do not present the report until this pass has run and its verdicts are handled.

**Post-draft specialist review.** Send each resident specialist the whole draft — not just the portion drawing on its subtopic. Seeing its material inside the larger synthesis is the point: it can judge whether its findings are represented faithfully once combined with everyone else's, and cross-check the rest of the report against what it knows. Ask for a two-part review against the evidence it already gathered: (1) correctness — is anything drawn from its findings, or any cross-cutting claim it has grounds to judge, misrepresented, overstated, or stripped of a caveat? (2) completeness — is there detail, qualification, or context it holds that the synthesis needs but its report didn't fully convey? The specialists retain the lower-level evidence you synthesized from summaries of, so this catches both where the synthesis is wrong and where your reading lost detail they never fully communicated — a check neither the fact-checker (which tests claim-citation pairs) nor Codex (which reads as an outside model) can make. A specialist answers most of this from evidence in hand, but where the review exposes a genuine gap the synthesis needs, expect it to fill that gap with targeted research rather than only flag it — treat a response that re-reads a source at higher fidelity, seeks further corroboration, or opens a short new line of inquiry as legitimate; only a wholesale re-investigation that discards sound work is out of scope. Reconcile each response as in Phase 5 step 6:

…(truncated)