Mmcp.market

interview-me skill

by pedrohcgs·pedrohcgs/claude-code-my-workflow·1.6k stars·MIT

Interactive interview that formalizes a fuzzy research idea into a structured spec (RQ, hypotheses, identification, data needs, empirical strategy). Use when user says "interview me", "help me think through this idea", "I have a half-baked idea", "formalize this into a project", "walk me through framing a study". Multi-turn Q&A; saves spec to disk. NOT for lit review (`/lit-review`) or ideation from scratch (`/research-ideation`).

A100/100content scan

Is the interview-me skill safe?

Clean: nothing in its files matched our rules. We read 1 file in the folder on 2026-09-28.

No findings.

Install the interview-me skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.

git clone --depth 1 https://github.com/pedrohcgs/claude-code-my-workflow.git /tmp/claude-code-my-workflow
mkdir -p ~/.claude/skills
cp -r /tmp/claude-code-my-workflow/.claude/skills/interview-me ~/.claude/skills/interview-me
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

Research Interview

Conduct a structured interview to help formalize a research idea into a concrete specification.

Input: $ARGUMENTS — a brief topic description or "start fresh" for an open-ended exploration.

How This Works

This is a conversational skill. Instead of producing a report immediately, you conduct an interview by asking questions one at a time, probing deeper based on answers, and building toward a structured research specification.

Do NOT use AskUserQuestion. Ask questions directly in your text responses, one or two at a time. Wait for the user to respond before continuing.

Interview Structure

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?"
  • After the user answers, optionally ask: "Do you have a sense of what kind of paper this would be — reduced-form / structural / theory+empirics / descriptive / formal-theory / survey-experiment / unsure?" (See .claude/agents/methods-referee.md for the type definitions and .claude/references/discipline-cards.md for field-default frequencies.) Record the answer in the saved spec under the Paper type: header field; "unsure" is fine and is recorded as Paper type: unsure.

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:

# Research Specification: [Title]

**Date:** [YYYY-MM-DD]
**Researcher:** [from conversation context]
**Paper type:** [reduced-form | structural | theory+empirics | descriptive | formal-theory | survey-experiment | unsure]

## Research Question

[Clear, specific question in one sentence]

## Motivation

[2-3 paragraphs: why this matters, theoretical context, policy relevance]

## Hypothesis

[Testable prediction with expected direction]

## Empirical Strategy

- **Method:** [e.g., regression discontinuity around an eligibility cutoff]
- **Treatment:** [What varies]
- **Control:** [Comparison group]
- **Key identifying assumption:** [What must hold]
- **Robustness checks:** [Placebo tests, bandwidth sensitivity, etc.]

## Data

- **Primary dataset:** [Name, source, coverage]
- **Key variables:** [Treatment, outcome, controls]
- **Sample:** [Unit of observation, time period, N]

## Expected Results

[What the researcher expects to find and why]

## Contribution

[How this advances the literature — 2-3 sentences]

## Open Questions

[Issues raised during the interview that need further thought]

Save to: qualityreports/specs/researchspec[sanitizedtopic].md — the directory /grant-proposal, /data-management-plan, /power-analysis, and /preregister read from.

Post-Flight Verification (mandatory, CoVe — applies when the spec cites prior work)

The research spec's Motivation and Contribution sections typically reference prior papers by author + year. Those citations are hallucination-prone. Before saving the spec, run the Post-Flight Verification protocol from .claude/rules/post-flight-verification.md if the spec contains any citations.

Steps (skip if the spec cites zero papers)

  1. Extract claims: every paper-citation in the Motivation / Contribution sections ("Smith 2019 shows X"), any dataset-structure claims ("the CPS has field educ_attain"), any negative-literature assertions ("nobody has studied Y").
  2. Generate verification questions: specific, answerable questions per claim. "Does Smith (2019, JEL) Section 3 report finding X? Is the venue correct?"
  3. Spawn claim-verifier via the Agent tool with subagenttype=claim-verifier, in a fresh context — a named Agent call, not a conversation fork, which would inherit the draft. Hand it the claims + questions + source pointers (DOIs, arXiv links, mastersupporting_docs/ PDFs if the user provided any during the interview). Do NOT include the drafted spec.
  4. Reconcile: PASS → attach green block to the spec. PARTIAL → mark unverifiable citations with uncertainty flags. FAIL → rewrite the affected paragraph using the verifier's evidence before saving the spec.

Skip conditions

  • Spec contains zero paper citations (pure-methodology specs with no lit references).
  • --no-verify flag.
  • The user explicitly said during the interview "I'll verify the literature myself."

Decision records (when tradeoffs surface)

If during the interview the researcher explicitly chose among alternatives — identification strategy (DiD vs IV vs RDD), data source (admin vs survey), outcome measure, sample scope, etc. — also write an ADR-style decision record for each choice. Use templates/decision-record.md and save to qualityreports/decisions/YYYY-MM-DD[short-topic].md. Required fields: Status / Problem / Options considered / Decision + rationale / Consequences / Rejected alternatives.

Skip the ADR if the interview produced a single uncontested direction — ADRs are for decisions with live alternatives, not for announcing the default path.

