Big Idea

The argument in one line.

Pairing an AI grilling interview with a shared ubiquitous language document and architectural decision records produces faster, more aligned code generation because the AI stops re-explaining domain concepts and starts using the same terminology as the codebase.

Who This Is For

Read if. Skip if.

READ IF YOU ARE…

You're a backend engineer working in a domain-driven design codebase who wants to accelerate feature design by building shared vocabulary with an LLM before coding.
A technical lead iterating on a Claude skill or prompt who's already familiar with /grill-me and wants to see how domain documentation improves the interview loop.
You're designing a complex entity in an existing system and struggle with the agent asking redundant questions about your domain's jargon and conventions.

SKIP IF…

You're building in a domain without established jargon or architectural decision records — this approach assumes you have docs worth feeding the LLM.
You've never used /grill-me or similar relentless-interview prompts — you'll miss the specific pain points that motivated the replacement.

TL;DR

The full version, fast.

Grilling AI with relentless interview questions works, but it breaks down inside a real codebase because you waste tokens re-explaining domain jargon every session. The fix is borrowed from domain-driven design: maintain a context.md file that defines the shared vocabulary your code, your team, and your domain experts all use, plus architectural decision records for non-obvious, hard-to-reverse choices. The grilling skill reads these docs first, then challenges fuzzy language against the glossary and updates it as you talk. Document the non-obvious stuff before implementing, sharpen terminology until one word means exactly one thing, and the AI replies more concisely, thinks in your vocabulary, and produces code whose variable and file names already match how you speak.

Members feature

Chat with this breakdown.

Modern Creator members can chat with any breakdown — ask for the hook, quote a framework, find the exact transcript moment. Unlocks at T2: refer 3 friends + add your own API key.

Create a free account →

Chapters

Where the time goes.

00:00 – 00:47

01 · The /grill-me backstory

Matt explains the four sentences behind /grill-me, shows community praise, teases that he has replaced it.

00:47 – 03:00

02 · What goes wrong with /grill-me

Opens a live session, pastes a prompt for a new pitch entity, explains the core problem: re-explaining domain jargon like standalone video every single session.

03:00 – 05:40

03 · Ubiquitous language and the new skill

Introduces DDD concept from Eric Evans blue book. Shows the /grill-with-docs SKILL.md on GitHub -- same grilling core plus domain-awareness sections.

05:40 – 09:20

04 · Live demo: grilling a pitch entity

Runs /grill-with-docs on the real codebase. AI reads CONTEXT.md, clarifies cardinality, resolves terminology collision, handles status semantics and nullability.

09:20 – 12:00

05 · CONTEXT.md updates live

Matt asks the AI to save agreed language. CONTEXT.md updated with Pitch, Pitch Status, Pitched and Unattached Standalone Video. Reflection on why language precision matters.

12:00 – 14:00

06 · The three benefits

Concise replies, tighter thinking traces, easier code navigation -- all downstream effects of shared language. DDD works with humans and AI alike.

14:00 – 15:16

07 · Is /grill-me dead? + CTA

/grill-me moves to productivity skills for non-engineering use. Rule: codebase = /grill-with-docs, no codebase = /grill-me. Newsletter CTA.

Atomic Insights

Lines worth screenshotting.

