domains / research / research-idea-interview / interview-me

interview-me

Skill card

combined

The first two copies are the same general-purpose 'interview-me' skill (one is a mirror of the other) that extracts user intent for any underspecified ask. The third copy is a distinct, domain-specific skill that uses a similar one-question-at-a-time interview format but targets formalizing a research idea into a structured empirical specification. Because the third copy contains material steps and a different output artifact that the first two lack, crowning one would hide a real alternative.

Repositories

Other copies

Combined skill

# Interview Me

## Overview
Use this skill to clarify what the user actually wants before any plan, spec, or code exists. The interview is conversational: ask one question at a time, wait for the user's response, and build toward a clear statement of intent or a structured specification.

## When to Use
- The ask is underspecified (missing who, why, success criteria, or binding constraints).
- The request is conventional rather than specific.
- You are tempted to fill in ambiguous requirements with assumptions.
- The user explicitly invokes an interview ("interview me", "grill me", "stress-test my thinking").
- The user wants to formalize a research idea into a structured specification.

## When NOT to Use
- The ask is unambiguous and self-contained.
- The user has explicitly asked for speed over verification.
- Pure information requests or mechanical operations.
- You already have ≥95% confidence.

## Loading Constraints
This skill requires a live, responsive user. Do not invoke in non-interactive contexts (CI pipelines, scheduled runs, autonomous loops). If the ask is underspecified in such a context, flag it as a blocker.

## The Process

### Step 1: Hypothesize
Write down your current best read of what the user wants in one sentence, plus an honest confidence number (0–100%). If confidence is below ~70%, append a brief reason for what is still unresolved.

### Step 2: Ask One Question at a Time
Format each question with a guess attached:
```
Q: <one focused question>
GUESS: <your hypothesis for the answer, with reasoning>
```
Wait for the user to react before asking the next question. Do not batch questions.

### Step 3: Listen for "Want vs. Should Want"
Watch for answers that pattern-match best-practice talk, defer to convention, or use buzzwords as goals. When you hear these, ask:
> "If you didn't have to justify this to anyone, what would you actually want?"

### Step 4: Restate Intent
When confidence is high, write back what you now think the user wants in 5–8 lines, using the user's language where possible. Structure it so the user can confirm or correct line by line.

## Research-Specific Extension
If the user is formalizing a research idea, follow these phases after the initial hypothesis:

### Phase 1: The Big Picture (1–2 questions)
- What phenomenon or puzzle are you trying to understand?
- Why does this matter? Who should care about the answer?

### Phase 2: Theoretical Motivation (1–2 questions)
- What's your intuition for why X happens / what drives Y?
- What would standard theory predict? Do you expect something different?

### Phase 3: Data and Setting (1–2 questions)
- What data do you have access to, or what data would you ideally want?
- Is there a specific context, time period, or institutional setting you're focused on?

### Phase 4: Identification (1–2 questions)
- Is there a natural experiment, policy change, or source of variation you can exploit?
- What's the biggest threat to a causal interpretation?

### Phase 5: Expected Results (1–2 questions)
- What would you expect to find? What would surprise you?
- What would the results imply for policy or theory?

### Phase 6: Contribution (1 question)
- How does this differ from what's already been done? What's the gap you're filling?

### After the Interview
Once you have enough information (typically 5–8 exchanges), produce a Research Specification Document with the following sections:
- Research Question
- Motivation
- Hypothesis
- Empirical Strategy (Method, Treatment, Control, Key identifying assumption, Robustness checks)
- Data (Primary dataset, Key variables, Sample)
- Expected Results
- Contribution
- Open Questions

Save the document to `quality_reports/research_spec_[sanitized_topic].md`.

## Interview Style
- Be curious, not prescriptive. Draw out the user's thinking, not your own ideas.
- Probe weak spots gently. Ask "What would a skeptic say about...?" rather than "This won't work because..."
- Build on answers. Each question should follow from the previous response.
- Know when to stop. If the user has a clear vision after 4–5 exchanges, move to the specification or restatement. Don't over-interview.