Interview Style

  • Be curious, not prescriptive. Your job is to draw out the researcher's thinking, not impose your own ideas.
  • Probe weak spots gently. If the identification strategy sounds fragile, 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 researcher has a clear vision after 4-5 exchanges, move to the specification. Don't over-interview.

More skills from pedrohcgs/claude-code-my-workflow

  • Aadjudicate-reviewTurn an incoming set of findings — from an AI reviewer, a referee report, a code review, a linter, or a second model — into verified fixes, without letting a confident misread damage correct work. Every finding is a CANDIDATE until checked against the actual source. Use whenever you receive review comments, audit findings, or a critique you did not write yourself, especially when the reviewer is a model or when the volume is too large to check by feel.
  • Aaudit-reproducibilityEnforce the replication-protocol.md rule by cross-checking numeric claims in a manuscript against the actual R / Stata / Python outputs. Report PASS/FAIL per claim against tolerance thresholds. Use before submission and before releasing a replication package.
  • Ablast-radiusBefore and after changing anything shared — a function's return value, a signature, a schema, a label set, a config default, a constant, a file format — find every consumer and actually run them. Catches the change that looks purely additive but silently breaks a contract in a file you never opened. Use when editing shared code, adding a field/column/return element, renaming, changing units or defaults, or touching a pipeline that produces reported numbers.
  • Acapture-environmentSnapshot the computational environment for a replication package — detects the analysis stack (R / Stata / Python) and emits the right lockfiles (renv.lock + sessionInfo.txt, requirements.txt / environment.yml / uv.lock, Stata version + ado package list), records seeds and RNG kind, optionally writes a pinning Dockerfile, and produces a paste-ready "Computational requirements" block. Use when user says "capture the environment", "snapshot my dependencies", "pin the versions", "make a renv.lock / requirements.txt", "make this byte-reproducible", or before releasing a replication package to openICPSR / the AEA Data Editor.
  • AchallengeStress-test a finding against the choices you did not make. Enumerates the discrete forks a competent analyst could have taken (measure definition, sample filter, control set, clustering level, weighting, functional form), runs the specification grid, and reports the distribution rather than a point estimate — then attacks the identifying assumption with named, computable sensitivity statistics. Use when the user says "is this robust", "challenge this result", "specification curve", "multiverse", "how sensitive is this", "what if I'd used a different measure", "stress-test my estimate", or before a result becomes a headline claim. NOT a reviewer of prose or code — it challenges the CLAIM.
  • AcheckpointSave a structured state snapshot before stopping or handing off. Captures the active plan, recent decisions, file pointers (with line numbers), open questions, and the next 1–3 actions into a checkpoint file under `quality_reports/checkpoints/`. Optionally proposes `[LEARN]` entries to add to MEMORY.md. Use when user says "checkpoint", "save state", "snapshot before I stop", "where am I", "wrap up the session for handoff", or before a long break / model switch / collaborator handoff. Companion to (NOT replacement for) the narrative session-log workflow.
  • Acoauthor-briefGenerate a co-author / collaborator handoff brief for a multi-author, multi-machine project — summarizing what changed since the last brief (git delta), the current state of each artifact (manuscript, analysis, slides), open questions, how to reproduce locally, and any restricted-data access steps. Use when user says "coauthor brief", "handoff brief", "bring my coauthor up to speed", "what changed since last week", "onboard a collaborator", "write a handoff for [name]", or before sending a co-author the repo. NOT a commit or a checkpoint — it is the cross-machine, cross-person summary `meta-governance.md` only partially covers.
  • AcommitCommit the current work — runs the quality, consistency and passport gates, branches off main if needed, stages specific files, and writes a commit whose subject states what is now true. Pushes and opens a pull request only with --pr or when the user asks; never merges — a merge happens only when the user explicitly says to merge. Use ONLY on explicit commit intent — user says "commit", "let's commit this", "open a PR", or prefixes with `/commit`. Do NOT auto-invoke on vague end-of-task phrases ("we're done", "wrap up") — those require explicit confirmation first. Never force-pushes or skips hooks.
  • Acompile-latexCompile a Beamer LaTeX slide deck with XeLaTeX (3 passes + bibtex). Use when user says "compile", "build the slides", "rebuild the PDF", "run latex", "render the tex", or asks why a `.tex` file isn't producing a PDF. Operates on `Slides/*.tex`.
  • Acompress-sessionDistill the current conversation into a structured note (decisions made, open questions, file pointers with line numbers, next 1–3 actions) and save to `quality_reports/session_logs/` before auto-compression. Differs from `/checkpoint` (explicit stop-point snapshot) and from auto-compaction (which truncates rather than distills). Use when context is approaching auto-compact threshold, when a long pipeline has accumulated many decisions, or when the user says "compress", "distil this session", "before we hit auto-compact", "structured handoff before context resets".
  • Acontext-statusShow current context status and session health. Use to check how much context has been used, whether auto-compact is approaching, and what state will be preserved.
  • Acreate-lectureCreate a new Beamer lecture `.tex` from source papers and materials, with notation consistency checks and the project's preamble wired in. Use when user says "create a lecture on X", "new lecture from these papers", "start a deck on topic Y", "scaffold a new Beamer file", "build me a lecture from these PDFs". Scaffolds the full deck — NOT for compiling existing `.tex` (use `/compile-latex`).

All agent skills → · MCP servers