research

Files (1)

• SKILL.md

SKILL.md (first lines)

# Research

Turn a loose topic into a synthesized, sourced findings report. This is the step *before*
`/grill-me` and plan mode, not a replacement for them — it ends by handing the user a report,
never by auto-continuing into an interview or a plan.

## Process

### 1. Discuss

Get the topic and the reason it matters in a sentence or two: what decision or question this
research is meant to inform. If the user already stated it, don't re-ask — just confirm you have
enough to scope the question set. If it's genuinely vague (no worked-out angle at all), ask one
clarifying question rather than guessing at scope; don't turn this into a `/grill-me` interview.

### 2. Draft the question set

Write an exhaustive set of sub-questions covering the topic, grouped by theme (e.g. prior art /
existing solutions, technical tradeoffs, cost/pricing, risks and failure modes, ecosystem/vendor
landscape, what would change the answer). Aim for coverage, not padding — skip themes that don't
apply to this topic rather than forcing a fixed template.

Show the numbered, grouped list to the user before dispatching anything. This is a cheap
checkpoint: dispatching a dozen parallel agents on the wrong question set is the expensive
mistake it prevents. Let the user add, cut, or re-scope questions. Skip the pause only if the user
explicitly said to just go (e.g. "research X and report back").

### 3. Dispatch

Cluster related questions into research agents — don't spawn one agent per question, that's
usually too fine-grained; don't dump every question on one agent either, that's too coarse to
parallelize. A handful of clusters (roughly 3-8, scaled to topic breadth) is typical.

Launch them as **parallel forks** (`subagent_type: "fork"`) in a single message — per this user's
token-discipline preference, forking beats fresh agents here because the raw search/fetch output
isn't needed afterward, only the synthesized findings, and forks share this session's prompt
cache. Each fork's prompt should:
- Name its specific question cluster, not the whole topic (a fresh reader of just that prompt
  should know exactly what to go find).
- Be told to use WebSearch/WebFetch and any other relevant tools, prefer primary sources over
  secondhand summaries, and cite what it used (URLs, doc titles).
- Be told to flag disagreement between sources and areas where it couldn't find a confident
  answer, rather than smoothing over gaps.

Do not race ahead and narrate or guess at findings before the forks report back — their results
arrive as later notifications, not something to predict.

### 4. Synthesize

Once all forks report, merge their findings into one coherent report, organized by the same
themes as the question set (not by which agent answered what). For each theme: the answer(s), the
confidence level, and where sources disagree or coverage is thin. Note the actual sources used;
don't present findings as settled fact if only one weak source backs them.

If the report is long enough that the user would want to reference, share, or come back to it
later, offer it as an Artifact in one line rather than only dumping it into chat — don't publish
without asking.

### 5. Stop

End by handing over the findings report. Do not automatically start `/grill-me`, enter plan mode,
or propose next steps as if they're already decided — the user reads the research and decides
what, if anything, to interview themselves about next. It's fine to mention `/grill-me` is there
if they want to sharpen a resulting plan, but that's a pointer, not a continuation.

From jpol34/polyak-dev-kit, MIT.

More from jpol34/polyak-dev-kit