You have an idea but cannot yet describe its goal or scope, or an existing proposal feels off. grill-me helps you work through that uncertainty in rounds of questions. It needs no repository and neither reads code nor saves files; products, writing and general decisions are all valid subjects.
This guide uses a local Skills manager as the first-session example. Adapt the sample prompts to your own question.
1. Install for your client
For Claude Code, use the author’s plugin. Enter this in a Claude Code session and follow the prompts. The plugin includes both grill-me and the grilling skill it calls; Node.js is not needed.
/plugin install mattpocock-skills
For Codex, install the skill files. With Node.js/npm available, run this in a terminal:
npx skills@latest add mattpocock/skills --skill grill-me --skill grilling --agent codex --global
--global makes the two skills available from other directories. To limit them to one project, enter that project directory first and omit the flag. Complete any installer prompts. Install both skills: grill-me is the entry point; grilling provides the interview rules.
If you prefer editable files in Claude Code, use npx skills@latest add mattpocock/skills --skill grill-me --skill grilling --agent claude-code --global in a terminal instead of the plugin. Installing both versions creates duplicate entries.
2. Describe the task and how finished it needs to be
Open a fresh conversation in Claude Code or Codex; you do not need a repository first. If you are in plan mode, return to a normal conversation for the discussion. Send the following to the chat input, not the terminal.
Claude Code plugin:
/mattpocock-skills:grill-me I want a local Skills manager for my own use.
My skills are spread across several folders and I struggle to find the right one.
Version one should only validate browsing and search. Exclude accounts, cloud sync and teamwork.
Help me clarify the requirements before writing code.
Codex:
$grill-me I want a local Skills manager for my own use.
My skills are spread across several folders and I struggle to find the right one.
Version one should only validate browsing and search. Exclude accounts, cloud sync and teamwork.
Help me clarify the requirements before writing code.
If you installed files in Claude Code, replace the first line with /grill-me. In Codex use $grill-me; do not copy the Claude slash command into its chat input.
Give four pieces of context: who uses it, what is inconvenient now, what this attempt should achieve and what is excluded. A prototype and a customer-ready product need different discussions. If the stack is undecided, say so; you do not need to choose a framework just to begin.
Expect numbered questions and recommendations for some choices. Questions that can be answered together may appear in one round, followed by another after your reply. There is no fixed question count.
3. Answer the questions and correct assumptions
Short numbered answers are enough. If the discussion reaches directory scope, interface and search behavior, you might reply:
1. Read only local directories I select manually; do not scan the whole computer.
2. I need a graphical interface so I can browse and read descriptions together.
3. Search names and summaries; full file contents are outside version one.
4. I am unsure about editing. Compare the costs of read-only and editable versions before I decide.
These illustrate an answer format, not questions you will always receive. You can reject a recommendation; explain the reason so later questions reflect your priorities.
After each round, check whether the agent has mixed confirmed needs with its own assumptions. If a local-file browser suddenly becomes an account system, bring it back to scope:
Return to the prototype scope.
List only decisions that currently prevent us from starting, and ask about those.
Keep accounts, cloud sync and collaboration out of this version.
Mark other unresolved details as assumptions rather than turning them into requirements.
If a round is too large, ask for one question at a time. You can also say that a decision is unknown and request a comparison before choosing.
4. Finish with requirements you can act on
Once you can explain the user, main task, included features and completion conditions, ask for a reviewable summary:
Pause the interview and summarize what we have agreed:
1. The user and problem.
2. Features required for version one.
3. Explicit exclusions.
4. Observable acceptance conditions for each feature.
5. Open decisions and assumptions that need a prototype.
List any remaining decisions that prevent implementation separately.
Show this in the conversation for my review.
“Supports search” may be too vague. For the practice task, an acceptance condition could say that a name or summary keyword filters the list, while clearing it restores all items. That is an example of precise wording; the actual rule remains your choice.
grill-me does not automatically save a document or start coding. After confirming the summary, continue with an implementation plan in the same conversation. For work spanning several sessions, request a saved specification separately.
The author’s current engineering workflow uses to-spec next. It needs its own installation and setup-matt-pocock-skills configuration, which can use local Markdown. For a first grill-me session, the summary prompt above is enough.
5. Adapt the background to your situation
Adding a feature to an existing project
grill-me can help discuss the goal and trade-offs, but it does not automatically inspect a codebase. For an independent requirements discussion, briefly describe the existing behavior and constraints yourself. Invoking /grill-me is not a code review.
If the questions must be grounded in the repository, use the author’s grill-with-docs instead. It reads the codebase and records settled vocabulary or qualifying major decisions. It also depends on grilling and domain-modeling, which must be installed. Do not expect these file-writing features from grill-me.
A built interface still feels wrong
Provide an accessible prototype or screenshot and identify the failed task. For example: “I came here to find a recently used skill, but the first screen shows categories and I do not know where to start.” Ask about the user goal, action order, states and information priority.
That leads to more actionable changes than “make it more premium.” If the uncertainty concerns visual feel, compare two small prototypes and return to the discussion with what you learned.
The interview follows the wrong premise
Pause and inspect assumptions:
Before expanding the design, list your assumptions about the goal, users and constraints.
Which have I not confirmed? Which would change the direction if they were wrong?
Let me confirm the consequential ones before continuing.
Use this when many questions are about the wrong problem. For one unsuitable question, a direct correction is usually sufficient.
6. A real example: a local Skills manager
Programmer Yupi shared a walkthrough starting from wanting a tool to manage Skills. The interview clarified local Agent Skills, a graphical interface and browsing, editing and storage needs. It then settled on Electron, React and SQLite before handing implementation to Cursor.
An implementation screenshot from Yupi’s article.
The useful pattern is the order: decide what is being managed and how it will be used before choosing implementation details. Our practice prompt deliberately limits the first version to browsing and search. Treat editing, synchronization or plugin management as separate scope decisions rather than copying the entire example stack.
7. Common questions
The terminal cannot find npx
Only Skills CLI file installation needs npx. Install Node.js LTS and npm from the Node.js website, then reopen the terminal. The Claude Code plugin does not need this step. npx runs in a terminal, not in agent chat.
grill-me does not appear after installation
Check the installation scope. With the current Skills CLI, the global file command above normally uses ~/.claude/skills for Claude Code and ~/.agents/skills for Codex. Without --global, project locations are .claude/skills and .agents/skills respectively. With custom configuration, follow the location printed by the installer rather than looking only under the older ~/.codex/skills path. Confirm that both grill-me and grilling contain readable SKILL.md files, including through any links.
List a global Codex file installation in your terminal:
npx skills@latest list --global --agent codex
Check that both grill-me and grilling appear, then refresh the agent session. For a project installation, enter that project and omit --global when checking. This lists installed files; it does not install a missing dependency.
Use $ to find the skill where supported; Codex CLI and IDE also offer /skills. Reopen the session or restart the client if it still does not appear. For the Claude plugin, check that it is enabled and try the full namespaced invocation.
If the entry point appears but grilling is missing, repeat the installation command that selects both skills.
It starts proposing a solution instead of asking
Confirm that the skill was selected. Try a fresh conversation with a concrete scope and ask it to check consequential decisions before proposing implementation. The author recommends leaving plan mode for this discussion.
Must I answer every possible question?
No. Excluded features do not need detailed design. When the first version is ready to start, summarize the decisions and leave the remaining uncertainties explicit. Prototype questions that require experience rather than more verbal reasoning.
How do I update the file installation?
For the global file installation above, run:
npx skills@latest update grill-me grilling --global
If you installed into a project, run it there and replace --global with --project.
Use the plugin’s own update mechanism if you installed the complete Claude plugin instead.
When to stop questioning and switch modes
Grill-me is useful when you have an idea worth exploring but cannot yet state its scope clearly. Start in a fresh conversation rather than asking an agent to write a complete plan and only then interrogate it; the questions may otherwise orbit the plan's assumptions. The Skill explores decisions in rounds. The target is not a fixed question count but rounds that use earlier answers to narrow what remains unknown. If the questions keep multiplying, split the goal into smaller decisions and discuss them separately. When a crucial answer is genuinely unknown, say so and plan a prototype or research step instead of guessing a tidy answer.
The session can end when you can explain the major tradeoffs, first-version boundary, and assumptions to someone who was not present. If the work is already precise, more questioning may add little; when it needs to become a project record, continue into the relevant spec workflow in the same conversation so the context you just built is still available.
Another exercise: turn “build a booking site” into a testable first version
For a single coffee shop, begin: “Use grill-me to discuss a page for booking small in-store events. Signups currently arrive by direct message, and staff lose track of counts. Version one should show events, collect name and party size, and confirm a place. No payment or membership yet. Ask about decisions that change the flow before writing code.” The next questions should probe who manages capacity, whether a full event has a waitlist, and whether confirmation is automatic or manual. You can answer in rounds rather than guessing every policy up front.
If the agent proposes automatic charging, ask whether it serves the first version and place it out of scope if it does not. An acceptance condition might be: a guest sees capacity, submits a booking visible to staff, and cannot receive a confirmed place when full. These are sample decisions to discuss, not a working site produced by the skill. If questions drift to color and framework before capacity and responsibility are settled, steer back to the choices that determine the product.