Use grill-me to Pressure-Test an AI Implementation Plan Before Code
Many software mistakes begin as decisions that nobody explicitly made. A feature request sounds clear enough, an AI coding agent begins implementation, and the details get settled by whichever model output appears first. Later, the team discovers that “add roles,” “cache this endpoint,” or “support collaboration” contained several linked product, data, security, and rollout choices.
grill-me is designed for the moment before that happens. It is a manually invoked skill that interviews you about a plan or design until the important decision tree is resolved. It asks one question at a time, supplies a recommended answer, and waits for feedback before continuing. Crucially, if an answer can be discovered by inspecting the codebase, the agent should investigate rather than ask you to recreate repository facts from memory.
The name is playful. The underlying practice is serious: force a proposal to survive questions before code makes it expensive to change.
What grill-me is-and is not
grill-me is not a general implementation workflow. It does not replace a specification, an issue breakdown, tests, or code review. It is a pressure-test for a direction that is not yet sufficiently settled to build.
That narrowness is its strength. Teams often need an agent to push back, not agree. A conventional assistant can be biased toward accepting the first plausible framing. A grilling workflow instead asks what would make the plan fail: what is ambiguous, what constraint is missing, what decision is being deferred accidentally, and what evidence should be checked in the repository.
Why one question at a time matters
A long questionnaire feels efficient but usually is not. It asks about details before the premise is fixed, and the answers become inconsistent. A sequential interview allows dependencies to resolve in order.
For example, consider “add organization-level roles.” The first question might be whether roles are global or scoped to each organization. That answer determines whether membership is a separate domain entity. The next question may be whether permissions are static role bundles or configurable. Only then does it make sense to ask about API shape, migration, administration UI, or audit requirements.
By proceeding one decision at a time, the skill turns a vague feature into a chain of explicit commitments.
Start with a proposal, not a blank page
The best grilling sessions begin with enough context to challenge. State the desired outcome, the affected users, known constraints, existing artifacts, and the decision you want help making. Do not ask “what should we build?” when you really mean “which of two approaches fits this codebase?”
Grill this proposal before implementation.
Goal: organization owners can invite members by email.
Constraints: existing RBAC model, no public workspace enumeration,
and invitations must be revocable.
Inspect the relevant auth and membership code first.
Ask one question at a time. Recommend an answer, explain the trade-off,
and record settled decisions and open risks.This gives the agent a job: interrogate the plan using evidence, not invent the product from scratch.
Questions worth asking before code
Outcome and scope
What user behavior changes? Who can trigger it? Who can observe it? What explicitly remains out of scope? Scope questions prevent a small feature from quietly becoming a platform redesign.
Domain model
What entities exist? Who owns them? What states can they occupy? What transitions are allowed? For invitations: pending, accepted, revoked, expired, perhaps resent. Decide whether resending creates a new token, extends expiry, or simply reuses a record. These are product rules with storage consequences.
Authorization
Who may create, view, revoke, accept, or resend the resource? Are permissions checked at an organization boundary, a project boundary, or both? What information should a denial reveal? Authorization is not a final middleware detail; it belongs in the plan.
Failure and recovery
What happens when an email is already associated with a member? When delivery fails? When two administrators act simultaneously? When a client retries? A plan that only describes the happy path is still incomplete.
Compatibility and rollout
Will the change alter stored data, public APIs, permissions, or client assumptions? How will it be migrated? How will you monitor behavior after release? The right answer may be “no special rollout needed,” but it should be consciously chosen.
Use repository evidence
One of grill-me’s best rules is that codebase facts should be discovered, not delegated to the user’s memory. Before asking whether an endpoint follows REST or RPC conventions, inspect existing endpoints. Before proposing a new role table, inspect the existing authorization system. Before recommending a migration, inspect database conventions and deployment tooling.
This does not mean the codebase gets the final word. Existing patterns can be wrong or outdated. It means the agent should distinguish “we should deviate deliberately” from “we did not know the convention existed.”
What a successful session produces
The output should be more than a transcript. It should leave behind a concise decision record:
The confirmed outcome and non-goals
Key decisions and their rationale
Alternatives considered and rejected
Assumptions that need validation
Open risks or owners
The recommended next artifact: domain model, PRD, spec, issues, or implementation plan
This gives a later agent something durable to follow. It also makes review better because reviewers can see what the code is intended to embody.
Where grill-me fits now
AI Hero notes an important update from Matt Pocock: for coding-oriented planning, he now generally recommends domain-model as the starting point when you want to align a plan with codebase language, CONTEXT.md, and architecture decision records. The suggested broader sequence is domain-model → to-prd → to-issues → tdd.
This does not make grill-me obsolete. It gives it a clearer role. Use grill-me as a lighter, targeted pressure-test when you have a plan that needs interrogation. Use a broader domain-model workflow when the task needs deep alignment with the application’s vocabulary and existing decisions.
Common failure modes
Asking hypothetical questions forever
Questions should converge toward a decision. If a scenario has little likelihood or impact, note it as a risk rather than letting it block every other choice.
Letting recommendations become decisions
The agent can recommend; the responsible human should approve. Record when a recommendation is accepted, changed, or deferred.
Skipping evidence gathering
A beautiful interview based on false assumptions is still waste. Require inspection of relevant code, documentation, and recent diffs first.
Calling it planning when no artifact remains
Capture the conclusions. Otherwise the next implementation session will reopen the same questions.
A repeatable ritual
Write a one-paragraph proposal.
Link relevant files, tickets, ADRs, and constraints.
Ask the agent to inspect before questioning.
Run one-question-at-a-time grilling.
Record decisions, non-goals, and unresolved risks.
Turn the result into the next formal artifact.
Only then begin implementation.
The time spent here is not delay. It is a way to move uncertainty from code into conversation, where it is cheaper to resolve.
Bottom line
Use grill-me when a feature direction feels plausible but has not earned implementation yet. It is particularly valuable when several decisions depend on each other and you want an agent to challenge you rather than cheerlead. Code should be the result of a decision, not the place where the decision first becomes visible.
