Academic ResearchBeginner
Interactive Research Interview
Use Claude as an interviewer to formalize vague ideas into concrete specifications. Transform 'I have this intuition...' into a clear research plan.
#research#interview#ideation#clarification#planning
You have an intuition about something important but can't articulate it clearly enough to write a proposal, design a study, or explain it to your advisor. The idea is there — it just needs someone to ask the right questions to draw it out.
Who it's for: researchers with half-formed ideas that need structure, PhD students preparing for advisor meetings, scientists translating intuitions into testable hypotheses, founders clarifying product visions, anyone who thinks better when asked good questions than when staring at a blank page
Example
"I have a vague idea about how social networks affect misinformation — help me formalize it" → Structured interview extracting your core insight, specific research questions, testable hypotheses, proposed methodology, and a 1-page research plan — all from a 15-minute conversation
CLAUDE.md Template
New here? 3-minute setup guide → | Already set up? Copy the template below.
# Research Interview System
## Command
`/interview-me [topic]` — Start an interactive interview to formalize an idea
## Interview Protocol
### Role
Claude acts as an experienced research advisor conducting a structured interview. The goal is to extract implicit knowledge and assumptions, then formalize them.
### Interview Structure
**Opening (1 question)**
"Tell me about your idea in your own words. Don't worry about being precise yet — just describe what you're thinking about."
**Phenomenon Clarification (2-3 questions)**
- What exactly are you trying to understand or explain?
- Can you give me a concrete example?
- When you say [key term], what do you mean specifically?
**Significance Probe (2-3 questions)**
- Why does this matter?
- Who cares about the answer?
- What would change if we knew the answer?
**Prior Knowledge Check (2-3 questions)**
- What do we already know about this?
- What have others tried?
- What's your hunch about the answer?
**Specification Drilling (3-5 questions)**
- What's your dependent variable / outcome?
- What's the independent variable / treatment?
- What's the population of interest?
- What's the unit of analysis?
- What's the time frame?
**Method Exploration (2-3 questions)**
- How would you ideally test this?
- What data would you need?
- What's preventing you from doing the ideal test?
**Synthesis**
After the interview, synthesize into a formal specification document.
### Interview Rules
1. **Ask one question at a time** — Let the user respond fully
2. **Build on answers** — Reference what they said in follow-ups
3. **Probe vagueness** — "When you say X, do you mean A or B?"
4. **Challenge assumptions** — "Why do you assume that?"
5. **Don't answer for them** — Draw out their thinking
6. **Summarize periodically** — "So what I'm hearing is..."
## Output: Specification Document
After the interview, produce:
```markdown
# Research Specification: [Title]
## Research Question
[One clear, focused question]
## Hypothesis
[Predicted answer with rationale]
## Key Constructs
- [Construct 1]: [Definition]
- [Construct 2]: [Definition]
## Population & Sample
- Target population: [Who/what]
- Sampling strategy: [How to select]
- Unit of analysis: [Individual/firm/country/etc.]
## Variables
- Outcome: [What you're measuring]
- Treatment/Predictor: [What varies]
- Controls: [What to account for]
## Proposed Method
[Ideal approach]
## Feasibility Constraints
[What limits the ideal approach]
## Fallback Method
[Practical alternative]
## Open Questions
[What's still unclear]
```
README.md
What This Does
When you have a vague idea but not a clear plan, this playbook has Claude interview you to draw out the specifics. Through structured questioning, it transforms fuzzy intuitions into concrete research questions, hypotheses, and methodologies.
Prerequisites
- Claude Code installed and configured
- A vague idea you want to clarify
## Step-by-Step Setup
### Step 1: Add to your CLAUDE.md
Add the interview template above to your research folder's CLAUDE.md.
### Step 2: Start an interview
/interview-me [brief description of your idea]
### Step 3: Answer questions honestly
Don't try to sound smart. The goal is to externalize your thinking, including the parts you're unsure about.
## Example Usage
**User:**
> "/interview-me I have a hunch that AI coding assistants are making programmers worse at debugging"
**Claude:**
> ## Research Interview: AI Coding Assistants & Debugging
>
> **Q1: Tell me about your idea in your own words.**
**User:**
> "I use Copilot a lot, and I've noticed that when code doesn't work, my first instinct is to ask the AI to fix it rather than understanding why it's broken. I worry that this means programmers are losing debugging skills."
**Claude:**
> Interesting. So you're observing a behavioral change in yourself — outsourcing diagnosis to AI.
>
> **Q2: Can you give me a concrete example of this happening?**
**User:**
> "Yesterday I had a null reference error. Old me would have traced the code path. Instead, I just highlighted the error and asked Copilot to fix it. It worked, but I don't really understand why the null happened in the first place."
**Claude:**
> Got it. So the concern is about understanding, not just output.
>
> **Q3: When you say 'debugging skills,' what specifically do you mean? What would a skilled debugger do differently?**
**User:**
> "They'd read the stack trace, form hypotheses about the cause, test those hypotheses, understand the root cause, then fix it. It's systematic problem-solving."
**Claude:**
> So debugging skill = systematic diagnostic ability, not just fixing symptoms.
>
> **Q4: Why does this matter? What's the consequence if programmers get worse at this?**
**User:**
> "When AI assistants are wrong — and they often are — programmers need to fall back on real skills. If we've atrophied those skills, we're stuck. Also, deep debugging builds understanding of systems. Lose that, lose architecture understanding."
**Claude:**
> Two concerns: fragility when AI fails, and loss of deep system understanding.
>
> **Q5: What's your hunch — do you think this is actually happening, or just a fear?**
**User:**
> "I think it's real for me personally. I'm not sure about the broader population. Junior developers who grew up with AI assistance might never develop these skills in the first place."
**Claude:**
> Interesting distinction: skill atrophy in experienced devs vs skill non-development in juniors.
>
> **Q6: How would you ideally test whether this is happening?**
**User:**
> "Compare debugging performance of programmers with/without AI assistance experience. Give them a bug, measure how they diagnose it."
**Claude:**
> What would you measure specifically?
>
> **...[interview continues]...**
>
> ---
>
> ## Research Specification: AI Assistance & Debugging Skill
>
> ### Research Question
> Does regular use of AI coding assistants reduce programmers' systematic debugging abilities?
>
> ### Hypothesis
> Programmers who heavily use AI code assistants will show weaker diagnostic processes (fewer hypotheses, less systematic testing, faster resort to trial-and-error) when debugging without AI assistance.
>
> ### Key Constructs
> - **Debugging skill**: Systematic diagnostic ability including hypothesis formation, targeted testing, root cause identification
> - **AI assistance reliance**: Frequency and manner of using AI for debugging tasks
>
> ### Population & Sample
> - Target: Professional software developers with 2+ years experience
> - Groups: High AI users (daily) vs Low AI users (rarely/never)
> - Unit: Individual developer
>
> ### Variables
> - Outcome: Debugging performance score (time, success, process quality)
> - Treatment: AI usage level (natural variation or experimental manipulation)
> - Controls: Years experience, language familiarity, baseline problem-solving ability
>
> ### Proposed Method
> Experimental: Give developers debugging tasks with AI disabled. Compare performance by AI usage history. Think-aloud protocol to assess process.
>
> ### Open Questions
> - How to measure "process quality" objectively?
> - Confounds: Maybe worse debuggers adopt AI more heavily (reverse causation)?
## Tips
- **Be honest about uncertainty**: "I'm not sure" is useful information. Claude can probe that uncertainty.
- **Give examples**: Abstract descriptions are hard to formalize. Concrete examples make it easier.
- **Let Claude push back**: If Claude challenges an assumption, engage with it. That's where the value is.
- **Don't rush**: The interview takes 10-15 minutes. That's time well spent.
## Troubleshooting
**Problem**: Claude's questions feel generic
**Solution**: Give more specific context in your initial response. The more Claude knows, the better it can probe.
**Problem**: Interview goes in circles
**Solution**: Ask Claude to summarize what it's learned so far and identify the key remaining ambiguity.
**Problem**: Specification still feels vague
**Solution**: Ask Claude to identify the weakest part of the specification and interview you more on that.