How to Use grill-me Skill for Better Project Planning

Mar 31, 2026

I spent three days building a feature, only to realize halfway through that I had made a fundamental assumption that was completely wrong. The API I was integrating didn’t work the way I thought it did, and now I had to tear apart everything I built.

Sound familiar? We’ve all been there. We jump into implementation with what feels like a solid plan, only to discover later that we missed something obvious—something a few probing questions would have uncovered immediately.

That’s when I discovered the grill-me skill.

What Went Wrong

Looking back at that failed feature, I realized my planning process had several fatal flaws:

I jumped to implementation too early — I started coding before I understood the full scope
I assumed shared understanding — The requirements doc said “user authentication,” but I never clarified what that actually meant
I skipped edge cases — What happens when the user’s session expires mid-operation?
I ignored dependencies — The auth service I planned to use had rate limits I didn’t account for
I accepted vague requirements — “Make it secure” isn’t a requirement; it’s a wish

Each of these could have been caught by asking the right questions upfront.

Enter grill-me

The grill-me skill is deceptively simple. It’s literally one paragraph long. Here’s the entire skill:

Before I do anything else, I'm going to interview you about your plan
to make sure I understand it completely. I'll ask one question at
a time, and after you answer, I'll tell you what I would recommend.
We'll keep going until you tell me to stop or we've covered everything.
What's the first thing you'd like to plan?

That’s it. That’s the whole thing.

But here’s what happens when you use it: Claude asks you one question. You answer. Claude gives its recommendation. Then it asks another question. And another. And another.

Sometimes it goes 40-50 questions deep.

And by the end, something magical happens—you actually know what you’re building.

Why Interrogation Works

Here’s what a typical planning session looks like in my head:

Idea → Code → Problems → Rework → More Code → More Problems → ...

And here’s what it looks like after:

Idea → Questions → Clarity → Code → Done

The difference isn’t the code—it’s the clarity. When I start coding after being grilled, I know:

Every edge case and how to handle it
Every dependency and its constraints
Every decision and why I made it
Every assumption and whether it’s valid

A Real Session

Let me show you what happened when I used grill-me to plan an authentication system:

Claude: What type of authentication are you building—session-based or token-based?

Me: Token-based, using JWTs.

Claude: I’d recommend considering the security implications carefully. JWTs can’t be easily revoked. Have you considered what happens when a user logs out or changes their password?

Me: Oh… I hadn’t thought about that. I guess I need a revocation mechanism?

Claude: That adds complexity. Options include short-lived tokens with refresh tokens, a token blacklist, or keeping session state server-side. Which approach fits your use case?

This continued for another 35 questions. By question 20, I realized my original plan had a fundamental flaw. By question 40, I had a completely different—and much better—architecture.

The Decision Tree Visualization

Here’s what happens visually:

                    Initial Idea
                         |
                    [Q1: Auth type?]
                    /              \
              Session            Token
                |                   |
           [Q2: Storage?]    [Q2: Revocation?]
           /    |    \          /     |     \
        Redis  DB    Mem    Blacklist Refresh Short
         |      |     |         |       |      |
       ...    ...   ...       ...     ...    ...

Each question splits into branches
Each branch leads to more questions
Until every leaf is a concrete decision

Without this grilling, I would have started coding at the top and discovered the bottom branches only after hitting bugs.

Installing the Skill

If you’re using Claude Desktop with the skills system, installation is straightforward:

cd ~/.claude/skills
git clone https://github.com/mattpoclock/skills.git temp-skills
cp temp-skills/grill-me/SKILL.md ./grill-me/
rm -rf temp-skills

Or if you’re starting fresh:

mkdir -p ~/.claude/skills/grill-me
cat > ~/.claude/skills/grill-me/SKILL.md << 'EOF'
---
description: Interrogates you about your plan before implementation
---

Before I do anything else, I'm going to interview you about your plan
to make sure I understand it completely. I'll ask one question at
a time, and after you answer, I'll tell you what I would recommend.
We'll keep going until you tell me to stop or we've covered everything.
What's the first thing you'd like to plan?
EOF

Common Mistakes I Made

After using this skill for several months, I’ve learned what NOT to do:

Rushing through questions — Early on, I tried to give quick answers to speed things up. This defeated the entire purpose. The value is in the friction, not the speed.

Accepting Claude’s recommendation without thought — Claude’s suggestions are starting points, not commands. The best sessions happen when I push back and debate.

Skipping to implementation — Halfway through one session, I thought “I know enough now” and tried to start coding. Claude politely asked if I wanted to continue the grilling. I should have said yes—I missed three important edge cases.

Using it only for big projects — I thought this was overkill for small features. I was wrong. A 20-minute grilling saves hours on even “simple” changes.

Not revisiting decisions — After being grilled, I sometimes forget why I made certain choices. Now I save the transcript as documentation.

When to Use grill-me

I’ve found this skill valuable for:

Feature planning — New functionality that touches multiple parts of the system
Architecture decisions — Choosing between approaches, libraries, or patterns
Bug investigation — Understanding root causes before fixing symptoms
Refactoring — Planning code reorganization without breaking things
Migration planning — Moving from one system to another

Basically, any time I’m about to write code that matters.

The Math Is Compelling

Let’s be concrete about the time investment:

Without grill-me:
  Planning: 30 minutes (often incomplete)
  Coding: 8 hours
  Debugging: 16 hours (finding and fixing issues)
  Rework: 8 hours (redoing things done wrong)
  Total: 32.5 hours

With grill-me:
  Planning: 1 hour (grilling session)
  Coding: 6 hours (clearer requirements = faster coding)
  Debugging: 4 hours (fewer issues to find)
  Rework: 0 hours (done right the first time)
  Total: 11 hours

Your numbers will vary, but the pattern holds: investment in planning pays dividends throughout the project.

A Warning About AI Assistance

Here’s something interesting I’ve noticed: the quality of AI coding assistance improves dramatically after a grill-me session.

Why? Because Claude has grilled me hard, it actually understands what I want. It has the full context—the decisions, the constraints, the edge cases. So when I ask it to write code, the output is way better.

It’s the same AI, but with completely different context.

The Bottom Line

Before you write any code, let Claude grill you.

The questions you can’t answer are the ones that would have caused problems later.

The assumptions you didn’t know you were making are the ones that would have led you astray.

The edge cases you hadn’t considered are the ones that would have produced bugs.

Twenty minutes of uncomfortable questions now saves days of painful rework later.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!