The grill-me skill interviews the developer relentlessly until reaching shared understanding, walking down each branch of the design tree and resolving decision dependencies one by one.
Grill-with-docs adds a ubiquitous language document and architecture decision records to the grill-me loop, so shared language persists across sessions rather than being re-negotiated each time.
Ubiquitous language from domain-driven design is a shared vocabulary that domain experts, developers, and the codebase all use — when these three are aligned, communication becomes effortless.
Non-obvious domain terms like 'standalone video' cost significant context window tokens to re-explain every session; documenting them once in a ubiquitous-language.md eliminates that recurring cost.
After four or five sessions with grill-with-docs, the agent begins completing sentences that match your mental model before you finish forming them — that is the compounding payoff.
The thinest useful documentation layer is not a full spec but a glossary of non-obvious terms paired with the key architectural decisions already made.
A bounded context in DDD is a part of the application in which a single shared language is spoken — large monorepos should map multiple bounded contexts rather than forcing one universal glossary.
Matt Pocock's most influential four sentences — the grill-me skill — demonstrate that a tiny, well-designed prompt can have more impact than an elaborate framework.
The compounding value of a ubiquitous language document increases with every session — early sessions build it, later sessions benefit from it without any additional explanation cost.
Replacing a viral skill with a better one requires admitting the original had gaps — Matt Pocock's willingness to do this publicly is itself a teaching about continuous improvement.
AI agents that share your domain language can cross-reference new code against existing concepts, catching terminology drift before it creates inconsistency in the codebase.
Architecture decision records capture the why behind past choices, preventing the agent from undoing decisions that were made deliberately rather than by accident.

Takeaway

Steal the CONTEXT.md pattern.

grill-with-docs playbook

Shared language is not bike-shedding -- it is the multiplier that makes every AI session faster, tighter, and less repetitive.

Create a CONTEXT.md at your repo root -- one definition per domain term, with _Avoid_ aliases for confusables. Start it during your first grilling session.
Use /grill-with-docs (or build an equivalent) that reads CONTEXT.md before starting -- never let the AI start cold on domain terms.
Write an ADR only when the decision is hard to reverse, surprising without context, AND the result of a real trade-off. Most decisions do not qualify.
Let the AI propose canonical terms mid-session -- accept or push back, then lock them into CONTEXT.md before ending.
The language you agree on becomes your variable names, file names, and UI labels. Getting it right upfront is leverage, not perfectionism.
Keep /grill-me for non-engineering uses: brainstorming, writing, life decisions -- anything without a codebase.
Expect compounding returns: four or five sessions in, the AI anticipates your domain model and you need far fewer words to drive it.

Glossary

Terms worth knowing.

Skill (Claude Code): A reusable prompt or instruction set you can invoke inside Claude Code, often by a slash command, to make the AI behave a specific way for a recurring task.
/grill-me: A skill that makes the AI interview you relentlessly about an idea, walking through each branch of the decision tree and resolving ambiguities one by one until you reach a shared understanding.
/grill-with-docs: A successor skill that runs the same relentless interview as grill-me but also reads and updates a shared-language document and architectural decision records as the conversation unfolds.
LLM: Large language model — the underlying AI system, such as the one powering Claude, that generates text responses from prompts.
Agent: An AI process that can take actions on your behalf, such as reading code, asking questions, and editing files, rather than just answering a single prompt.
Entity: A distinct object your application tracks in its database, like a course, lesson, or video, usually with its own table and lifecycle.
Pitch (in this app): The packaging concept for a video — its title, description, and framing — created and evaluated before any footage is produced, so the best ideas become actual videos.
Standalone video: Within this codebase, a video that is not attached to a lesson or course. It is stored as a video record whose lesson reference is null.
Term of art: A word or phrase with a specific meaning inside a particular field or project that differs from, or sharpens, its everyday meaning.
Ubiquitous language: A shared vocabulary used consistently by developers, domain experts, and the code itself so that everyone refers to the same concepts using the same words.
Domain-driven design (DDD): A software design approach, introduced by Eric Evans, that organizes code around the real-world business domain and the language used to describe it.
Domain expert: Someone who deeply understands the problem the software is solving but does not necessarily know how it is built.
Bounded context: A defined section of a system within which a particular shared language and model apply consistently. Different bounded contexts can use the same word to mean different things.
Context map: A high-level document that names the bounded contexts in a large codebase and describes how they relate to each other.
Monorepo: A single repository that holds the source code for many applications or packages instead of splitting them into separate repositories.
context.md: A markdown file kept in the repo that captures the project's ubiquitous language — the agreed definitions of entities, statuses, and terms the code and team use.
CLAUDE.md: A markdown file Claude Code automatically reads on startup that gives the AI persistent instructions and context about a specific project or user.
Glossary (in context.md): The section of the shared-language document that lists each defined term so the AI and team can check usage against an authoritative list.
Architectural decision record (ADR): A short markdown file documenting a single non-obvious technical decision, why it was made, and what trade-offs it carries, so future readers understand choices that are hard to reverse.
Cardinality: The numeric relationship between two entities, such as one-to-one or one-to-many, describing how many records on one side can link to records on the other.

