researchkit

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.

When this fires

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:

• Not a neutral note-taker. It always ends in a recommendation. If there's genuinely nothing to compare (one credible option survives), it degrades to a cited explainer of that option, but it never dumps opinion-free notes as the deliverable.
• Not repo grounding. Reading this codebase to reuse existing patterns is planning work, not researchkit's job. researchkit investigates the external landscape: tools, libraries, services, approaches.
• Not implementation. researchkit reads and cites; it never builds. See Never build to find out. This is the boundary users most often see it cross, and crossing it is always a bug.

Never build to find out

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 npm install to see what happens, not even a "quick" one. This holds however tempting the shortcut looks and however much it would sharpen the recommendation.