I stopped using /grill-me for coding. Here's what I use instead

생각 덩어리

가장 영향력 있는 네 문장 — Grill Me와 매일 다섯 통의 찬사

A 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. I 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.

I 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.

찬사 위에 머무르지 않는다 — 이미 더 나은 것을 만들었다

And after all that praise, you might think, well, you should probably stick with that skill, shouldn't you? ... And it turns out I've actually built a better one. I'm never very happy when I'm resting on my laurels. I always feel like there's improvements to be made at every single part of my process.

데모 — pitch라는 새 엔티티, Mr. Beast식 패키징 우선주의

There's this kind of Mr. 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.

A pitch is really just the packaging for the video, the title, the description, how I'm going to frame it to people, and I create a bunch of these pitches and then pick the best ones and then turn those into videos.

에이전트가 모르는 term of art — standalone video의 재설명 비용

I'm talking about stand-alone videos. What does a stand-alone video mean? Oh, of course, it 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 set up, but the agent doesn't know that yet.

Grill Me의 빠진 조각 — 좋은 공유 언어가 어디에도 기록되지 않는다

As I used 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. Or, we would actually land on some really good shared language and then that wasn't documented anywhere.

So, I started to feel dissatisfied with Grill me 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.

가장 얇은 문서화 레이어 — DDD에서 가져온 ubiquitous language

So, 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. So, 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.

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. In 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.

두 스킬의 합체 — Grill with Docs와 context.md

So, 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. It has exactly the same text as grill me at the top here, but it has a couple of extra pieces.

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 contexts inside. So, that's how you would scale this to an enormous repo.

It's instructed to look for this existing documentation to pull in this shared language, and then during the session it's got some extra additions here to challenge language usage against the existing glossary, to sharpen fuzzy language, discuss concrete scenarios, cross-reference with code, and update it as you go.

4~5세션 뒤의 마법 — 말이 나오기 전에 정렬된다

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. But 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 that brain.

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.

repo 안의 실물 — standalone video의 정확한 명세와 context pointer

So, we have an exact specification for what standalone video means now. Now, the Grill with Docs skill knows to look for this, but I also add a context pointer into, not inside that claw.md, but inside the local claw.md here.

세 번째 레이어 ADR — 언어 sharpening으로 잡히지 않는 결정들

I wanted a layer that would explain all the non-obvious decisions that weren't able to be captured inside context.md. And so for that, I've gone with an architectural decision record. These ADRs here are really like simple markdown files that sit in your repo that essentially document all of the non-obvious decisions.

You only want to create an ADR when the decision is hard to reverse because if it's just like oh we'll use this library instead of this library and they're kind of interchangeable, then you can always just swap later. It 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.

라이브 그릴링 — 구현 디테일보다 용어 충돌이 먼저

All right, so the first thing it has done is it said "Ooh, context.md is rich. Standalone video is already defined as ... a video with lesson ID equals null." And it says before going further, I want to surface attention with the glossary. This is what you'll often find with grill with docs is that it really focuses on the language before you then actually go and talk about implementation details.

Now the way we answer this question is going to influence everything afterwards. It's going to 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. Because 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.

언어가 스키마까지 — deletion cascade도 공유 언어의 연장

It's now asking, "Can a pitch exist with zero videos?" Absolutely, a pitch can exist with zero videos. The point here is that we're kind of generating pitches, ideas for videos, you know? This is the Mr. Beast thing. We're trying to get the packaging ready first.

And this relationship, this language also goes into things as concrete as deletion cascades. So, I think I'm going to say on delete restrict here. This is mostly because I just like restrictive deletions. And mostly what I do is I tend to archive instead of delete when I actually do these.

bike-shedding이 아니다 — 모든 변수명·파일명의 뿌리, 그리고 멈출 타이밍

Now, bear in mind, 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, all file names are going to be based on these context.md documents here. And so, getting this right is absolutely crucial for feeling aligned with the AI.

Now, of course, we don't want to just endlessly bike-shed. So, I'm going to call this now. I'm going to say that's good enough. Let's ship with this. We can always change and refactor to new language later.

세 가지 보상 — 간결한 응답·절약되는 사고 토큰·탐색 쉬운 코드

The AI is able to use fewer tokens to speak to you because you have this shared language and it doesn't need to verbosely repeat everything or re-describe everything.

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 thinking. This is something I've observed and it feels pretty nice.

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, I 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. So, the same techniques that work with humans also, it turns out, work with AI.

Grill Me는 죽지 않았다 — 코드베이스 유무로 갈리는 규칙

You're thinking though, is Grill me dead? Did I just kill Grill me? Did its creator come along and stab it in the back? Absolutely not. I think Grill me is an excellent excellent skill, but Grill with Docs is better when you 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 used 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.

If you are really early on in a project, actually really early on a project, I'd still probably recommend using Grill 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 Grill with Docs. When you don't have a code base, use Grill me.

(원본 말미 — 스킬 변경 로그를 전하는 'AI skills for real engineers' 뉴스레터 안내와 skills repo 이슈 제보 요청으로 마무리)