Stop Your AI Agent From Agreeing With You: The /grill-me Skill

Your coding agent's worst habit isn't hallucinating APIs. It's saying "great idea!" and building the...

Your coding agent's worst habit isn't hallucinating APIs. It's saying "great idea!" and building the wrong thing at full speed. Here's a tiny skill that fixes it.

If you've spent any real time pair-programming with an AI agent in Cursor, Claude Code, or Windsurf, you've felt this exact moment of dread:

You describe a feature in two loose sentences. The agent replies with enthusiasm, invents five decisions you never made, and starts writing 250 lines of code. Twenty minutes later you realize it delivered something — just not the thing you actually needed. Now you're not reviewing code, you're archaeologically excavating the assumptions buried inside it.

The problem isn't that the model is dumb. The problem is that it's agreeable. It's optimized to be helpful, and "helpful" gets interpreted as "start building immediately." What you actually wanted was pushback.

That's the entire reason /grill-me exists — a small, sharp skill from Matt Pocock that turns your agent from a yes-man into an interrogator. This post walks through what it is, how to install it, a full worked session, where it fits in a larger planning workflow, and the pitfalls to watch for.

Heads up (2026): Matt has since moved his own default to domain-model and grill-with-docs for coding work. grill-me is still the cleanest introduction to the idea of adversarial planning, and it remains genuinely useful as a narrow pressure-test. I'll cover how they relate near the end.

The problem, in one screenshot

Here's the default behavior we're trying to kill. Vague prompt in, confident wall of assumptions out:

Look at what happened. You said "build a notifications feature… make it good." The agent decided — silently — that:

• notifications are email only
• they live in a new Postgres table
• delivery happens synchronously inside the request handler
• read-state is a single boolean
• there are no user preferences and no batching

Every one of those is a real architectural decision. Some are probably wrong for your app. And you didn't make any of them — the agent did, on your behalf, and then wrote code as if they were settled. This is the failure mode /grill-me targets: premature convergence. The agent collapses a tree of open questions into one arbitrary path before you've had a chance to think.

What /grill-me actually is

The skill is almost comically small. That's the point. Here's the entire thing:

---
name: grill-me
description: Interview the user relentlessly about a plan or design until
  reaching shared understanding, resolving each branch of the decision tree.
  Use when user wants to stress-test a plan, get grilled on their design,
  or mentions "grill me".
---

Interview me relentlessly about every aspect of this plan until we reach a
shared understanding. Walk down each branch of the design tree, resolving
dependencies between decisions one-by-one. For each question, provide your
recommended answer.

Ask the questions one at a time.

If a question can be answered by exploring the codebase, explore the codebase
instead.

There's no code, no MCP server, no tooling. It's a prompt — a behavioral contract you hand the agent. But notice how much design judgment is packed into those few lines. Four rules do all the work:

1. Interview relentlessly, resolving the decision tree. The agent is told to treat your plan as a graph of unresolved decisions, not a to-do list. Its job is to find the open branches and close them.

2. One question at a time. This is the rule that makes it usable. A lesser prompt would dump twenty questions in a numbered list and you'd freeze. Serializing the interview keeps your working memory free and lets each answer inform the next question.

3. Provide a recommended answer for every question. Crucial. The agent isn't allowed to just interrogate you into exhaustion — it has to take a position. That does two things: it keeps momentum (you can often just say "yes"), and it gives you something concrete to push against, which is far easier than answering an open-ended "what do you want?"

4. Resolve dependencies first, and read the code before asking. If choice B only matters after choice A is settled, the agent asks A first. And if the answer is already in your repository — "which queue library are we using?" — it's supposed to go look rather than make you recite your own codebase back to it.

Installing it

The skill lives in Matt Pocock's public skills repo. One command installs it globally:

npx skills add mattpocock/skills --skill=grill-me -y -g

• --skill=grill-me grabs just this skill rather than the whole pack.
• -g installs it globally, so it's available in every project.
• -y skips the confirmation prompts.

Source, if you want to read or fork it: mattpocock/skills/grill-me.

Once installed, it works anywhere your agent reads skills — Cursor, Claude Code, and other skill-aware tools. You invoke it by name (/grill-me) or just by asking the agent to "grill me on this plan."

If you'd rather not install anything to try the idea, you can paste the prompt body straight into a chat. The skill is just a reusable, named version of that same instruction — which is exactly why skills are worth adopting: the good prompt stops living in your head and starts living in your toolchain.

A full worked session

Let's replay the notifications feature — this time grilled. Same vague starting point, completely different trajectory.

You type:

/grill-me

I want to add a notifications feature. Users get notified when things
happen in the app.

Instead of a wall of code, you get one question with a recommendation attached:

Notice everything the agent is doing right in that single exchange:

• It labels where you are (Question 3 of ~7) so the interview feels bounded, not infinite.
• It asks about delivery model — and explains why now: this decision blocks the storage decision, so it has to come first.
• It commits to a recommendation (background queue) with actual reasoning, not a shrug.
• It checked the codebase first and found you already have a BullMQ worker wired up, so its recommendation is grounded in your real stack instead of a generic best practice.

Here's roughly how the whole interview plays out. Each line is one turn:

Q1  In-app only, or in-app + email + push?
    → Rec: in-app + email now, push behind a flag.   You: agree.

