grill-me and grill-with-docs: How to Actually Install and Run Them

`/grill-me` is not a brainstorming tool and it is not a code reviewer. It is a specific, narrow instrument, published as an open-source Claude Code skill by Matt Pocock: it interviews you about a plan or a design until every branch of it has been resolved, not just mentioned. Here is exactly how to install it, run it, and which of its two variants to reach for.

Installing it

Both skills ship in Matt Pocock's Skills For Real Engineers repo, free and open source. In Claude Code, install the whole set as a plugin — run `/plugin install mattpocock-skills`, or `claude plugins install mattpocock-skills` from a regular shell — and it updates automatically as he ships changes. If you use Codex or another agent, or want an editable copy of just this one skill in your own repo instead, run the command below and it adds `grill-me` under your project's skills directory.

npx skills add https://github.com/mattpocock/skills --skill grill-me

Either way, run `/setup-matt-pocock-skills` once per project afterward — it asks which issue tracker you use and where to save docs, and a couple of the skills depend on that setup.

Two variants, two different jobs

/grill-me is for non-code decisions — a product plan, a business idea, a decision with no repository attached. /grill-with-docs runs the same interrogation for engineering work, and additionally builds a shared vocabulary as it goes — a glossary and architecture decision records (ADRs) — using the `domain-modeling` skill underneath. Use `/grill-me` for a plan; use `/grill-with-docs` for a change to an actual codebase you want documented as you decide it.

What a session actually looks like

It does not feel like an interview with a fixed question list. It feels like a conversation that refuses to let a vague answer stand — "we will figure out the retry logic later" gets followed by "what happens to a message that fails during 'later'?" until there is an actual answer, not just an intention to have one eventually.

When to reach for it, and when not to

1. Before starting anything expensive to reverse — a migration, an architecture choice, a public API shape: run it.
2. When you have described the same plan out loud twice and it still feels slightly unsettled: run it.
3. When you do not have a plan yet and are still exploring what the plan even could be: don't — that is what brainstorming is for.

The value is not that it makes plans sound better. It is that it makes plans survive contact with reality, which is a much higher bar and a much rarer thing to get for free before you have spent the time building.