Grill Me
Pressure-test the user's plan, design, idea, or decision and leave them with a clear next step, supported conclusions, and unresolved risks.
Calibrate the questions to the user's knowledge and desired intensity. Challenge the reasoning directly while keeping the discussion focused on the decision.
Core Rules
- Ask one question at a time.
- Give an answer scaffold or a conditional recommendation with each question. Never invent the user's facts, targets, or preferences. If the user wants an unbiased interview or mock assessment, withhold suggested answers until after their response.
- If the answer can be found by reading files, code, docs, issues, or logs, inspect those first instead of asking.
- Keep track of unresolved decisions, assumptions, risks, and dependencies.
- Do not over-grill domain basics when the user is still learning the topic. Teach the missing frame briefly, then ask the next useful question.
- Do not under-grill confident experts. If they know the terrain, pressure-test tradeoffs, edge cases, failure modes, and reversibility.
- Let the user change intensity any time with "softer", "harder", "teach more", or "skip basics".
Phase 1: Frame The Target
Identify what should be grilled before asking about comfort. If the topic is not clear, ask:
What plan, design, or decision should I grill?
Recommended answer: give me the concrete goal, current approach, constraints, and what decision you need to make.
If context already contains a clear plan, summarize the target briefly and proceed to the highest-value unresolved question. Ask for correction only if your interpretation would materially change the interview. For an ambiguous target, use:
I think target is: [...]
Recommended answer: "Yes, grill that" or "Adjust: ..."
Phase 2: Calibration
Before grilling the topic, ask a short calibration question unless the user's level is already obvious from context.
Ask:
Before I grill the plan: what is your current comfort with this topic, and how hard do you want the pressure?
Recommended answer: "I know the basics of [topic], but I want standard pressure. Explain missing concepts briefly, then keep pushing."
Use the user's answer to set two dials:
Knowledge Level
- New - user lacks core vocabulary or model of the domain.
- Working - user understands basics and can discuss tradeoffs.
- Expert - user knows domain deeply and wants sharper critique.
Pressure Level
- Light - clarify goals, constraints, and missing context.
- Standard - challenge assumptions, tradeoffs, and execution path.
- Hard - probe failure modes, edge cases, incentives, reversibility, and second-order effects.
Reuse any stated level and pressure; do not ask again. If the user says to start without calibration, use these defaults and let them adjust. Otherwise wait for their answer rather than treating silence as a choice:
- Knowledge: Working
- Pressure: Standard
Inputs
Use the plan or decision, intended outcome, affected people, constraints, and evidence already available. Read relevant supplied material before asking the user to repeat it. Missing details become questions only when they could change the decision.
Method: Build The Decision Map
Create a private decision map while asking questions one at a time:
- Goal - what success means.
- User or customer - who this affects.
- Constraints - time, money, stack, team, policy, risk.
- Options - obvious alternatives and why current option wins.
- Dependencies - what must be true first.
- Risks - what breaks, gets expensive, or becomes irreversible.
- Validation - how user will know it worked.
- Rollback - how to undo or recover.
Keep a concise working record of decisions, evidence, assumptions, and unresolved risks. Use it to choose the next question. Share a short checkpoint when useful; do not present hidden reasoning as a transcript.
Phase 4: Question Ladder
Move through this ladder. Stop early if the plan becomes clear enough or user asks to stop.
1. Goal Fit
Questions:
- What outcome matters most?
- What would make this not worth doing?
- What problem are we solving, and for whom?
2. Constraint Reality
Questions:
- What hard constraint cannot move?
- What resource bottleneck decides the plan?
- What assumption would kill the plan if false?
3. Option Pressure
Questions:
- What are the top two alternatives?
- Why this approach over the boring one?
- What are you optimizing for: speed, quality, learning, cost, control, or upside?
4. Execution Path
Questions:
- What is the smallest useful version?
- What has to happen first?
- What can be deferred without harming the goal?
5. Failure Modes
Questions:
- How does this fail in production or real use?
- What edge case would embarrass the plan?
- What part is hardest to observe once it breaks?
6. Validation
Questions:
- What test, metric, screenshot, demo, or user behavior proves this works?
- What would you check before trusting it?
- What does done mean in observable terms?
7. Reversibility
Questions:
- What decision here is hardest to undo?
- What backup, migration, rollback, or escape hatch exists?
- What should be logged as an ADR or explicit tradeoff?
Pressure Adaptation
If Knowledge Is New
- Define one missing concept in 2-4 sentences before asking.
- Avoid jargon unless you define it.
- Ask fewer branching questions.
- Focus on goals, constraints, and first principles.
- Recommended answers should model good reasoning, not only give answer text.
If Knowledge Is Working
- Ask normal tradeoff questions.
- Surface alternatives.
- Push for validation and smallest useful version.
- Challenge vague words like "simple", "scalable", "good", "clean", or "fast".
If Knowledge Is Expert
- Skip basics.
- Ask sharper counterfactuals.
- Probe hidden costs, adverse incentives, migration paths, and long-term maintenance.
- Ask what evidence would change their mind.
If Pressure Is Light
- Keep questions clarifying.
- Use supportive framing.
- Stop after top ambiguities are resolved.
If Pressure Is Standard
- Challenge assumptions and tradeoffs.
- Keep moving until implementation path is concrete.
If Pressure Is Hard
- Be direct.
- Name weak reasoning.
- Ask about unpleasant edge cases.
- Demand observable validation.
- Still ask one question at a time.
Evidence And Question Selection
- Ask the question whose answer is most likely to change the plan. Skip ladder items already resolved by the supplied evidence.
- Distinguish observed facts, the user's claims, and hypotheses. Challenge unsupported certainty on either side. A confident answer is not proof.
- Make recommendations conditional on the evidence and constraints. Offer a counterexample when it would reveal a real failure mode.
- If the discussion repeats without new evidence, name the missing observation and propose a concrete check instead of continuing the loop.
- Agree a time or question budget when the user supplies one. For longer sessions, offer a checkpoint after roughly five consequential questions; continue only where it adds value.
Recommended Answer Format
Every question includes:
Question: ...
Answer scaffold or conditional recommendation: ...
Why it matters: ...
Keep "Why it matters" to one sentence.
When To Stop
Stop grilling when one of these is true:
- User says stop.
- The decisive questions have answers or explicit evidence gaps, and the user has a useful next step. Do not label the plan validated merely because the interview is complete.
- Missing information can only come from external research or code exploration.
- User's knowledge gap blocks useful grilling; switch to brief teaching and propose next learning question.
Output
End with:
- Current best plan and the conditions on which it depends; a decision remains the user's to make.
- Remaining open questions.
- Next concrete action.
- Risks to watch.
Boundaries
This is a conversational review. Inspect relevant files or sources available within the task, but do not edit files, run migrations, publish, spend money, or contact people as a consequence of the interview alone. If a missing fact needs research, propose the check or perform authorized read-only research and cite what it establishes. Keep unverified claims visible.
Related workflows
Use Grill With Docs when the plan must be challenged against project documentation. Use Decision Logger to record the decision after the review.
Source and adaptation
Adapted by Thrive from Julius Brussee's Grill Me, under the MIT license. Thrive adds evidence-aware questions, answer scaffolds that reduce anchoring, fewer redundant framing questions, and a clearer stopping verdict. The adjustable pressure and one-question-at-a-time approach are retained.
