I Stopped Arguing With Claude About My Plans — Here's What I Do Instead

For a long time, my planning process with Claude looked like this: I would describe an idea, it would agree the idea sounded reasonable, I would start building, and three days later I would discover the actual hard question — the one that should have killed the plan or reshaped it — sitting unasked the entire time. I stopped doing that. Now I run `/grill-me` before anything that matters, and it has changed how far a plan gets before I trust it.

The problem was never that Claude disagreed too little

It is tempting to blame this on Claude being agreeable. That is only half true. The deeper issue is that a normal conversation has no mechanism forcing every branch of a decision to actually get resolved — you can describe a plan, get a supportive response, and never notice that "what happens if the third-party API rate-limits us" was never actually answered, just implicitly assumed away.

Where this skill actually comes from

`/grill-me` is not something Claude does natively — it is an open-source skill from Matt Pocock's Skills For Real Engineers repo, a free collection of Claude Code skills he uses in his own engineering work. It is deliberately not automatic: the skill's own definition sets disable-model-invocation, meaning Claude will not decide on its own to start grilling you — you type `/grill-me` yourself, on purpose, when a plan is worth the interrogation.

What `/grill-me` actually does

It flips the roles. Instead of me describing a plan and waiting for a reaction, the skill interviews me — relentlessly — about the plan, following each branch of the decision tree until it is actually resolved, not just mentioned. It does not stop at the first plausible-sounding answer. If I say "we will handle that edge case later," it asks what "later" means and what happens between now and then.

What that interview surfaces that a normal conversation does not

  • Assumptions I stated confidently but never actually verified.
  • Edge cases I mentioned once and then quietly stopped thinking about.
  • Places where two parts of my own plan silently contradicted each other and I had not noticed.

The uncomfortable part is the useful part

A grilling session is not comfortable. Getting asked "how would you know this failed?" four different ways until you actually have an answer is not a pleasant experience. But the discomfort is the signal — it means a branch that would have surfaced three days into implementation just surfaced in ten minutes instead, while it still costs nothing to fix.

If your plans keep surviving the conversation and dying in implementation, the conversation was never the test. Getting grilled before you start is — and it takes five minutes to install.

Questions

What is the grill-me skill?

An open-source Claude Code skill from Matt Pocock's Skills For Real Engineers repo (github.com/mattpocock/skills). It interviews you about a plan or design, following each branch of the decision tree until it is genuinely resolved rather than just mentioned, instead of the usual pattern of describing a plan and getting a supportive reaction.

Does grill-me run automatically?

No — it is explicitly invoked. The skill is defined with disable-model-invocation, so Claude never starts a grilling session on its own; you type /grill-me yourself when you have a plan worth stress-testing.

Why does Claude usually agree with plans that later fall apart?

A normal conversation has no mechanism forcing every branch of a plan to actually get resolved — you can describe a plan, get agreement, and never notice that a key edge case was implicitly assumed away rather than answered.