Resources Mentioned

Things they pointed at.

03:30bookDomain-Driven Design by Eric Evans

09:20toolWhisper Flow (dictation tool)

14:10productAI Skills for Real Engineers newsletter

12:30linkmattpocock/skills GitHub repo ↗

Quotables

Lines you could clip.

08:15

“This might just feel like bike shedding to you, but this is going to affect every part of the code that's generated. All variable names or file names are gonna be based on these context.md documents.”

Sharp defense of language precision -- counterintuitive to most devs, immediately relatable→ TikTok hook↗ Tweet quote

07:25

“It magically aligned with the thoughts I had before the words came out of their brain.”

User testimonial -- vivid description of AI alignment feeling→ IG reel cold open↗ Tweet quote

12:18

“The same techniques that work with humans also, it turns out, work with AI.”

Clean thesis, no setup needed→ newsletter pull-quote↗ Tweet quote

12:50

“Did its creator come along and stab it in the back? Absolutely not.”

Self-aware humor about killing his own viral tool→ TikTok hook↗ Tweet quote

The Script

Word for word.

analogystory

00:00A few months ago, I wrote a few sentences about four sentences that have turned out to be the most influential four sentences I've ever written.

00:09I packaged these four sentences up into the grill me skill, which is a skill that you can use to get the LLM to interview you relentlessly. It interviews you until you reach a shared understanding, walking down each branch of the design tree, resolving dependencies between decisions one by one.

00:24I know this skill is influential because every single day I receive about five messages of people saying they've tried it and they love it. This skill is an absolute game changer. What are your favorite skills?

00:34Grill me is great. I'm working on a project. Blah blah blah.

00:37The grill me skill asks me about ambiguities. Fantastic. Grill me skill is goated.

00:42At first, I felt like it slowed me down with all the questions. But after using it a bit, I honestly think it might save time. You just one shot everything after you've kind of gathered all the context.

00:51And you tested the skill called Grill Me and blah blah blah blah blah. It's wonderful. Wonderful.

00:55Wonderful. Wonderful. And after all that praise, you might think, well, you should probably stick with that skill, shouldn't you?

01:00That skill sounds pretty good. And it turns out, I've actually built a better one. I'm never very happy when I'm resting on my laurels.

01:07I always feel like there's improvements to be made at every single part of my process. And now, grill me has been replaced with a new skill. Let's open up a session so that I can explain a little bit more about where grill me goes wrong.

01:19I'm gonna paste in a prompt that I've already added here. And this prompt is an idea for a new feature. I've just dictated this out so you just sort of be spared the details of it.

01:28But essentially, I want to create a new entity in my database and a new entity that my app is going to deal with. Currently, this application deals in courses, deals in lessons, deals in videos, and sections and a few other things.

01:41And I want to add a concept of pitches. There's this kind of mister beast style axiom where you should be thinking about the packaging for your video before you actually work out what's going in the video. And that's what a pitch is in this kind of setup.

01:55A pitch is really just the packaging for the video, the title, the description, how I'm gonna frame it to people, and I create a bunch of these pitches and then pick the best ones and then turn those into videos. Now what you notice here is as I'm communicating with the agent, we're really focusing on language. Right?

02:10We're really focusing on what is a pitch. I just had to communicate that to you so that you could follow along, and the agent will need to extract that information from me too. But there's also some extra jargon in here that the agent doesn't know about yet.

