An idea can sound clear until someone asks what should happen when it fails, who should be allowed to use it, or what we actually need in the first version. Those questions can change the plan before we have written any code.
I want the AI to help find those gaps. It can read the available context, challenge assumptions and ask about the decisions that still need my judgment.
My grill-me-pragmatic skill was inspired by Matt Pocock's grill-me skill. The version described here is my adaptation, with an emphasis on keeping the conversation practical and writing down the resulting decisions. Matt's skill has continued to evolve too; this article describes mine as of its updated date.
Why pragmatic?
There is a balance here. I want the AI to make sensible choices from the context and keep planning efficient, while still involving me in decisions that need my judgment.
Sometimes it makes too much explicit: every small choice becomes a question or a lengthy explanation. Other times it leaves too much implicit and moves ahead on an assumption we should have discussed.
The pragmatic part is an attempt to loosen that up a bit. I give the AI more room to handle ordinary choices without spelling out every detail, and ask it to focus the conversation on decisions that could meaningfully change the plan.
That does not guarantee it will get the balance right. I still need to notice when it assumes too much or spends too long on something minor. But for me, it has helped make the planning conversation less rigid and reduced some of the unnecessary back-and-forth.
Start with the outcome
I do not need a finished specification to begin. I can bring an idea, an existing plan or a document with unresolved decisions. This example uses my skill’s Claude Code command:
/raholsn:grill-me-pragmatic We want users to retry failed report exports from the dashboard. Help clarify the first version using the existing export flow.This is an illustrative example. It gives the AI assistant an outcome and a place to look, while leaving the scope open for discussion.
The skill starts by restating the plan briefly and identifying the decisions that matter. It is a standalone planning conversation; it does not require a tracker or company profile.
Read first, then ask
If the code already shows how exports are created, the AI should inspect that flow. Asking me to describe something it can discover adds work and risks replacing evidence with my recollection.
The exploration stays focused on the current decision. Relevant handlers, tests, configuration or client behavior can establish part of the answer without requiring a complete repository audit.
For example, imagine the existing export flow creates a separate job for each request and retains failed attempts. That would give us a starting point for discussing retries. It would not settle whether users should be able to retry every failure or only particular ones. That depends on the behavior we want and the constraints we need to respect.
The AI should summarize what it found and ask about the remaining decision.
One question at a time
The skill presents a recommendation before each question. That gives me a concrete proposal to assess and a reason for it.
An illustrative exchange might look like this:
Recommended answer: Limit the first version to retrying an export with its original parameters. That keeps retry behavior separate from editing and requesting a different report.
Question: Should users be able to change the report parameters when they retry?I can accept that, reject it or explain a missing requirement. If my answer leaves an important ambiguity, the skill asks a tighter follow-up.
The ordering matters too. Deciding whether a retry preserves the original request comes before discussing how an editing screen should work. Once a decision is resolved, the skill tracks it and moves to the dependent questions instead of asking me to confirm it again.
Recommendations remain proposals. A confident suggestion does not establish the product requirement or make the tradeoff mine by default.
Let the AI handle the ordinary choices
Not every branch of the plan needs a question:
| Situation | What the skill should do |
|---|---|
| Existing code or documents establish the answer | Read them and explain the finding. |
| A choice is conventional, low-risk or easy to reverse | Make the choice and state the assumption briefly. |
| A decision changes scope, user behavior or a consequential commitment | Recommend an answer and ask one focused question. |
| An answer would not materially affect the plan | Skip the question. |
In the export example, following the application's established naming convention is usually something the AI can handle. Deciding who may retry another user's export needs more care because it changes permissions and user behavior.
The skill considers areas such as failure handling, data, rollout and testing when they matter to the plan. Those areas are prompts for judgment, not a requirement to ask a question about every topic.
The planning workflow
These diagrams describe the skill instructions, not a recorded planning session.
Open the overview at full size
Explore the planning conversation
The sequence shows how the skill uses available context, follows up on ambiguous answers and records the outcome.
Know when to stop
The conversation finishes when the relevant decisions are concrete enough to move forward and the remaining unknowns are explicit, acceptable assumptions. There will almost always be more detail we could discuss.
Some unknowns also need evidence beyond a conversation. If we do not know whether users understand the proposed retry behavior, more confident wording from the AI will not answer that. The next useful step might be a prototype or feedback from the people who will use it.
I need to keep the conversation directed toward the outcome and be clear when a recommendation relies on something we have not established.
Keep the decisions after the conversation
The skill writes a concise Markdown decision record containing:
- The plan summary.
- Decisions and their reasoning.
- Assumptions and why they are acceptable.
- Material open risks or questions.
- A suggested next step.
It records the outcome rather than the full conversation. I can choose the output path; otherwise it uses an existing planning directory or creates docs/planning/.
For the illustrative export plan, the default filename could be:
docs/planning/2026-07-02-export-retry-grill-decisions.mdThe record gives the next stage something concrete to work from. I can use it directly or ask write-requirements to turn it into requirements. Neither happens automatically, and the grilling conversation does not start implementation. I have to explicitly end planning and ask for execution.
The skill
Thanks to Matt Pocock for the inspiration. His grill-me source is available in his skills repository.
You can find the grill-me-pragmatic skill on GitHub.
For me, the value is in finding the decisions that deserve attention before they become assumptions in the code. The AI can help expose them, while I stay responsible for the direction and the choices we carry forward.
Happy coding!
