Grill Me

Grill Me

Overview

Drive an interactive plan review that keeps digging until the important unknowns are either answered, disproven by repository evidence, or explicitly deferred. Prefer targeted investigation over broad speculation, and prefer one decisive question over a large batch of shallow questions.

Operating Mode

Treat the plan as a decision tree, not a prose document.

For every branch:

• Identify the parent decision.
• Identify what downstream decisions depend on it.
• Resolve the dependency in the highest-leverage order.
• Ask only the next question that materially unlocks progress.

If the answer may already exist in the codebase, inspect the codebase first. Ask the user only when repository evidence is absent, ambiguous, stale, or policy-driven.

Do not dump a questionnaire. Run an interview.

When a question does not settle after direct discussion in the main thread, spawn a fresh subagent for that single unresolved branch. Give the subagent only the minimum task-local context needed to reason about the question. Do not pass the full grill-me thread, your hidden chain of reasoning, or your preferred answer. Treat the subagent as an isolated deep-dive surface, then bring back only the useful conclusions, alternatives, and evidence.

Treat branch subagents as temporary tools, not long-lived collaborators. Keep each one tied to a single unresolved branch, and close it as soon as that branch is settled or explicitly abandoned.

Workflow

1. Establish the Plan Artifact

Pin down what is being designed before interrogating details.

Extract or ask for:

• Objective
• Scope boundaries
• Intended users or operators
• Success criteria
• Time or rollout constraints
• Existing artifacts to inspect first: code, docs, tickets, RFCs, schemas, tests

If the user provided a document or codebase, read it before asking foundational questions that it can answer.

2. Build the Decision Tree

Convert the plan into a compact internal model:

• Goals and non-goals
• Hard constraints
• Major architectural choices
• Data and state model
• Interface boundaries
• Operational concerns
• Validation and rollout strategy

For each item, label it mentally as one of:

• Resolved
• Assumed
• Unknown
• Conflicted
• Deferred

Prioritize Unknown and Conflicted items that block many other decisions.

3. Explore Before Asking

Use the repository to answer factual questions whenever possible.

Inspect:

• Existing modules that would own the change
• Current interfaces, schemas, config, and API boundaries
• Tests that reveal intended behavior
• Docs, ADRs, and comments that encode prior decisions
• Similar features or migrations already implemented

When reporting what you found, distinguish clearly between:

• Facts observed in the codebase
• Inferences from those facts
• Remaining questions for the user

4. Interrogate Branches One-by-One

Ask one short, high-value question at a time unless several questions are tightly coupled and cheaper to answer together.

Every question should have a reason. Prefer questions like:

• Which of these two constraints is actually binding?
• Is this state authoritative here or mirrored from another system?
• What failure is acceptable: stale data, blocked writes, or partial rollout?
• Does this need backward compatibility, or can old callers break?
• Is the real requirement configurability, auditability, latency, or simplicity?

Avoid questions that are merely exhaustive but not decision-relevant.

After each answer:

• Update the decision tree
• State what became clear
• State what remains open
• Move to the next blocking dependency

If the answer does not produce settled behavior, a crisp decision, or a shared framing:

• Confirm why the branch is still unresolved
• Decide whether the missing piece is factual, conceptual, or preference-driven
• If a deeper isolated discussion would help, spawn a subagent focused only on that branch
• Instruct the subagent with the raw question and the minimum supporting artifacts
• Keep the main thread lean; do not paste the whole unresolved discussion into the subagent
• Reconcile the subagent output back into the main decision tree

After reconciling a subagent's output:

• Confirm with the user whether the branch is now settled
• If settled, close the subagent immediately
• If explicitly deferred or abandoned, close the subagent immediately
• If still unresolved, keep the subagent only if it is actively useful; otherwise close it and spawn a fresh one later if needed

5. Force Precision

When the user answers vaguely, tighten the abstraction instead of accepting fuzzy language.

Convert vague statements into concrete choices:

• "Fast" -> latency or throughput target
• "Simple" -> fewer moving parts, less code, less operator burden, or less user friction
• "Support retries" -> idempotent writes, deduplication, or resumable workflow
• "Scalable" -> which dimension grows and what bottleneck matters

When multiple interpretations remain plausible, present the alternatives and ask the user to choose.

6. Check the Missing Surfaces

Before concluding, explicitly close or defer the major surfaces below:

• Inputs and outputs
• Ownership and source of truth
• Persistence and migrations
• Concurrency and failure handling
• Permissions and security boundaries
• Observability and debugging
• Performance and capacity assumptions
• Backward compatibility
• Test strategy
• Rollout, fallback, and recovery

Do not require every plan to be equally detailed. Match depth to risk.

Questioning Heuristics

Prefer questions that:

• Eliminate multiple downstream ambiguities
• Expose hidden constraints
• Separate policy decisions from implementation details
• Reveal incompatibilities with the existing codebase
• Convert preferences into measurable requirements

Deprioritize questions that:

• Are already answerable from local artifacts
• Do not affect design or execution
• Can wait until a later implementation phase without creating rework

Response Shape

Keep the conversation moving. A good turn usually contains:

• A one- or two-sentence summary of the current model
• Any codebase findings that changed the picture
• The single next question, or a tightly related pair

When you use a subagent, also include:

• Why the branch was worth isolating
• What minimal context was delegated
• What conclusion or option set came back
• Whether the branch is now resolved, narrowed, or still open
• Whether the subagent was closed or remains temporarily active

When useful, show a short checkpoint list of:

• Resolved decisions
• Open decisions
• Explicit assumptions

Stop Condition

Stop the interview only when one of these is true:

• The plan is concrete enough to implement safely
• The remaining unknowns are explicitly deferred and non-blocking
• The user asks to pause or switch modes

Before stopping, summarize:

• Final shared understanding
• Decisions made
• Assumptions still in force
• Risks or unanswered questions that remain

Example Triggers

Use this skill for prompts like:

• "Interrogate this architecture plan until there are no hidden assumptions left."
• "Walk this refactor proposal branch-by-branch and tell me what you need to know."
• "Review this migration plan, explore the repo for answers first, and only then question me."
• "Turn this vague feature idea into an implementation-ready plan by interviewing me."