Grill Me: Adversarial Plan Interview for Hermes Agent

Grill Me is an optional Hermes Agent skill that interrogates a plan before anyone writes code. It models the plan as a design tree, then asks the user a structured round of questions until every branch is resolved and nothing is left silently assumed. Reach for it when a plan is vague, when a decision is unresolved, or when the cost of getting the design wrong is high.

What it does

The skill turns a plan or a raw idea into a design tree: each decision branches into the decisions that hang off it. It then finds the frontier, which is every decision whose prerequisites are already settled. Those are the questions that can be asked right now without guessing at answers that have not been given yet.

It works in rounds. Each round asks the whole current frontier in one message, numbered, and each question carries a recommended answer. Then it waits. A question whose answer depends on another question still open in the same round belongs to a later round, not this one.

Each answer reshapes the tree. Settled decisions push the frontier outward and unblock dependent questions, so the next round is recomputed from the new state. The loop continues until the frontier is empty.

The division of labour is explicit: facts are the agent's job, decisions are the user's. When a frontier question needs a fact from the environment, the skill looks it up rather than asking. Only the questions downstream of that lookup wait; the rest of the frontier is asked immediately.

Before you start

There are no prerequisites. The skill works on any plan or raw idea, so you do not need an existing repository, a spec, or a ticket to use it.

The skill is optional and installed on demand. Its path is optional-skills/software-development/grill-me, version 2.0.0, under the MIT licence. It runs on linux, macos, and windows. The author line credits Rafael Zendron (rafaumeu), Matt Pocock (mattpocock/skills, grilling), and Hermes Agent.

Because it is a planning skill rather than an execution skill, the practical prerequisite is a plan worth interrogating. A one-line task with no real decisions in it gives the interview nothing to work with.

Core mechanic: frontier rounds

Map the plan as a design tree. The frontier is every decision whose prerequisites are already settled, meaning the questions you can ask NOW without guessing at answers you haven't heard yet.

Work in rounds: ask the whole current frontier in one message, numbered, each question carrying your recommended answer. Then wait. A question whose answer depends on another question still open in this round belongs to a LATER round, not this one.

Format each round like so:

❓ Q1 — <question title>: <question body, options if relevant>
➡️ Recommendation: <your recommended answer + one-line why>

❓ Q2 — <question title>: <question body>
➡️ Recommendation: <...>

Each answer reshapes the tree: settled decisions push the frontier outward and unblock dependent questions. Recompute the frontier and ask the next round.

Facts are your job; decisions are the user's. When a frontier question needs a fact from the environment (codebase, filesystem, config, docs), find it yourself with search_files / read_file / terminal, or dispatch a subagent via delegate_task for a heavy exploration. Never ask the user for anything you could look up. Don't block on an exploration: only the questions downstream of it wait; ask the rest of the frontier now.

The round format matters more than it looks. Numbering keeps the user's replies traceable back to specific questions, and attaching a recommendation to each one means the user can accept a default instead of composing an answer from scratch. That is what keeps a long interview from stalling.

Question coverage

Three families of branches get worked into the tree.

Understanding

The real goal and its boundaries. What is the ACTUAL objective? What is explicitly IN and OUT of scope? What are the constraints (time, tech, team, budget)? Who are the users?

Technical decisions

For each architectural choice: "Why this approach and not X?" and "What happens if Y fails?" Also "What's the worst case?" and "How would you roll back?" The skill cross-references the existing codebase here, and if the project already has a pattern for this, it calls that out.

Edge cases

"What happens if the user does Z?" and "What if dependency X goes down?" Then scale and security: "What if volume is 100x expected?" and "What are the security implications?"

Synthesis

When the frontier is empty, the skill closes out the interview in three steps:

1. Summarize ALL decisions in bullet points
2. List anything left open, and what is explicitly OUT of scope
3. Ask: "Aligned? Should I start implementing, or adjust anything?"

Do not act on the plan until the user confirms shared understanding. The summary is the artefact you keep: it is the record of what was decided, what was deferred, and what was ruled out, and it is what the implementation gets checked against later.

When not to use it

Do not use it for existing code. That is what requesting-code-review is for. Do not use it for simple one-off tasks either, where there is no design tree worth walking.

The intended trigger points are narrower than "any planning": the user says "grill me", "interview my plan", or "stress test this idea"; the work ahead is complex, such as auth flows, schema changes, migrations, or payments; a plan has unresolved decisions or seems vague; or you are about to decompose work with subagent-driven-development.

Limits and gotchas

The source lists six pitfalls, and they are the failure modes that show up in practice.

1. Asking questions out of dependency order. A question that depends on an unanswered question is a guess wearing a question mark. Keep it for a later round.
2. Skipping the codebase. Find facts in code with Hermes tools instead of asking the user.
3. Accepting "I don't know" as final. Suggest options, explain trade-offs, make a recommendation.
4. Writing code during the interrogation. Alignment only, code after the explicit green light.
5. Being too agreeable. Your job is to find problems. If everything looks fine, look harder.
6. Not adapting to the user's language. Interview in whatever language the user speaks.

There is also a verification checklist to run before calling the interview done:

• Every question in a round had all its prerequisites already settled
• Provided a recommendation with each question
• Explored the codebase for facts instead of asking the user
• Frontier empty (no branch silently assumed) before synthesizing
• Produced a clear summary of all decisions and open items
• Confirmed user alignment before stopping

The last item is the one that gets skipped. An empty frontier is not the same as an aligned user, and the skill does not stop until the user has confirmed shared understanding.

What pairs with it

Grill Me sits at the front of a chain. Once alignment is confirmed, subagent-driven-development is the natural next step, since the decomposition it performs is exactly what the interview was preparing for. test-driven-development follows from there, turning the settled decisions into executable expectations.

For work on code that already exists, requesting-code-review is the counterpart skill: same adversarial intent, different target.