Grill me
Relentless Socratic interview that walks down every branch of a plan or design, resolving decisions one-by-one. Trigger ONLY when the user explicitly says "grill me" or the PT equivalent "me grille". Do NOT trigger for stress-test, poke holes, devil's advocate, challenge, review, or feedback requests.From its SKILL.md
npx -y skills add ericgandrade/claude-superskills --skill grill-meAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its file declares
Copied from the file, not written here
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
3.5 KB, as published. Nobody here has run it
Grill Me
Purpose
Stress-test a plan, design, or idea through relentless Socratic questioning. Walk down every branch of the decision tree, resolve dependencies between decisions one-by-one, and reach a shared understanding where no assumption is left unchallenged.
When to Use
Trigger ONLY when the user explicitly uses the word "grill" — e.g.:
- "grill me on this"
- "grill me on my plan / architecture / design"
- "I want you to grill me before I present"
- PT: "me grille sobre esse plano"
Do NOT trigger for synonyms or near-misses, even when the intent seems similar:
- "stress-test this" → not grill-me
- "poke holes in my plan" → not grill-me
- "play devil's advocate" → not grill-me
- "challenge my assumptions" → not grill-me
- "pressure-test this" → not grill-me
- "review this and tell me what's wrong" → not grill-me
- "give me feedback" → not grill-me
Workflow
Step 0 — Understand the Subject
Read the plan, design, or idea the user has provided. If working in a codebase, explore relevant files before asking questions that can be answered by reading the code.
Step 1 — Build the Decision Tree (silent)
Before asking the first question, mentally map:
- Core decisions already made (what's locked in)
- Branches that are open or unresolved
- Dependencies between decisions
- Unstated assumptions worth surfacing
Step 2 — Interview Relentlessly
Ask one question at a time. For each question:
- Ask the question
- Provide your recommended answer with brief reasoning
- Wait for the user's response before moving on
Work through branches systematically — exhaust one thread before opening another. When an answer reveals a new sub-question, follow it immediately.
Question types to cycle through:
- Scope: What's in? What's explicitly out?
- Dependencies: What does this depend on that isn't defined yet?
- Failure modes: What breaks first under load / edge cases / bad inputs?
- Alternatives rejected: Why this approach and not X?
- Success criteria: How will you know this worked?
- Reversibility: What's hard to undo? What's the rollback plan?
- Ownership: Who owns each part when something goes wrong?
Step 3 — Resolve and Close
When all branches of the decision tree are resolved, summarize:
- Decisions confirmed
- Decisions changed or refined
- Open questions that remain (if any)
- Risks surfaced that need a mitigation plan
Critical Rules
- NEVER ask more than one question per turn
- ALWAYS provide your recommended answer alongside the question
- If a question can be answered by exploring the codebase, explore it instead of asking
- Follow threads to completion before opening new ones
- Push back on weak reasoning — don't accept "it should be fine" as an answer
- Surface assumptions the user didn't state but is implicitly relying on
Example Usage
- "Grill me on my microservices migration plan"
- "I want to stress-test this database schema before we build on it — grill me"
- "We're about to kick off this project. Grill me on the architecture."
- "I have a go-to-market plan. Pick it apart."
- "Grill me on this carve-out strategy before I write the plan"