02:23For instance, I'm talking about standalone videos. What does a standalone video mean? Oh, of course.

02:29It means a video that's not connected to a lesson or a course. Now, of course, I know that. That's kind of like a term of art for using this whole setup.

02:37But the agent doesn't know that yet. It doesn't have any concept of what that is. So during the grilling session, it's going to have to ask me what a standalone video is or try to figure it out from the code.

02:47So as I use grill me more and more and more, I would start to notice these times where the agent was being really really verbose, and I would have to remind it, no, there's already a term for that. And often though, there wasn't a term, or I was kind of thinking about things in a very verbose way myself, and that wasn't being challenged by the agent.

03:06Or we would actually land on some really good shared language, and then that wasn't documented anywhere. So I started to feel dissatisfied with Grillme because there was this piece missing from the puzzle, which is we were able to communicate about the code pretty effectively, but I would have to re explain all of the non obvious things about the code base and about the domain, the problem that we were solving before we could do anything productive.

03:30So I started to think to myself, what is the thinnest layer of documentation I could use to just give the AI a bit more of a leg up?

03:39So I came up with this skill, the ubiquitous language skill. Ubiquitous language is an idea that comes from domain driven design. This is the big blue book by Eric Evans that everyone goes on about.

03:49And what it does, it's it's essentially, you're trying to create a document which is the language that's used by the code base, that's used by developers, and that's used by domain experts.

04:01In other words, people that know about what you're building, but not how you're building it. All of those three groups should be using a shared language because that means that the domain expert can go, okay, there's something wrong with this particular section of the app. The developer knows what they're talking about and the code also reflects that.

04:17So what I would do is in the middle of a grilling session, when I noticed that we were needed to sharpen some language, I would use the ubiquitous language skill and correlates with, you know, ubiquitous language and try to create a ubiquitous language dot m d as we were going.

04:32So I had grill me and I had ubiquitous language and I was using them both at the same time and I realized wouldn't it be great if I just combine the two into a new skill? And here is that new skill. It is grill with docs.

04:45It has exactly the same text as grill me at the top here, but it has a couple of extra pieces. The first thing it has is the ability to look for a context dot m d file. This context dot m d file will have document all of the shared language that's inside that context.

05:01Now context is like super overloaded, so I'm sort of uncomfortable but maybe okay with it. It's essentially a bounded context in DDD is a part of the app in which you speak a shared language. So if you have a massive mono repo, you can have a context map here and have many different context inside.

05:20So that's how you would scale this to an enormous repo. But still, if you just have one pretty big repo where all the application is speaking the same language and the domain experts speak the same language, then you can just use a single context dot m d here. So it's instructed to look for this existing documentation to pull in this shared language.

05:38And then during the session, it's got some extra additions here to challenge, uh, language usage against the existing glossary, to sharpen fuzzy language, discuss concrete scenarios, cross reference with code, and update it as you go.

05:53So this essentially helps you really sharpen your language as you're using the grill with doc skill. And this pays off as you go. I was asking some folks for feedback on this and I got some really nice quotes here.

06:06So this guy used it for the whole of today. And at the start, it asked him to define a lot of terms. Some terms were hard to agree on and ones he would most definitely forget.

06:15But four or five sessions in, he started noticing that Claude was picking up the context during the grill session and it magically aligned with the thoughts I had before the words came out of their brain. So that's what you get out of this. By documenting the non obvious stuff, by agreeing on a shared language, you really can nail down and get a magical alignment between you and the AI where you just have to use far fewer words to communicate what you mean.

06:38For instance, here's the one that I have in my repo here. We essentially just have a little description about what the, you know, what the repo is.

06:46Then we have a course and a course repo, and we have all of the entities inside here. Course versions as well because I have multiple versions. And if we look for the one that we were looking at before which is standalone video, it is just down here.

