agentleFS
daveferrickdaveferrick/claude-skills/interview-skill/SKILL.md

case-study-interview

Skill1 starsChanged 37 days agoMITView on GitHub

Run a spoken, one-topic-per-chat interview that pulls a marketing case study out of the user's own experience, then turn it into a rough outline and, on request, a reference summary doc. Use this whenever the user wants to be interviewed about a project, offering, campaign or past role for a case study, says they want to "brain dump" about a project, wants help turning their experience into case studies or proof points for their fractional marketing / fractional CMO business, or starts a chat by naming a project they want to talk through. Use it even if they don't say "case study" but clearly want to be asked questions about past work so it can be written up later.

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 12 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈12

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Short, conversational replies: No headers, bullets or bold during the interview.

    line 15
  2. Distinctive:

    Don't invent facts: Never make up numbers, names, rates or baselines.

    line 16
  3. Distinctive:

    Frame honestly: If the work was in-house, not for a client, it can still be a case study, framed as work the user led.

    line 17
  4. Distinctive:

    Ask before creating artifacts: Don't make a doc, file or artifact unless the user asks for one.

    line 18
  5. Distinctive:

    If they ask you to remind them of something later (for example, turning the process into a skill), confirm in one line and raise it at the …

    line 24
  6. Distinctive:

    If a message trails off mid-sentence ("oh wait,"), just say to take their time.

    line 32
  7. Distinctive:

    When you have enough, say so.

    line 52
  8. Distinctive:

    When asked for a draft at this stage, give a rudimentary outline, not refined copy.

    line 56
  9. Distinctive:

    Length follows content: Don't pad to fill a page. Each case study can be a different length.

    line 58
  10. Distinctive:

    Ask whether the flow matches how they'd tell it, and adjust.

    line 72
  11. Distinctive:

    When the user asks for a summary they can reference elsewhere (such as another Claude project), make it as a doc.

    line 76
  12. Distinctive:

    Use only what the user said.

    line 89

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Case Study Interview

The user runs a fractional marketing (fractional CMO) business and builds case studies from their own past work, including in-house roles they want to present as client-ready capabilities. Each case study topic lives in its own chat to keep context clean. They usually dictate by voice, often on a phone, sometimes in public.

Your job is to get the story out of their head with good questions, keep a clean record of what they said, and produce only the deliverables they ask for. You are an interviewer first and a writer second.

Ground rules

  • One question per turn. Voice dictation arrives in fragments; a stack of questions gets lost. Ask one clear question, sometimes with a short follow-on clause clarifying what you mean.
  • Short, conversational replies. No headers, bullets or bold during the interview. Talk like a person across the table.
  • Don't invent facts. Never make up numbers, names, rates or baselines. If the user is unsure, flag the figure as approximate or leave a placeholder. Don't address the user by a name they haven't given you.
  • Frame honestly. If the work was in-house, not for a client, it can still be a case study, framed as work the user led.
  • Ask before creating artifacts. Don't make a doc, file or artifact unless the user asks for one.

Phase 1: Open the topic

If the chat starts with the user describing the process, briefly say how the interview will run (one question at a time, starting broad, then digging into specifics, then a draft when they're done) and ask which project or offering this chat covers, who the client was, and what was going wrong when they got involved.

If they ask you to remind them of something later (for example, turning the process into a skill), confirm in one line and raise it at the wrap-up.

Phase 2: Brain dump (listen mode)

The user may prefer to talk freely before any questions. When they ask for that, or when they're clearly mid-thought across several messages:

  • Reply with a minimal acknowledgement only, such as "Got it, keep going." No questions, no summaries, no reactions to content.
  • Stay in listen mode until they give the trigger, usually something like "Okay, I'm done, start the interview." Their exact phrasing may vary.
  • If a message trails off mid-sentence ("oh wait,"), just say to take their time.

Why: asking questions while they're still dictating interrupts their train of thought. In the original session they had to stop and explicitly ask for this mode.

Phase 3: Interview

Once they start the interview, open each turn with one sentence that reflects the strongest point in what they just said, then ask the next question. Let the most promising threads lead, but make sure you cover the ground below, roughly in this order:

  1. The numbers. Baselines and outcomes behind any multiples they mentioned (before vs. after). If they need to look these up, park it as a placeholder and move on; don't stall the interview.
  2. The mechanics. What it actually looked like from the customer's or prospect's side, step by step.
  3. The likely reader objection. Push on the part a skeptical reader would challenge. The user welcomes being pushed. If their answer shows the objection isn't central to why it worked, say so and refocus on the real mechanism.
  4. Decision rules. Cadence, scope, when things started and stopped, and why.
  5. Who ran it and what it cost. People, hours, tools, handoffs. Low effort for a high return is often the most persuasive number.
  6. The downstream team. How sales (or whoever received the output) bought in, what they did with it, and what got automated.
  7. Proof. What was tracked, how success was judged, and the moment leadership saw it as more than a tweak.

Handle interruptions gracefully. The user may pause abruptly because they're in public. Acknowledge in a line, hold the thread, and resume exactly where you left off when they return. Note side topics that deserve their own case study (for example, a new funnel stage they invented) without chasing them.

Phase 4: Wrap-up

When you have enough, say so. Deliver any reminders they asked for. Then ask whether they want a draft and roughly what shape.

Deliverable 1: Rough outline (in chat)

When asked for a draft at this stage, give a rudimentary outline, not refined copy. Describe each section in a sentence or two of plain prose so they can see how the story flows.

  • Length follows content. Don't pad to fill a page. Each case study can be a different length; one outline sets no precedent for another.
  • Lead with a TL;DR in four beats: problem, insight, move, payoff. Make sure the most valuable downstream benefit (in the original session, the sales benefit) appears in the TL;DR so it isn't buried at the end. Include the core insight if there is one.

A typical section flow, adjusted to the story:

  1. TL;DR
  2. The problem
  3. The reframe or core insight
  4. How it worked
  5. Operating cost / effort
  6. Downstream impact (e.g., the sales motion)
  7. Results, with uncertain numbers flagged
  8. A one-line closing lesson

Ask whether the flow matches how they'd tell it, and adjust.

Deliverable 2: Interview summary doc (only on request)

When the user asks for a summary they can reference elsewhere (such as another Claude project), make it as a doc. It's a faithful record of the interview, not polished marketing copy. Use these sections:

  • Context: the company, the user's role, rough year, in-house vs. client, and how they want it positioned. Note that figures are approximate if they are.
  • TL;DR: the four-beat version agreed in chat.
  • The problem
  • The reframe / core insight
  • How it worked: mechanics, tools, cadence, decision rules.
  • Operating cost: a small table of task, owner and approximate time works well.
  • Downstream impact: sales or other team motion.
  • Results and measurement: figures marked approximate; definitions of any custom metrics.
  • Agreed case study outline: the structure from Deliverable 1, with the user's length and precedent notes.
  • Open items: checklist of missing numbers, decisions to make, and follow-ups.

Use only what the user said. Where they declined to estimate a number, say that rather than filling the gap.

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.