A classic "so close, yet so far" AI experience. Here is the scenario:
You spend a long time giving the AI every detail it needs, but it still misses the mark. You end up spending more time fixing its mistakes than you would have spent doing the work yourself. Also, the result are not consistent with every new prompt for smaller task it perform well but fails in complex task.
And you can't even blame the AI. You gave it everything at once and expected a magic.
The Real Problem: One Big Prompt Is a Trap
When you dump a giant prompt at AI, you feel like you've communicated well. You've written paragraphs. You've attached files. You've been thorough.
But here's what's actually happening: your prompt has gaps. It always does. You don't know what you don't know. The AI fills those gaps — silently, confidently, and often incorrectly. It doesn't stop and ask. It just builds.
And you won't find out until the end.
That's the black-box problem. You get back something that almost matches what you imagined. Then you spend the next hour in refactor mode, wondering where it went wrong.
A Better Way: Let AI Question You First
What if instead of giving AI everything upfront, you let it ask you the right questions first?
That's exactly what the Grill Me skill does.
Here's how it works:
You tell the AI what you want — in a short line or two. No essays, no spec docs.
The AI starts questioning you. One question at a time. Sharp, targeted questions that expose the gaps in your thinking.
For each question, it gives you a recommended answer with its reasoning — you just confirm, correct, or redirect.
If the answer can be found by reading your codebase, it reads the codebase instead of bothering you.
When every branch is resolved, you get a clean Decision Summary — and you can say: "Implement."
No surprises. No refactoring. No "oh I didn't realize it would do that."
What It Actually Looks Like in Practice
Here's a real implementation session. Three Jira tickets needed implementing — a legacy compatibility layer for an NRP publish service. Instead of writing a long prompt, I just ran:
/grill-me "implement XYZ-10499, XYZ-10501, XYZ-10503"
The AI pulled up all three tickets, then explored the codebase before asking a single question. It came back with:
"Got the full picture. The codebase has no legacy-compat mode detection yet — that's the foundational piece all three tickets depend on.
Question 1: How will legacy-compat mode be detected?
My recommendation: An org level config flag is more reliable than a header because it doesn't depend on callers always sending it correctly. Though a header-based override on top for testing would be useful. Which approach are you taking — header, org config, or both?"*
Notice what happened there. I gave it three ticket links. It read them, explored the codebase, identified a missing foundational piece I hadn't even mentioned, and then asked one sharp question with a recommended answer.
I responded in one line: xyz-legacy request header will be added by the intermediate service for all legacy calls automatically.
The AI confirmed and moved to Question 2 — where to read and store the header — and again it had already looked at the codebase and suggested the exact right place, with code references.
Question 2: Where should the xyx-legacy header be read and stored on the request context?
Looking at the codebase, there are two existing patterns for request-level data propagation:
. . .
My recommendation: read xyx-legacy in abc.ts and store it as something like var.isLegacy= true/false, so all downstream pipes and services can branch on it without re-reading the header repeatedly.
Is that the right place, or do you have a different layer in mind (e.g., a dedicated middleware, or reading it directly in each pipe)?
Total 09 questions in, every design decision was locked in. No ambiguity. The overall session ran for 15mins. But I ended up with confidence. Overall task completion time was 45mins. Which includes below mentiond skills execution, which we will see in later post.
Then I typed /to-prd and it generated a full PRD.
Then /to-issues and it created vertical implementation slices.
Then create a pr — and a pull request was live on GitHub.
From Jira tickets to open PR, with zero rework.
What Makes It Different
A few things Grill Me does that a plain prompt never will:
It reads your codebase before asking. If the answer already exists in your code, it won't ask you to re-explain it. In that session, it checked abc.ts, pqrs.pipe.ts, xyz.service.ts — and tailored every question to how your project actually works, not how a generic project would.
It gives a recommendation first. You're not staring at an open-ended question wondering what the right answer even is. It says "here's what I'd do and why" — you just react. This is way faster than thinking from scratch.
It catches things you missed. In that same session, the AI caught that the codebase had zero legacy-compat detection — before even getting to the actual ticket requirements. That's the kind of gap that bites you mid-implementation.
It builds a shared record. By the end, the Decision Summary is the ground truth. No more "wait, what did we decide about the depth override?" It's all written down.
When to Use It
The best moments to reach for Grill Me:
Before writing a PRD or TRD
Before asking AI to implement a feature
Before committing to a data modelling or API implementation
When several design choices depend on each other
When you want the AI to push back instead of just agree
If you're about to write a long prompt — stop. Write two lines about what you want. Then type /grill-me. The questions alone will surface things about your own idea that you hadn't fully thought through.
Top comments (0)