Interactive Research Interview

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

The CLAUDE.md Template

Copy this into a CLAUDE.md file in your research folder:

# 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]

## 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.