Research Planner

Research Planner

Overview

Turns one research question into a run plan: sub-questions, which source skills to dispatch for each, a search budget, and the condition that ends the run. This skill produces a plan, not evidence — its output is consumed by the orchestrator, which then dispatches the actual source skills.

Workflow

1. Decompose the question into sub-questions. Non-overlapping, each answerable somewhat independently. Budget the count to the question's actual complexity — don't manufacture 5 sub-questions for something that's really 1-2, and don't force a genuinely broad question into 1.

   • Simple fact-finding: 1-2 sub-questions.
   • Comparative ("X vs Y"): one sub-question per compared element, capped around 3.
   • Complex/open investigation: 3-5 sub-questions.

2. Match each sub-question to source skills. A sub-question can dispatch more than one source skill — pick by what kind of evidence would actually settle it, not by habit:

   • A claim about official specs/pricing/terms → official-source-research (+ web-research to find it if the URL isn't already known).
   • A claim about whether something actually works/ships → github-research (+ web-research for docs).
   • A claim about user sentiment/demand/pain points → reddit-research + social-research.
   • A claim about a launch/event → news-research (which itself traces to official-source-research when it finds a press-release root).
   • A claim resting on published research → academic-research.
   • A practitioner's direct account → blog-research.

3. Set a search budget per sub-question, scaled to the same complexity tiers as decomposition — a simple sub-question gets 3-5 searches, a complex one more, but state the number explicitly in the plan so source skills know when they've done enough for this round.

4. One sub-question, one claim_class. If a question mixes kinds — "do people like X, and does it actually work?" — split it: one community-signal sub-question and one implementation sub-question. A single sub-question carrying both forces one bar onto evidence that should face two, which is how community volume ends up grading a technical claim. Declare each sub-question's claim_class (fact / implementation / community-signal / opinion). This is not bookkeeping: it determines which quality bar the eventual finding must clear (engine/ranking.md), and therefore what "enough evidence" means for this sub-question before any search runs. Declaring it up front is also what stops the class from being back-inferred from whatever evidence happened to turn up.

5. Set the stopping condition (constitution rule 11). Two distinct rules, deliberately separated:

   • Global stop: the run ends after 2 consecutive rounds in which no new evidence was collected across all still-active sub-questions. "New evidence" is defined in engine/dedup.md — a restatement of an existing claim from an existing root is not new.
   • Per-sub-question saturation: a sub-question that meets its claim-class bar, or that individually returns nothing new for 2 rounds, stops drawing budget. It does not end the run; other sub-questions keep going. A sub-question still open when the run stops is a gap, not a failure; it goes to the report's gaps section.

6. Confirm scope with the user before dispatch — required for anything beyond quick-research. Steps 1-5 are cheap: no network calls, just a draft plan. Before turning that draft into real dispatch, show it and ask what to narrow:

   This will check N sub-questions across these sources: <list>. Want me to focus on specific ones, skip any, or run the full set?

   This exists because a deep-research/market-research/competitive-research/technology-research run can touch most of the 8 source skills and take a long time — asking before collection starts is the only point where narrowing is cheap. A user who says "just check GitHub and the docs" turns a 6-source draft into a 2-source dispatch before a single search runs.

   Skip this gate for quick-research — that workflow is already narrow by design (1-2 sub-questions, 2-3 sources, 1 round; see workflows/quick-research.md), and for any request where the user already named the specific source(s) they want ("search GitHub for X" routes straight to github-research, bypassing the planner entirely — this gate only applies when the full pipeline is what's running).

   If the user doesn't respond with changes, proceed with the drafted plan — this is a confirmation checkpoint, not a blocking questionnaire; don't re-ask for depth beyond one round of narrowing.

7. Write the confirmed plan to the run's ledger (state/ledger.md format) before dispatch: sub-questions, claim classes, assigned source skills, budget, stopping condition, and any narrowing the user requested at step 6. This is the artifact the orchestrator hands to source skills and later checks the run against — plan before work, not vibes.

Output

A written, user-confirmed plan (sub-questions → claim class → source skills → budget → stopping condition), not evidence records. The orchestrator dispatches source skills against this plan.

Common mistakes