# Grill Me

> Adversarially interrogate a claim, document, or piece of work until it either breaks or holds. Finds the load-bearing claims, attacks each the way a skeptical expert would, and follows up three levels deep instead of accepting the first answer. Use when the user says "grill me", "poke holes in this", "interview me on this", "what will they ask", "stress test this", or is about to defend work to someone who did not build it.

- Skill: `raz-gits/grill-me` (Agent Skill)
- Install (CLI): `npx skillmds@latest add raz-gits/grill-me`
- Raw SKILL.md: https://api.skillmd.com/api/skills/raz-gits/grill-me/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Raz-Gits (https://skillmd.com/u/raz-gits)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/raz-gits/grill-me

---


# grill me

Most interview prep and most review generates questions. Questions are the easy
part. What actually breaks people is the **second and third follow-up**, because
the first answer is always the rehearsed one.

This skill exists to get past the rehearsed answer.

It also has an output that question-generators do not have. At the end, every
claim gets a verdict: it holds as stated, it holds at a smaller size, or it comes
out. A grilling that ends with the user feeling worse and changing nothing was a
waste of both people's time.

## What this is for

Anything the user will have to defend to someone who did not build it and has no
reason to be generous:

- a resume bullet, an application answer, a cover letter
- a design doc, an RFC, a migration plan
- a pull request, an architecture decision
- a pitch, a proposal, a set of numbers
- a claim made in passing that is about to become load-bearing

## Step 1, find the load-bearing claims

Do not grill everything. Most of any document is scaffolding, and attacking
scaffolding wastes the user's attention on things nobody will ever ask about.

A claim is load-bearing when removing it changes the conclusion, or when the
reader's decision depends on it being true. Typically three to six per document.

List them back before starting, numbered, in the user's own words. If the user
disagrees about what the document rests on, that disagreement is itself worth
having and takes thirty seconds.

## Step 2, classify how each one can fail

Attack shape follows failure mode. Pick the one that fits before writing a
question:

| Failure mode | What it looks like | The opening question |
| --- | --- | --- |
| **Unsupported** | stated as fact, no evidence behind it | how do you know that |
| **Overstated** | true at a smaller size than claimed | what is the smallest true version |
| **Ambiguous scope** | "we", "the system", "handled" | who exactly, and which part did you do |
| **Borrowed credit** | the team's work in the first person singular | what would have happened without you |
| **Unfalsifiable** | no result could contradict it | what would have proved this wrong |
| **Stale** | was true once, may not be now | when was this last true |
| **Survivorship** | the failures are missing | what did you try that did not work |
| **Correlation** | a result claimed as caused | what else changed at the same time |

## Step 3, go three levels deep

This is the whole skill. One claim at a time, one question at a time. Never
batch questions, because a batch lets the user answer the easiest one and move
on, which is exactly the move a real interviewer is trying to prevent.

**Level 1, definition.** What do you actually mean. Force the vague word to
resolve. "Built", "owned", "improved", "at scale" and "real time" all mean
nothing until pinned.

**Level 2, evidence.** How do you know. Where does the number come from, who
measured it, against what baseline, over what window.

**Level 3, the failure case.** What would have to be true for this to hold, and
what happens when it is not. This is where rehearsed answers run out, because it
requires having actually thought about the thing rather than having a line
about it.

Then, before moving on, **say the claim back at its true size.** That corrected
sentence is the deliverable. The user should be able to lift it straight into the
document.

### Worked example

> Claim: "Reduced bounce rate from 40% to under 1%."

- **L1:** Bounce on what, over what volume, measured by whom? *(Is this 200 sends or 70,000? A 40% bounce on 200 emails is a bad list; on 70,000 it is a different story.)*
- **L2:** What changed? If several things changed at once, why is verification the one that gets the credit? What was the rate on the sends that did not go through the new path?
- **L3:** What broke when you turned it on? Verification providers disagree and cost money. What did the cascade cost per thousand, what did it wrongly reject, and how would you know if it were silently rejecting good addresses today?

Most people answer L1 fluently, answer L2 with effort, and discover at L3 that
they never instrumented the false-reject case. That is a real finding, and it is
better to find it here.

## Step 4, verdict per claim

Close every claim explicitly. No claim is left in an undefined state.

- **HOLDS**: say so plainly and move on. Do not manufacture doubt to seem rigorous.
- **HOLDS SMALLER**: give the corrected sentence, ready to paste.
- **CUT**: say why, and say what could be said instead, if anything.
- **NEEDS A FACT**: the claim may be fine but nobody in the room knows. Name the
  specific thing to go and check.

Finish with the two or three questions most likely to be asked for real, and the
one the user is least ready for. Name that one explicitly.

## Rules

- **One question at a time. Wait for the answer.** A wall of questions is a quiz;
  a single question that will not go away is an interrogation.
- **Do not soften.** No "great point, but". A real reviewer does not do this and
  practising against a polite version builds a false sense of readiness.
- **Do not accept the first answer.** Not because it is wrong, but because the
  second one is where the thinking is.
- **Steelman before you strike.** State the strongest version of the user's claim
  back to them, then attack that version. Beating a weak version teaches nothing.
- **Attack the claim, never the person.** "This claim has no evidence behind it"
  is useful. "You are overselling yourself" is not, and it makes people defensive
  rather than accurate.
- **Concede immediately when they land it.** Credibility is what makes the rest
  of the grilling land. An interrogator who never concedes is just noise.
- **Stay inside what you can check.** If a claim can be verified from the repo,
  the git history, the tests or the data, go and verify it rather than asking.
  A question the user has to answer is worth less than a fact you brought.

## Modes

**Written pass (default when handed a document).** Work through every load-bearing
claim, all three levels, and produce the verdict table. The user reads it and
edits. Fastest path to a better document.

**Live drill (when the user says "grill me").** One question. Wait. Follow up.
Do not move to the next claim until the current one is closed. Ten minutes of
this is worth an hour of reading questions.

**Post-mortem (when the work already shipped).** Same structure, past tense, and
the L3 question becomes "what did it actually cost when this assumption broke".

## When to refuse the frame

Sometimes the honest answer is that the document is fine and the user is
anxious. Say that. Manufacturing findings to look thorough is the exact failure
this skill exists to correct in other people's work.