agentleFS
flonatflonat/flonat-research/skills/interview-me/SKILL.md

interview-me

Skill150 starsChanged 10 days agoMITView on GitHub

Conduct an adaptive structured interview that elicits tacit knowledge, requirements, preferences, or decisions and summarizes them explicitly. Use when the needed information is in the user's head and cannot be recovered from project files. Not for adversarial oral examination; use $grill-me.

98 other projects use a version of this, 4 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use constraint-driven-development, idea-refine and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • MrCipherSmithSkill

    constraint-driven-development

    Use when a project needs a persistent, measurable quality bar — starting a project without documented standards, 'set up constraints', or when coverage/perf/a11y thresholds get re-debated per-PR. Produces CONSTRAINTS.md with enforceable numbers, ratchets, and a guard against silent weakening. NOT for throwaway prototypes or a one-off CI setup.

    Also in 16 projects that use this

  • LLl0k0laDSkill

    idea-refine

    Refine ideas through structured divergent and convergent thinking. Use "idea-refine" or "ideate" to trigger.

    Also in 42 projects that use this

  • LLl0k0laDSkill

    using-agent-skills

    Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked.

    Also in 32 projects that use this

  • HK-hubSkill

    observability-and-instrumentation

    Instruments code so production behavior is visible and diagnosable. Use when adding logging, metrics, tracing, or alerting. Use when shipping any feature that runs in production and you need evidence it works. Use when production issues are reported but you can't tell what happened from the available data.

    Also in 32 projects that use this

  • orenluxySkill

    implementation-notes

    Maintain an IMPLEMENTATION_NOTES.md decision log during any multi-step implementation session. Use this in EVERY session that involves writing or modifying code across more than one file, or any session expected to run longer than a few tool calls. Records decisions, deviations from plan, and open questions so nothing is silently guessed.

    Also in 3 projects that use this

  • HK-hubSkill

    deprecation-and-migration

    Manages deprecation and migration. Use when removing old systems, APIs, or features. Use when migrating users from one implementation to another. Use when deciding whether to maintain or sunset existing code.

    Also in 29 projects that use this

  • +6 more from LLl0k0laD

The file

We split this skill into the rules it gives an agent

7 rules. 0 are common, 5 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 84 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do NOT use the available structured-question mechanism: Ask questions directly in your text responses, one or two at a time.

    line 21
  2. Very specific:

    Before starting, read .context/profile.md and .context/projects/_index.md to understand the researcher's areas and active projects.

    line 23
  3. Distinctive:

    If the research is non-quantitative (conceptual, design science, qualitative), adjust: replace "Identification" with "Analytical Framework" …

    line 63
  4. Very specific:

    After the interview, populate .context/field-calibration.md from answers combined with Research Spec content.

    line 79
  5. Distinctive:

    If field-calibration already exists with content: ask the user whether to update specific sections or keep as-is.

    line 81
  6. Distinctive:

    Probe weak spots gently: If the identification strategy sounds fragile, ask "What would a sceptic say about...?" rather than "This won't …

    line 143
  7. Distinctive:

    Know when to stop: If the researcher has a clear vision after 4–5 exchanges, move to the specification.

    line 145

“Common” is measured: kept by at least 6 in 10 of the 84 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Research Interview

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

Input: $ARGUMENTS — a brief topic description or "start fresh" for 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 the available structured-question mechanism. Ask questions directly in your text responses, one or two at a time. Wait for the user to respond before continuing.

Before starting, read .context/profile.md and .context/projects/_index.md to understand the researcher's areas and active projects. If the topic relates to an existing project, read its context file too.


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?"

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?"

Adapting to the Research Area

the user's work spans multiple disciplines. Adapt the interview to the domain:

  • Human-AI collaboration / MCDM: Focus on decision architecture, experimental design, behavioural measures, and what "better" decisions look like.
  • Multi-agent systems: Focus on agent design, interaction protocols, equilibrium concepts, and simulation methodology.
  • Organisational behaviour: Focus on mechanisms, field vs. lab settings, mediators/moderators, and internal validity.
  • Carbon markets / environmental: Focus on policy variation, compliance data, market microstructure, and welfare implications.

If the research is non-quantitative (conceptual, design science, qualitative), adjust: replace "Identification" with "Analytical Framework" and "Data" with "Empirical/Evidence Strategy".


Phase 7: Field Calibration (optional, auto-triggered)

Auto-triggers when: the project has no .context/field-calibration.md, or it exists but still contains <placeholders>.

Skip when: the file already exists with populated content, unless the user explicitly asks to update it.

Ask 2–3 targeted questions:

  • "Which journals or conferences are you targeting? I can cross-reference venue rankings." (Use .context/resources/venue-rankings.md to validate and suggest alternatives.)
  • "Which seminal papers would a reviewer in this subfield expect to see cited?"
  • "What's the typical identification strategy in this subfield — and what do reviewers most often attack?"

After the interview, populate .context/field-calibration.md from answers combined with Research Spec content. Use the template at skills/init-project-research/templates/field-calibration.md.

If field-calibration already exists with content: ask the user whether to update specific sections or keep as-is.


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:** the user

## 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., DiD, experiment, simulation, case study]
- **Treatment/Manipulation:** [What varies]
- **Control/Comparison:** [Comparison group or baseline]
- **Key identifying assumption:** [What must hold]
- **Robustness checks:** [Pre-trends, placebo, alternative specifications]

## 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: the project root or docs/ if inside a research project, or present to the user for placement.

Also produces (if Phase 7 triggered): .context/field-calibration.md — the per-project domain profile that agents use to calibrate reviews.


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 sceptic 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.
  • Use British English throughout (the user's preference).

Cross-References

SkillWhen to use instead/alongside
devils-advocateAfter the spec is written — stress-test the idea
literatureTo find related work mentioned during the interview
init-project-researchTo scaffold a project once the spec is approved (seeds empty field-calibration)

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.