06:59So we have an exact specification for what standalone video means now. Now the grill with doc skill knows to look for this, but I also add a context pointer into not inside that claw dot m d, but inside the local claw dot m d here.

07:14So we have just this domain docs, a single context layout, context dot m d at the repo root, and you see this extra little bit of documentation for more information about where this stuff is.

07:27One final thing that grill with docs does is that there are some things that sharpening the fuzzy language will help with, but there are some things that it won't. And so I wanted a layer that would explain all the non obvious decisions that weren't able to be captured inside context dot m d. And so for that, I've gone with an architectural decision record.

07:47These ADRs here are really, like, simple markdown files that sit in your repo that essentially documents all of the non obvious decisions. Only want to create an ADR when the decision is hard to reverse. Because if it's just like, oh, we use this library instead of this library and they're kind of interchangeable, then you can always just swap later.

08:06It would be surprising without context, and plenty of decisions in a repo are surprising without context, especially more complex ones, and the result of a real trade off. In other words, that this decision has consequences down the line.

08:20And I've got an ADR format inside here that the LLM uses when it creates these ADRs. So now we understand all the pieces.

08:27Let's go back up to here. Let's replace grill me with grill with docs. And let's actually start this grilling session to see it in action.

08:35Alright. So the first thing it has done is it said, oh, context dot m d is rich. Standalone video is already defined as a less a video with lesson ID equals null.

08:44And it says, before going further, I want to surface attention with the glossary. This is what you'll often find with Grille with Docs is that it really focuses on the language before you then actually go and talk about implementation details. It says there's cardinality between pitch and standalone video.

08:59It's asking whether one pitch holds many standalone videos or one pitch corresponds to exactly one standalone video. I think it might make sense to follow its recommendation here and go with, okay, we have one too many relationship here. So I'm just going to say correct.

09:14Very nice. Next up, it's noticing that there's a terminology collision with the standalone video. So it's saying that you have a standalone video that are either totally standalone or they can be related to pitches.

09:25So I think it's basically asking whether we keep standalone video as any pitched or unpitched lesson or we redefine it to mean specifically unpitched, unlessened video.

09:36Now the way we answer this question is going to influence everything afterwards. It's gonna influence whether standalone videos get their own section in the UI or whether we have standalone videos and videos with pitches kind of mixed in.

09:49Because the language that we're defining here is also the language that the user is going to be seeing on the page when they navigate around this. And I think I'm agreeing with it, actually. I was actually going into this thinking we would probably have a separate section for pitched videos.

10:01But I think, yes, I agree. It makes sense to keep pitching as just metadata on the standalone video itself.

10:08This, by the way, is Whisper Flow, what I'm using for dictation. It works okay. Uh, I'm not sure I recommend it but it's fine.

10:14It's now saying, okay, we need some status semantics here. So each pitch can be idle or scheduled or shipped here. I think I want just to allow I think I wanna allow just free form transitions.

10:28So I don't really care about this being automated. We can always layer on automation later, you know, like when you press, uh, send to YouTube or something, it goes into a new status. But for now, I'm okay just like toggling it myself.

10:40That's fine. It's now asking, can a pitch exist with zero videos? Absolutely, a pitch can exist with zero videos.

10:46The point here is that we're kind of generating pitches, ideas for videos, you know, and this is the mister beast thing.

10:52We're trying to get the packaging ready first. And this relationship, this language also goes into things as concrete as deletion cascades.

11:00So I think I'm going to say on delete restrict here.

11:05This is mostly because I just like restricted deletions. And mostly what I do is I tend to archive instead of delete when I actually do these.

11:13We're now getting into more implementation details here. So I think instead of just boring you with actually like implementing the grilling session here, I'm just gonna say, could you save what we have into context on d so far?

11:25If there's anything we haven't figured out, grill me about that before you make the adjustments. And let's see what it goes for here. And, okay, it has made a bunch of updates into context on d.