Q2  Should notifications persist, or fire-and-forget?
    → Rec: persist — users expect a notification center. You: agree.

Q3  Synchronous in the request, or background queue?
    → Rec: queue (found existing BullMQ worker).       You: agree.

Q4  Read-state: boolean is_read, or read_at timestamp?
    → Rec: boolean is simpler.
    You: push back — use read_at, we'll want "unread since" later.

Q5  Per-user notification preferences now, or later?
    → Rec: defer to v2.
    You: push back — legal wants opt-out from day one. Add it.

Q6  Digest/batching in v1?
    → Rec: no, ship per-event first.                   You: agree, log as v2.

Q7  Any events that must never be silenced (security alerts)?
    → Rec: yes, a non-optOutable "critical" category.  You: agree.

Two of those seven, you pushed back on. That's the whole return on investment. Q4 and Q5 are exactly the decisions that, left to the agent's defaults, would have shipped as a boolean and a missing opt-out — and surfaced as a painful migration and a compliance scramble weeks later. The interview dragged them into the open while they were still cheap to change.

When the tree is fully resolved, the agent summarizes the decisions and only then is ready to build:

From resolved plan to code

Because every decision is now explicit, the resulting code is built on choices instead of guesses. Compare the two notify implementations.

Before — the agent's silent assumptions, hard-coded:

// Written before a single question was asked.
export async function notify(userId: string, message: string) {
  await db.insert(notifications).values({ userId, message });
  await email.send(userId, message); // blocks the request on a flaky API
}

After — the same function, built on the seven resolved decisions:

type NotifyInput = {
  userId: string;
  category: "critical" | "social" | "billing";
  payload: Record<string, unknown>;
};

export async function notify(input: NotifyInput) {
  // Q5 + Q7: respect per-category opt-out, but never silence "critical".
  if (input.category !== "critical") {
    const prefs = await getPreferences(input.userId, input.category);
    if (!prefs.enabled) return;
  }

  // Q3: durable, non-blocking. The BullMQ worker drains the outbox.
  await outbox.enqueue({
    userId: input.userId,
    category: input.category,
    payload: input.payload,
    // Q4: read_at stays null until the user opens it.
    readAt: null,
  });
}

Every line traces back to a decision you made, annotated with the question that settled it. There's no throwaway code because the expensive thinking happened before implementation, not during code review. That's the actual deliverable of /grill-me: not the answers, but the fact that the answers are yours.

Where it fits in the bigger workflow

/grill-me isn't meant to stand alone. It's the front-of-funnel pressure test in a planning chain. The currently recommended sequence from AI Hero looks like this:

domain-model → to-prd → to-issues → tdd

• domain-model shapes the feature against your codebase's own language, your CONTEXT.md, and your architectural decision records. This is now the recommended default starting point.
• to-prd turns the resolved context into a product requirements doc.
• to-issues slices the PRD into vertical, shippable issues.
• tdd drives the implementation test-first.

So where does /grill-me sit? Use it when you have an idea, plan, or architecture direction that needs questioning but doesn't yet need the full domain-model treatment. Good moments:

• before writing a PRD
• before asking an agent to implement a feature
• before committing to a data model or API shape
• when several design choices depend on each other
• when you simply want the agent to push back instead of agree

Think of domain-model as the heavy, codebase-aware planning tool and grill-me as the lightweight interrogation you reach for when you just want to be challenged. They pair naturally: grill first to surface the open questions, then run domain-model to sharpen the survivors against your codebase's real vocabulary.

Pitfalls and how to handle them

It can over-interview trivial work. If you ask it to grill a one-line copy change, it'll dutifully generate questions that don't matter. Reserve it for decisions with real branching — data models, API shapes, delivery semantics — not for renaming a variable.

Recommendations can anchor you. Because every question ships with a recommended answer, it's tempting to reflexively say "yes." That's a feature for momentum and a trap for judgment. The value shows up on the questions where you disagree, so treat each recommendation as a claim to test, not a default to accept. If you agreed with all seven, you probably weren't reading closely.

"Explore the codebase instead" depends on access. The rule that the agent should inspect code rather than quiz you only works if it actually can see the repo. In a fresh chat with no files loaded, it'll fall back to asking. Make sure your relevant files or workspace are in context so it can ground its recommendations.

It's a planning tool, not a spec. /grill-me gets you to shared understanding; it doesn't produce a durable artifact by itself. Pipe its output into to-prd (or at minimum, have it write the resolved decisions to a markdown file) so the reasoning survives past the chat session.

The takeaway

The single most valuable thing you can get from an AI agent during planning is disagreement — the pointed question that exposes the decision you were about to make by accident. Left to its defaults, an agent will never give you that. It'll agree, assume, and build.

/grill-me is a nine-line prompt that flips the default. One question at a time, each with a recommendation, dependencies first, code-aware. It costs you a few minutes of being interrogated and saves you the far more expensive experience of discovering your architecture's problems in code review three days later.

Install it, point it at your next half-formed idea, and let it push back:

npx skills add mattpocock/skills --skill=grill-me -y -g

Then type /grill-me and resist the urge to just say "yes."

Credit where due: /grill-me is by Matt Pocock, part of his skills collection and documented at aihero.dev. If you found this useful, the AI Hero skills series is worth reading end to end.