Purpose
Convert a fuzzy topic or stakeholder request into a precisely scoped, answerable research question — with defined constructs, a clear unit of analysis, and an explicit link to the decision it will inform — so study design starts from a sharp target instead of a moving one. Prevents the most common and expensive research failure: running a well-executed study that answers the wrong question.
When to Use
Invoke this skill when the user asks to:
- Sharpen a broad topic ("does our product help students learn?") into a studyable question
- Translate a stakeholder or executive request into a research question
- Scope a research initiative before choosing methodology
- Separate one overloaded question into a primary question plus sub-questions
- Decide whether a proposed question is even answerable with available data and access
- Align a team on what a study will and won't cover before design kickoff
Inputs Required
Before starting, collect:
- Raw topic or request: The question or topic as it currently exists, in the requester's words
- Decision it informs: What action or choice the findings will drive, and who makes it
- Population/context: Who or what the question is about (learners, teachers, cohorts, segments, product surfaces)
- Timeline and resources: How long the team has and what data, access, or budget exists
- Prior work: What's already known or previously studied on this topic
- Stakeholders: Who requested this and who will consume the findings
- Constraints: Access limits, ethical/consent considerations, or off-limits data
If the decision it informs is missing, treat that as the first thing to reconstruct — an unlinked question is the primary risk this skill exists to catch. State the assumed decision explicitly so the requester can correct it.
Instructions
Step 1: Reconstruct the Decision Behind the Request
Before touching the question wording, surface the decision.
- Name the specific choice the findings will inform (ship/kill, redesign X, invest in Y, target segment Z).
- Identify the decision-maker and the threshold that would change their mind.
- Apply the "So what?" test: if you had a perfect answer, what would the team do differently? If nothing, the question isn't worth studying yet — flag it and stop.
- Distinguish research questions (answerable with evidence) from strategy questions (require judgment calls) and operational questions (already answerable from existing data). Route non-research questions out.
Step 2: Diagnose the Raw Question
Score the raw question against five failure modes and note which apply:
- Too broad: no bounded population, timeframe, or outcome
- Compound/overloaded: two or more questions fused into one
- Assumption-laden: presumes an unproven causal or definitional premise
- Unmeasurable construct: relies on a term ("engagement," "learning," "success") with no operational definition
- Undecidable: no realistic data or access could answer it
Step 3: Define the Constructs
For each fuzzy term in the question, produce an operational definition.
- State the construct (e.g., "learning gain"), the observable indicator (e.g., "pre/post assessment score delta on standards-aligned items"), and the boundary (what counts and what doesn't).
- Flag any construct that has multiple defensible definitions and pick one deliberately, noting the trade-off.
- For EdTech/product contexts, explicitly separate behavioral proxies (time-on-task, sessions) from outcome constructs (mastery, retention) — do not let a proxy silently stand in for the outcome.
Step 4: Set the Unit of Analysis and Scope
- Fix the unit of analysis: student, session, class, cohort, teacher, school, account, or feature.
- Define the population and timeframe explicitly.
- Write a one-line scope boundary: "This study covers ___ and explicitly does not cover ___." Name at least two adjacent questions being deliberately excluded.
Step 5: Draft the Primary Question and Sub-Questions
Frame the question type deliberately using the appropriate frame:
- Descriptive ("What is happening / who / how much"): frame around measurement and prevalence
- Relational ("Is X associated with Y"): name both variables and the population
- Causal ("Does X cause Y"): name the intervention, comparison, outcome, and confound risk — and confirm the design could support a causal claim
- Exploratory ("Why / how / what patterns"): frame around discovery, not confirmation
Produce one primary question and 3-5 supporting sub-questions that decompose it. Each sub-question must be independently answerable and ladder up to the primary.
Step 6: State Hypotheses or Expected Findings
- For confirmatory questions: state a directional hypothesis and its null, plus what result would falsify it.
- For exploratory questions: state expected findings or working assumptions the study could confirm or overturn.
- Name the result that would surprise the team — this exposes hidden bias and sharpens the design.
Step 7: Feasibility Go/No-Go
Run a final gate before handing off to design:
- Data: Does the needed evidence exist or can it be collected in the timeframe?
- Access: Are the participants, records, or consent obtainable?
- Answerability: Could any realistic finding actually move the decision?
- Return a verdict: Go, Go with narrowed scope, or No-go (reason) — with the single change that would flip a no-go to a go.
Output Format
- Structure: Structured document with labeled sections; primary question and sub-questions rendered as a clearly set-off block
- Length: 700-1,000 words
- Format: Structured prose with short bulleted lists; construct definitions in a compact table (Construct / Indicator / Boundary)
- Sections: Decision Behind the Question → Diagnosis of Raw Question → Construct Definitions → Unit of Analysis & Scope Boundary → Primary Question + Sub-Questions → Hypotheses / Expected Findings → Feasibility Verdict
- Tone: Research director — precise, skeptical, decision-first; comfortable telling the requester their question isn't ready
Quality Checklist
Before delivering output, verify:
- [ ] The primary question passes the "So what?" test — a named decision changes based on the answer
- [ ] Every fuzzy construct has an operational definition with an observable indicator (count them against the raw question's vague terms)
- [ ] The question type (descriptive/relational/causal/exploratory) is named and matches what a feasible design could support
- [ ] The scope boundary explicitly names at least two excluded adjacent questions
- [ ] 3-5 sub-questions are present and each is independently answerable
- [ ] The feasibility verdict is stated as Go / Go-with-narrowed-scope / No-go — not left ambiguous
Notes
- The most common defect in EdTech research is a behavioral proxy standing in for a learning outcome — catch this in Step 3 every time.
- When a request arrives as a compound question, splitting it is usually more valuable than answering it; resist the urge to fuse sub-questions back together for tidiness.
- A "No-go" verdict is a successful output, not a failure — it saves a study's worth of effort. Always pair it with the one change that would make it a Go.
- Causal framings are the easiest to write and the hardest to answer; if the available design is observational, reframe the question as relational rather than overclaiming.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills