research-driven-development

Research-Driven Development

Dispatch parallel research agents, synthesize their findings, and write a persistent research document. Research is not complete until there is a written artifact — verbal answers without documents are prohibited.

Announce at start: "I'm using the research-driven-development skill to investigate this topic."

When to Use

• User asks a question about a technology, concept, or approach
• User says "research this", "deep dive", "investigate", "look into"
• User asks "what is X", "how does Y work", "compare A vs B"
• Before planning a non-trivial task that requires understanding first
• When you need to understand something before making a decision

When NOT to Use

• User asks about a specific file in the current codebase (just read it)
• The answer is a single fact you already know with certainty
• User explicitly asks for a quick verbal answer

Iron Law

NO RESEARCH WITHOUT A DOCUMENT. Every research task produces a written artifact. Verbal answers without persistent documents are prohibited. If you researched it, write it down.

Grounding Rule

Every load-bearing claim must be grounded by the verify stage (Step 4) before the document is written.

Pipeline

Step 0: Scope check (conditional)
Step 1: Create bead + calibrate effort
Step 2: Check existing knowledge
Step 3: Decompose + dispatch parallel research agents
Step 4: Synthesize + verify findings
Step 4.5: Gap-closing round (if needed)
Step 5: Write document
Step 6: End-gate (top-level only) + close bead

Step 0: Scope Check (conditional)

If the question is already specific, skip this step. Fire it only when you cannot name the sources you'd search or the decision the answer informs — e.g. "research databases" (too vague). Do NOT fire when scope is already present — e.g. "compare Postgres vs SQLite for our embedded Dolt use case". This is disambiguation, not a quality gate — mandatory scope-gating just duplicates what a capable model already does; the "When NOT to Use" list still applies.