agentleFS
ggoosenggoosen/Digital-Workforce/.claude/skills/interview-me/SKILL.md

interview-me

Skill1 starsChanged 4 months agoMITView on GitHub

Before you start a task, this grills you to surface the blind spots and unknown-unknowns you can't see yourself — assumptions, missing context, the real question under the question — then hands the resulting primer to the right employee. Use when you're about to do anything important (research, a decision, a hard message) and want to think it through first. Voice triggers — "interview me", "grill me", "what am I missing", "ask me questions".

98 other projects use a version of this.

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

9 rules. 0 are common, 4 are distinctive, and 5 are very specific to this project.

  • 0

    Common

    Most of the 84 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 5

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Before asking anything, find out what's already known so you never waste a question on it (the GOLDEN RULE: pull from context/ first).

    line 45
  2. Very specific:

    Read, if present: context/profile.md (role, expertise, current priorities, pet peeves), context/company.md, context/decision-style.md.

    line 48
  3. Very specific:

    If the task touches a known person or a past decision, glance at the matching context/stakeholders/<name>.md or context/decisions/<file>.md.

    line 52
  4. Very specific:

    If context/ is empty or sparse, say so once and continue — don't block.

    line 54
  5. Distinctive:

    First, get the task: If the user didn't say what they're about to do, ask: *"What's the task you're about to take on?

    line 64
  6. Distinctive:

    Then grill — one focused question at a time: Never dump a numbered list and wait.

    line 81
  7. Distinctive:

    Know when to stop: Keep going until marginal value drops — when answers start repeating, when the user is clearly surprised by nothing new, …

    line 102
  8. Distinctive:

    When the interview is done, synthesize everything into a tight primer block — the lecturer's "primers / initial thoughts… your existing …

    line 114
  9. Very specific:

    Always tell the user, on screen, what you saved and where (e.g.

    line 166

“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

/interview-me — have AI interview you (the reusable primitive)

1. Purpose

This is Operating Principle 3 made operational: have AI interview you. The lecturer is blunt about why this matters — "the more senior you are, the more unknown unknowns you have." You don't know what you've left out; that's the whole problem. So before any complex task — research, a decision, a tricky message — you let the AI grill you until the blind spots are on the table. As the lecturer puts it: "What are the assumptions that you are making? What haven't I considered? What should I provide in forms of a context? This will often surface a lot of the blind spots before you even get the results that you're after."

This skill is a reusable primitive. The four employee skills call it as their opening move, and you can also run it standalone any time you feel a task is fuzzier than it should be. Its job is not to do the work — it's to make sure that when the work happens, your in-head context is already steering it. The output is a tight primer you can save and hand off.

Note: some tools have this built in — Codex shipped a dedicated command for it. This is the universal version that works wherever you run Claude Code.

2. Operating principles applied

See .claude/OPERATING_PRINCIPLES.md. This skill is Principle 3, and it leans on the others:

  • #3 Have AI interview you — the core. Grill until unknown-unknowns surface.
  • #1 Speak, don't type — interrogation works best out loud. Tell the user to dictate; reward messy, spiral answers.
  • #5 Be intentional about your intervention point — the primer this produces is the captured "primer / initial thoughts" the lecturer insists leaders capture up front, before AI does anything.
  • #4 Separate planning from execution — the lecturer says the interview "combines well with the planning step." This skill is pure thinking; it never jumps to the deliverable.

3. Step 1 — Load context

Before asking anything, find out what's already known so you never waste a question on it (the GOLDEN RULE: pull from context/ first).

  1. Read, if present: context/profile.md (role, expertise, current priorities, pet peeves), context/company.md, context/decision-style.md.
  2. Skim the most recent files in context/brain-dumps/ — the user may have already dumped context relevant to this task.
  3. If the task touches a known person or a past decision, glance at the matching context/stakeholders/<name>.md or context/decisions/<file>.md.
  4. If context/ is empty or sparse, say so once and continue — don't block. (Suggest /onboard for next time.)

Then tell the user, in two or three lines, what you already know so they don't repeat it. Example: "I've got that you run a 40-person software company, your top priority this quarter is the new product launch, and you hate hedging in writing. I'll skip those. Here's what I want to dig into."

4. Step 2 — Interview the user (this is the whole skill)

First, get the task. If the user didn't say what they're about to do, ask: "What's the task you're about to take on? Research, a decision, a message to someone, or something else — and what's the rough shape of it?" One sentence is enough to start; you'll excavate the rest.

Classify the task type so you ask the right questions:

  • Research → decision behind it, what they'd do with each possible answer.
  • Decision → options, reversibility, who's affected, what they secretly already believe.
  • Communication → audience, the reaction they want, what they're avoiding saying.
  • Operational / planning → the real deadline, constraints, definition of done.
  • Anything else → fall back to the universal five below.

Remind them to speak. "Dictate these — don't type. Ramble. The messy version is the valuable one."

Then grill — one focused question at a time. Never dump a numbered list and wait. Ask one sharp question, read the answer, and let it shape the next. Anchor every interview on the lecturer's universal five, tailored to the task:

  1. Assumptions — "What are you taking for granted here that might not be true?"
  2. Blind spots — "What haven't you considered? Where could this surprise you?"
  3. Missing context — "What's in your head that the AI would need to know to not give you generic output — the politics, the history, the look on someone's face?"
  4. Success — "What does a genuinely great outcome look like — and how is that different from a merely fine one?"
  5. The real question — "What's the actual question under the question? If you got a perfect answer to what you asked, would you still be stuck?"

Then probe the specifics the task type surfaced. Follow threads. When the user says something vague ("I want it to land well"), dig: "Land well with whom, and what would they do differently if it landed?" When they reveal a constraint, chase its edges. The senior the user, the more you push — they have more buried assumptions, not fewer.

Know when to stop. Keep going until marginal value drops — when answers start repeating, when the user is clearly surprised by nothing new, or when you've covered all five anchors plus the task-specific specifics. Then say: "I think I've got the blind spots that matter. One more or shall I write this up?" Don't pad. A good interview is 4–8 sharp exchanges, not an interrogation marathon.

Watch for the highest-value moment in any executive interview: the thing they almost didn't mention. When you hear "oh, and probably worth noting…" — slow down and mine it. That's usually the real context.

5. Step 3 — Produce the primer

When the interview is done, synthesize everything into a tight primer block — the lecturer's "primers / initial thoughts… your existing assumptions, premises, formed opinions." Keep it dense and skimmable, in the user's own framing, not corporate gloss:

PRIMER — <task in one line>            (<date>)

THE REAL QUESTION:  <the question under the question>
SUCCESS LOOKS LIKE: <concrete definition of a great outcome>

MY ASSUMPTIONS:     <bullets — what they're taking as given>
MY PREMISES/OPINIONS: <bullets — what they already believe / lean toward>
CONSTRAINTS:        <bullets — time, money, people, politics, reversibility>
CONTEXT AI WOULD MISS: <bullets — the undocumented in-head stuff>
BLIND SPOTS SURFACED: <bullets — what they hadn't considered before this>
OPEN QUESTIONS:     <anything still genuinely unknown>

Show it to the user and ask them to confirm or correct it. This is their thinking reflected back — make sure it's faithful.

6. Step 4 — Output & persist

Wiki Contract (.claude/WIKI.md). ORIENT before you grill: read context/index.md so you never ask for what the wiki already holds. The primer is reusable thinking — when you save it (below), append a BRAINDUMP: line to context/log.md (date "+%F %H:%M") noting the task, so the handoff and its resulting work are traceable in the ledger.

Offer two handoffs (use AskUserQuestion, options below). The GOLDEN RULE requires persisting reusable thinking so it's never re-elicited.

  • Save to context — write the primer to context/brain-dumps/<YYYY-MM-DD>-primer-<slug>.md (slug from the task). This makes it discoverable by future skills, including the employee skills' own context-load step. State the exact path you saved.
  • Hand to an employee — pass the primer straight into the relevant skill so the work starts already steered:
    • research → /research-analyst
    • decision / strategy → /strategic-advisor
    • message / writing → /comms-expert
    • planning / execution → /ops-powerhouse
  • Both / neither — let them choose. If neither, still show the primer in chat so nothing is lost.

AskUserQuestion — "What do you want to do with this primer?"

  • Save it — write to context/brain-dumps/ for reuse.
  • Hand it off — pass to the right employee skill and start the work now.
  • Both — save and hand off.
  • Just show me — keep it in chat only.

Always tell the user, on screen, what you saved and where (e.g. "Saved → context/brain-dumps/2026-05-31-primer-product-launch.md. Handing it to /strategic-advisor now.").

7. Pro tips

  • You are not here to be agreeable. A soft interview is a useless interview. Push back. If the user's assumption sounds shaky, name it: "You said X is a given — are you sure? What if it isn't?"
  • One question at a time, always. A wall of questions gets a wall of shallow answers. A single sharp question gets a real one.
  • Mine the throwaway line. The most valuable context is almost always the thing said in passing, half-apologetically. Chase it.
  • Tailor depth to seniority and stakes. A quick email needs three questions; a board decision or an irreversible hire needs a real grilling. More senior = more buried assumptions = dig harder.
  • Reflect, don't lead. The primer must be their thinking, sharpened — not your opinions dressed up as theirs. When in doubt, quote them back.
  • This combines with planning. As the lecturer notes, the interview pairs naturally with separating planning from execution — once the primer's done, the next step is often "now let's plan the approach" before any output.
  • Run it on yourself often. The whole point of Principle 3 is that you can't see your own blind spots. Reach for this skill before you feel you need it.

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.