The Prompting Problem Nobody Talks About
Most advice about prompting Claude assumes you know what you want. Be specific. Give context. Describe your output format. That's solid guidance, as far as it goes.
The problem is that the most valuable knowledge you have isn't the kind you can easily describe. It's buried in judgment calls you make automatically. In the shortcuts you've developed over years. In the decisions you make without thinking, because stopping to think about them would only slow you down.
That's tacit knowledge. And standard prompting does almost nothing with it.
You can describe your explicit process. You can't easily describe why you deviate from it, or what you're actually reading when you decide a piece of work is done. That gap between what you can articulate and what you actually know is where most AI productivity potential gets left behind.
What Nate Herk Actually Built
Nate Herk is a YouTube creator who builds what he calls AI Operating Systems, or AIOS. The concept is straightforward: instead of treating AI as a one-off tool you prompt ad hoc, you build integrated systems where skills, workflows, and automation cadence compound over time.
The individual pieces matter less than the architecture. An AIOS isn't a single prompt or a single tool. It's a system where each session starts from accumulated context, and each output refines the skill set feeding future sessions. You're not starting from zero every time.
The "Grill Me" prompt is one piece of that system. It does a single thing: it turns Claude into an interrogator.
You tell Claude you want to build a reusable skill for a specific domain. Maybe it's how you write cold outreach. Maybe it's how you audit a financial statement. Maybe it's your process for debugging a gnarly codebase. The prompt then forces Claude to extract that knowledge from you through a structured question-answer session, not through your own attempt to document it from scratch.
The distinction matters. Self-documentation requires you to know what's worth documenting. Most people don't know. They document what seems obvious and skip the parts that feel too automatic to mention. Those automatic parts are exactly what a new collaborator, human or AI, most needs to know.
Why Interrogation Works Better Than Description
Here's what happens when you try to write a skill yourself. You describe the obvious parts. The parts you can see clearly from the outside. You write something like "write professional emails" or "follow my coding style" and call it done.
What you leave out is everything interesting. The edge cases you've learned to handle differently. The tone adjustments you make based on who's reading. The things that would take a new hire six months to figure out, because you never wrote them down and couldn't articulate them if asked directly.
When Claude interrogates you, it surfaces those gaps by asking for them specifically. It asks about exceptions. It asks what you do when things go sideways. It asks you to compare two scenarios you'd handle differently and explain why. The questions are targeted in a way general documentation prompts aren't.
They're the kind of questions a sharp new colleague would ask if they were trying to actually learn your job, not just read the job description. And because Claude is asking rather than you writing, you're in explanation mode rather than summary mode. Explanation is where tacit knowledge tends to surface.
You answer. You explain. And in explaining, you externalize knowledge you didn't even know you had in structured form.
What the Conversation Actually Looks Like
The dynamic isn't complicated, but it's worth walking through step by step. You start by telling Claude the domain. Something like: "I want to build a skill for how I handle client feedback on design projects."
Claude doesn't just accept that framing and move on. It starts asking. What kind of feedback triggers immediate revisions versus what goes into a backlog? How do you handle feedback that contradicts a decision you made for a documented reason? Do you respond differently when feedback comes from the client's CEO versus their project coordinator? What's your threshold for pushing back, and what does pushing back actually look like in practice?
You answer each question. Some answers come quickly. Some surprise you a little, because you've never said the thing out loud before. Claude keeps going, probing edge cases, asking you to rank competing preferences, asking you to walk through a recent example in detail.
After enough exchanges, Claude synthesizes. It produces a structured document that captures your process, your decision logic, your tone preferences, and your edge-case handling in organized form. That document is your skill.
The session doesn't need to be long. Herk's approach isn't about exhaustive documentation. It's about hitting the parts that aren't obvious. Thirty minutes of interrogation often produces a more accurate and useful skill than hours of trying to write one from scratch.
Where the Output Lives and Why That Matters
The synthesized skill isn't meant to exist as a one-time conversation output you copy into a doc and never touch again. It gets stored in a persistent layer. In Claude Projects as a context document. In a CLAUDE.md file for Claude Code users. In whatever system-prompt layer your specific workflow supports.
This is where the productivity claim becomes concrete. Herk talks about 10x output on Claude Code projects, and the mechanism is specific: eliminating re-explanation overhead. Every new session starts cold by default. You either re-explain your context, or you accept that Claude is operating without it. Most people accept the impoverished starting state and compensate with more mid-session prompting.
A skill file changes the baseline. When your tacit knowledge is captured and stored, the session starts from where your knowledge actually lives. Claude doesn't need you to re-explain your taste, your process, your edge cases, or your known exceptions. It already has them in context before you type your first message.
The compounding effect is real and cumulative. You build one skill. It works reasonably well. You notice where outputs still miss. You refine the skill based on what's off. Over time, your AI context layer gets more accurate not because the model improved, but because your captured knowledge improved.
That's the actual operating system Herk is describing. Not a single prompt trick. An iterative system that gets better the more you use it.
The Broader Framework: Reverse Engineering What Works
Herk applies this same logic at a larger scale across the AIOS framework. In financial auditing, software development, and content creation workflows, the pattern holds: take something that worked once, formalize it into a reusable structure, then improve it iteratively through feedback loops and real outputs.
"Grill Me" is the extraction mechanism. Claude Code or Claude Projects is the storage layer. Iteration over actual outputs is the compounding mechanism. Each piece depends on the others working together.
What makes this different from just writing good documentation is the AI's role in the extraction step. Most people are bad at documenting their own process. Not from laziness, but because the most valuable parts are genuinely invisible to them. They've automated those judgments. They need a prompt structure that specifically targets what they can't see from inside their own expertise.
That's the gap "Grill Me" fills. It doesn't ask you to describe your process in the abstract. It asks you to explain specific decisions, specific tradeoffs, specific exceptions. That level of specificity is where tacit knowledge actually lives, and it's what makes the resulting skill useful rather than generic.
The technique works in any interface that supports system prompts or project-level context files. It doesn't require a specialized tool stack beyond Claude itself. There's no proprietary setup, no complex automation needed to get started.
Standard prompting tells Claude what you want in a given moment. "Grill Me" tells Claude what you know across all moments.
That gap is the one worth closing.