11:34Specifically, it's added a bunch of pitch information here. So we've got pitch, the actual entity itself. We've got pitch status, the status the pitch can be in.

11:42Pitched standalone video is a little bit awkward. I might want to grill it about that.

11:48And then unattached standalone video. That's also like it's basically saying standalone standalone video.

11:54Now bear in mind, I'm like I might seem like pretty, you know, anal retentive about this language. This might just feel like bike shedding to you, but this is going to affect every part of the code that's generated. All variable names or file names are gonna be based on these context dot m d documents here.

12:10And so getting this right is absolutely crucial for feeling aligned with the AI. Now, course, we don't want to just endlessly bike shed, so I'm gonna call this now. I'm gonna say that's good enough.

12:21Let's ship with this. We can always change and refactor to a new language later. So let's quickly talk about the benefits here, what you actually get from going through this ceremony.

12:29The first thing that you get is concise replies. The AI is able to use fewer tokens to speak to you because you have this shared language, it doesn't need to verbosely repeat everything or re describe everything. It just says, okay, stand alone videos are changing.

12:44We're, uh, needed to make a change to the pitches and how the pitches display. This concision is also reflected in its own thinking traces as well. Because of course, AI uses language to think to itself, and so it's able to be much more aligned with your intention and actually use fewer tokens when it's thinking.

13:00This is something I've observed and it feels pretty nice. And finally, because the planning documents, because the way that you're speaking with the AI is also aligned with the way the code looks as well, then you end up with easier to navigate code because it's able to just okay.

13:14I need to find all the information about pitches. Let me just search for it. And of course, this makes sense because these are all the same benefits described in domain driven design itself.

13:23So the same techniques that work with humans also, it turns out, work with AI. You're probably thinking though, is Grillme dead? Did I just kill Grillme?

13:31Did its creator come along and stab it in the back? Absolutely not.

13:34I think Grillme is an excellent excellent skill, but Grill with Docs is better when you have a code base. In my skills, have moved grill me into the productivity area here.

13:46So this is for general use cases, for use cases where you don't have a code base. I had someone, this is the most amazing story, who said that they were writing a eulogy for their mom and they use Grill Me to get the AI to grill them about their mom and surface all these amazing stories. And so Grill Me has incredible use cases outside of engineering.

14:06And of course, if you are really early on in a project, actually, really early on in a project, I'd still probably recommend using Grille with Docs because you just get so much more out of that shared language. And often at the start of a project is where you're trying to establish that shared language. So essentially, the rule is when you have a code base, use Grille with Docs.

14:24When you don't have a code base, use grill me. I update these skills super duper regularly and I'm often thinking new thoughts about the skills or even how best to use them without changing the skills themselves. So I keep everyone up to date on this with my AI skills for real engineers newsletter.

14:40This is just an addition to the, uh, already good newsletter that I have that just gives you a few extra skills updates or maybe one a week when they happen. I really freaking hate email spam and so I'm not gonna spam you. But this little page will help you basically keep up to date with all the skill change logs and have some nice extra additions here that you can just take a look at and learn how to use the skills better.

15:01Otherwise, thanks for watching and I'll see you in the next one. Thank you so much for following along. I really really appreciate it.

15:06And if you enjoy this skill, do let me know in the comments how you got on with it, what you noticed, and do raise an issue on the skills repo itself if you think there's something that I could improve.

The Hook

The bait, then the rug-pull.

Four sentences. That was all it took to make /grill-me one of the most-talked-about Claude Code skills in the community -- Matt Pocock was getting five messages a day from engineers raving about it. So naturally, he killed it and built something better.

Frameworks

Named ideas worth stealing.

03:30concept

Ubiquitous Language (DDD)

A shared vocabulary document aligning codebase, developers, and domain experts. When all three groups use the same terms, the AI needs zero re-explanation.

Steal forAny project where you re-explain domain terms to Claude -- create a CONTEXT.md at repo root and feed it into your grilling skill

05:10concept