Stop Asking Claude to Agree With You - Engineering Blog
Akash Karyakarte
Software Engineer • Full-Stack<br>AI Enthusiast
Follow
Custom Social Profile Link
-->
The best claude skill I’ve found writes no code. It just won’t let me start until I know what I’m building.
Why Plan Mode isn’t enough
For a long while, my default move with any non-trivial feature was Claude Code’s plan mode. Sketch the idea, let it draft a plan, skim it, hit go.
The cracks showed up fast.
A fuzzy ask produces a fuzzy plan. The output looks structured and confident, but it’s quietly inheriting every gap in your thinking.
The agent drifts mid-execution. You approve a plan, switch to execute, and it quietly adds files and patterns the plan never mentioned. You end up appending “implement exactly as written, nothing extra” to every run.
It never challenges the idea itself. Plan mode answers how Claude would build your thing. It never asks whether the thing is worth building, or whether you’ve actually thought it through. You can burn three days producing a clean, well-structured mistake.
That last one is the real gap. Plan mode assumes your idea is already sound and your only problem is execution. Most of the time, that assumption is wrong — and that’s the exact gap /grill-me fills.
The skill that argues back
Matt Pocock — the TypeScript educator behind Total TypeScript — opened up his personal .claude directory as a public skills repo on February 3, 2026. Within three months it had crossed 50,000 GitHub stars, peaking near the top of GitHub’s trending charts. Not a framework, not a wrapper — just the actual markdown files he uses every day.
The repo targets one failure mode: misalignment. You think the agent understood you. Then you see what it built, and it clearly didn’t. The same communication gap you get with a human dev, now at machine speed.
The headline fix is /grill-me. It removes vagueness before any code exists, by interrogating your plan one decision at a time. The entire skill is three sentences:
Interview me relentlessly about every aspect of this<br>plan until we reach a shared understanding. Walk down<br>each branch of the design tree, resolving dependencies<br>between decisions one by one.
That’s it. No clever machinery — the value is entirely in being forced to answer.
Getting it running:
npx skills add mattpocock/skills
Then run /setup-matt-pocock-skills once per repo to wire up your issue tracker and config.
The questions you didn’t want to answer
Take a real feature — per-workspace billing limits in a multi-tenant SaaS. You sketch the idea and type /grill-me.
Claude: When a workspace hits its limit, does the whole workspace get blocked, or just new usage?
Me: Just new usage, I think.
Claude: Who gets notified — the user who triggered it, the workspace admin, or both? Through what channel?
Me: Admin. Probably email.
Claude: If the admin ignores that email and a user hits the wall mid-session, what’s the experience? Hard error? Degraded mode? Graceful message?
Me: …I hadn’t defined that.
Claude: That’s your entire degradation story. It shapes the API contract, the frontend, and what the billing page has to show. Let’s keep going.
One rough idea. A handful of decisions that reshape the architecture before implementation, instead of surfacing as bugs three days in.
Every answer you give in a grill session is a decision you won’t have to reverse in code review.
The pipeline
FIG. 01 · The four-step workflow.
The whole thing runs as a single continuous session, each step feeding the next.
/grill-me → /to-prd → /to-issues → /afk
The rule that makes it work: never /clear between steps. The PRD skill leans on everything from the grill — your answers, your reasoning, the edge cases you named, the trade-offs you accepted. A PRD generated cold is a template. A PRD generated right after a grill is a spec with a point of view.
Tight PRD in, tight tickets out — /to-issues produces tasks with real context and acceptance criteria, not “implement auth.” Tight tickets mean /afk can execute without guessing.
There’s a second payoff that shows up later. The PRD and the issues are written artifacts — they live in your tracker, not just in a chat window. So when a session dies halfway, or you come back to the same feature a week later, you’re not reconstructing intent from memory. You point a fresh session at the PRD and the open issues, and it picks up with the full reasoning already in hand: what you decided, why, and what’s left. The grill happens once; the context it produces keeps paying out across every session that touches the feature.
Output quality at the end is a direct function of honesty at the beginning.
When the grill gets hard: /handoff
Deep grill sessions burn context. You’re well into one when you realize you need to prototype something or check how an existing schema behaves. The instinct is to do it right there in the same session.
Don’t.
Pocock also wrote /handoff, built for...