/framing-research-questions

name: framing-research-questions
description: You MUST use this before any data analysis or investigation - before exploring a dataset, loading or profiling data, running a model, computing a statistic, or testing an idea, and before any outcome data is touched

Framing Research Questions Into Investigations

Help turn a fuzzy research interest into a precise, falsifiable question with explicit hypotheses, the data required, and what would count as an answer — through natural collaborative dialogue.

Start by understanding the context (the data on hand, the domain, what your human partner already knows), then ask questions one at a time to sharpen the interest. Once you understand what is being investigated, present the framing and get approval.

<HARD-GATE> Do NOT load the dataset, compute any statistic, fit any model, plot any outcome, or invoke any execution skill until you have presented a research framing and your human partner has approved it. This applies to EVERY investigation regardless of perceived simplicity.

**Why this gate is strict for science specifically:** Looking at outcomes before the question and predictions are fixed contaminates a confirmatory analysis. Once you have seen the data, you cannot un-see it, and every later choice (which test, which subgroup, which cutoff) becomes suspect. Framing first is what keeps a result confirmatory rather than a story told after the fact.

**What this gate does NOT forbid:** measuring whether the computation can run — assembly size, peak memory, wall clock, iteration counts, convergence behavior. Those are provenance and structure, not outcomes. Resource measurement never contaminates a confirmatory analysis, because the outcome variable is untouched. </HARD-GATE>

When Feasibility Is Unknown

If it is not yet known whether the computation can run at all — an unbenchmarked solver, an unproven pipeline, a configuration whose memory or wall-clock ceiling is estimated rather than measured — say so during framing and offer feasibility mode:

> "Whether this can run at scale is unknown, and the design depends on the answer. I can establish feasibility first — a minimal runner, three scaling probes, one exploratory campaign — and defer the survey, plan, and pre-registration until we know what is runnable. Nothing produced that way can support a confirmatory claim. Or we proceed with the standard sequence. Which?"

**Only your human partner can choose it.** If they do, use `science-superpowers:establishing-feasibility-first` after a short framing. If they decline or say nothing, continue the standard sequence below.

Separate the two questions in the framing either way: the feasibility question (a measurable threshold) and the scientific question it gates. Tangling them produces predictions written over runs that may not be possible.

Anti-Pattern: "This Is Too Simple To Need Framing"

Every investigation goes through this process. A single t-test, a quick correlation, a "just look at the trend" — all of them. "Simple" questions are where unexamined assumptions and undeclared researcher degrees of freedom do the most damage. The framing can be short (a few sentences for a truly simple question), but you MUST present it and get approval.

Checklist

You MUST create a task for each of these items and complete them in order:

1. **Explore context** — what data exists, its shape and provenance, the domain, recent related work in the repo 2. **Ask clarifying questions** — one at a time; understand the phenomenon, the population, the unit of analysis, and what decision the answer informs 3. **Propose 2-3 framings** — different ways to make the question precise, with trade-offs and your recommendation 4. **Present the framing** — question, hypotheses, data needed, success/answer criteria, scope; get approval after each section 5. **Write the question document** — save to `docs/science-superpowers/questions/YYYY-MM-DD-<topic>.md` and commit 6. **Self-review** — quick inline check for vagueness, unfalsifiable claims, undefined measures, scope creep (see below) 7. **Your human partner reviews the written framing** — ask them to review the file before proceeding 8. **Transition** — invoke surveying-prior-work to ground methods, then designing-the-analysis

Process Flow

digraph framing {
    "Explore context" [shape=box];
    "Ask clarifying questions" [shape=box];
    "Propose 2-3 framings" [shape=box];
    "Present framing sections" [shape=box];
    "Partner approves framing?" [shape=diamond];
    "Write question doc" [shape=box];
    "Self-review (fix inline)" [shape=box];
    "Partner reviews doc?" [shape=diamond];
    "Invoke surveying-prior-work" [shape=doublecircle];

    "Explore context" -> "Ask clarifying questions";
    "Ask clarifying questions" -> "Propose 2-3 framings";
    "Propose 2-3 framings" -> "Present framing sections";
    "Present framing sections" -> "Partner approves framing?";
    "Partner approves framing?" -> "Present framing sections" [label="no, revise"];
    "Partner approves framing?" -> "Write question doc" [label="yes"];
    "Write question doc" -> "Self-review (fix inline)";
    "Self-review (fix inline)" -> "Partner reviews doc?";
    "Partner reviews doc?" -> "Write question doc" [label="changes requested"];
    "Partner reviews doc?" -> "Invoke surveying-prior-work" [label="approved"];
}

**The terminal state is invoking surveying-prior-work** (then designing-the-analysis). Do NOT jump to loading data or fitting models. The ONLY skills you invoke after framing are surveying-prior-work and designing-the-analysis — or, if and only if your human partner opted into feasibility mode, establishing-feasibility-first.

The Process

**Understanding the interest:**

• Inspect the context first: what data is available, its schema, size, and where it came from. You may look at *structure and provenance* (column names, row counts, collection method) — but do NOT look at outcome distribut