Brainstorm

Brainstorm

Overview

This is the first step in the superpapers pipeline for any new research project. It starts by invoking academic-baseline as the standing policy layer for the session, then mirrors the Superpowers brainstorming philosophy — Socratic questions, proposed approaches, incremental design approval — but asks research-specific questions. The terminal state is invoking write-plan. No implementation, data collection, or literature review beyond gap-verification happens until the design spec is written and approved by the user.

When to Use

• "I have an idea for a paper"
• "I want to study X"
• "Can you help me think through this research question?"
• Start of any new empirical research project
• Before any data collection or analysis begins
• Revisiting a stalled project with a new angle

When NOT to Use

• Mid-project troubleshooting — use statistical-modeling or the relevant domain skill
• The research question and design are already clear and stable
• Formatting, writing, or submission tasks — use journal-guidelines or other late-stage skills

Hard Gate

Do NOT invoke write-plan, execute-plan, data collection, analysis, or any literature search beyond gap-verification until the design spec is written and the user has explicitly approved it. This applies to every project regardless of apparent simplicity.

Mandatory Steps

1. Invoke academic-baseline and replication-driven-research first. academic-baseline resolves CLAUDE.superpapers.md via the walk-up Read (current working directory, then parent directories) and carries its settings into the session; its nine principles apply from the first question onward. replication-driven-research anchors the design as end-to-end reproducible — data to scripts to outputs to paper, with fixed seeds. Both skills stay active for the entire brainstorm.

2. Explore project context. Inspect existing data/, paper/, .bib files, and git history. Settings from CLAUDE.superpapers.md are already loaded via step 1. Learn what already exists before asking questions.

3. Detect research field and paper language. From project context when possible; otherwise ask the user. The field shapes which databases, methods, and journals will be relevant. The paper language determines later user-facing output.

4. Ask Socratic questions one at a time. Do not batch. Use multiple choice where possible. Cover these topics in roughly this order:

   • Research question: What is the question? Can it be rejected by data?
   • Exploratory vs confirmatory: This shapes every downstream decision — specification rigidity, multiple testing corrections, framing.
   • Causal vs descriptive: What would a causal answer require — and is that answerable with the available data?
   • Identification strategy: Candidate — DiD, RD, IV, SC, time-series, none (descriptive)? Invoke statistical-modeling to apply its guidance on specification, assumptions, and diagnostics for the chosen strategy.
   • Data: What would you need? Does it exist? Is it accessible? At what cost? Invoke data-collection for source-discovery guidance only; the hard gate above still blocks actual collection.
   • Contribution: What's the contribution over existing literature? Invoke literature-search in gap-check mode: one or two targeted queries, 5-8 results maximum, no bibliography output. This is NOT the full literature review. The full review runs in the plan's Literature phase, where literature-search is invoked in full mode with all its Mandatory Steps. Do not conflate the two invocations.