Research a "which should I use / which approach" question and land a recommendation. researchkit enumerates the credible options, investigates each against primary sources (official docs, source code, specs, first-party APIs, maintainer benchmarks, not blog hearsay), compares them on the constraints that actually matter, and picks one with a cited, dated rationale. It is decision research: the goal is a choice you can act on, not a neutral pile of notes.

It front-runs planning. Answer "Drizzle or Prisma?", "which queue for this workload?", "REST or gRPC here?" first, then turn the chosen direction into a plan. If you use plankit, researchkit is the step before it.

Any "which one / which approach" question where the answer isn't obvious and the stakes justify looking: "compare X and Y", "which should I use", "evaluate options for Z", "what's the best library/tool/service for …", "should we use X or Y", "research X before we build", "/researchkit".

Three things it deliberately is not:

researchkit's deliverable is a cited argument, not a working artifact. It never writes, runs, or scaffolds code to test a hypothesis: no spike, no prototype, no benchmark harness, no throwaway repo, no to see what happens, not even a "quick" one. This holds however tempting the shortcut looks and however much it would sharpen the recommendation.

The failure mode is specific and worth naming, because it feels helpful from the inside: research turns up a claim the docs don't settle, building a small test looks like the fastest way to settle it, and twenty minutes later the user is reading about a prototype they never asked for. The user asked which option to pick. Handing back an implementation instead answers a question they didn't ask, spends their time and tokens without consent, and buries the comparison they wanted.

So: surface the hypotheses and the evidence, then stop and let the user choose. If a spike is genuinely the only way forward, say that in Open questions ("settling this needs a spike: <what it would measure>") and wait. Building one is a separate, explicitly requested job: prototypekit's when it's installed, and otherwise a throwaway the user asks for by name. It is never researchkit's, and it is not the build step's either, because that one needs a settled intent and ships production code.

Pin down what's actually being chosen and the constraints that decide it: the stack it plugs into, scale, budget, team familiarity, must-have features, hard constraints. If the ask is a bare one-liner, ask a couple of scoping questions first; the constraints are what turn a generic comparison into a real recommendation.

Enumerate the real contenders, the ones a knowledgeable engineer would actually weigh. Don't pad the field with strawmen to look thorough. If only one option genuinely survives the constraints, say so and switch to explainer mode for that one.

Use whatever web search/fetch tools the host exposes to read the authoritative origin for each load-bearing claim (official docs, the source, the spec, the first-party API, a maintainer-published benchmark) over secondary interpretation. For every source, note its version and date, and flag when the evidence may be stale (a benchmark from an old major version, a doc that predates a rewrite). Trace each claim back to where it's actually established.

No web access? Say so plainly, then give a best-effort comparison from knowledge with an explicit staleness warning, and never fabricate a citation. A missing source is stated as missing, not invented.

A claim the sources won't settle (a performance number for your exact workload, whether two libraries actually interop, whether an API does what its docs imply) is not a cue to go test it. Mark it unverified, carry it into Open questions, and let the reader decide whether it's worth a spike. prototypekit is where that spike belongs when it's installed. Unresolved is a legitimate research finding; a surprise prototype is not.

Lay the options against the constraints that matter (from Frame the decision), not a generic feature grid. Each load-bearing claim in the comparison carries its source. Keep it to the axes that actually move the decision.

Pick one. Give a one-line why, and state the condition under which you'd pick differently ("Drizzle, for its lighter runtime and no codegen; choose Prisma if you need its migration tooling and admin GUI"). Give a recommendation the reader can accept, reject, or redirect, not a shrug.

Print the recommendation, then offer the next steps without starting either:

Print inline by default; write to a file only when asked. Either way, the shape:

undefined

<the pick>: <one-line why>. Choose <alternative> instead if <condition>.

Unresolved or thin spots to settle when planning, including any claim that would need a spike to settle, named but not acted on. Those hand off cleanly to prototypekit when it's installed.

Scale it to the decision. A two-way library pick is a short block; an architecture choice earns more. Drop any section that would be filler.