knowledge-interviewlisted

Extract knowledge that lives in someone's head and turn it into documentation by interviewing them — one question at a time — and then drafting the doc in the right structure for them. Use this whenever the user wants to document something, write up how a system/process/decision works, "get something out of my head", brain-dump a topic, onboard others, or says they have the knowledge but don't know how to structure it or fit it in a single prompt. Trigger on phrases like "interview me about X", "help me document X", "I need to write up how Y works", "write docs for Z", or any request where the user clearly holds the knowledge and the hard part is eliciting and organising it rather than researching it.
jdrydn/dotclaude · ★ 0 · Data & Documents · score 70

Install: claude install-skill jdrydn/dotclaude

# Knowledge Interview Turn tacit knowledge (what's in the user's head) into a clear document, by **interviewing them**, then **drafting the doc** in a structure that fits the material. The user has the knowledge. They usually don't know the best way to structure the doc, and they can't dump it all in one prompt — that's exactly why this skill exists. Do the structuring and the eliciting for them. ## The one rule that matters most **Ask one question at a time.** A single, focused question, then wait for the answer. Batching five questions feels efficient but wrecks the interview: the user answers the easy ones, skims the hard ones, and you lose the thread to follow up on the interesting bits. A real expert interviewer asks one thing, listens, and pulls the next question out of the answer. Do that. Resist the urge to dump a questionnaire. The exception is the very first framing step below, where two or three quick scoping questions up front save time. ## Workflow ### 1. Frame the session (fast) Establish three things, then move straight into the interview: - **Topic** — what are we documenting? - **Reader** — who reads this, and what should they be able to _do_ after reading it? ("A new engineer who needs to deploy this safely" produces a very different doc from "future me, six months from now, debugging an incident.") - **Doc type** — pick the shape that fits (see Document structures below). State your pick and why; don't ask permission. The reader answer usually