grill-me: Let AI Interrogate You for 45 Minutes Before Coding — Save Countless Hours of Rework

A Familiar Development Dilemma

Have you ever had this experience: your plan is still a fuzzy blob in your head, but you can't resist jumping straight into coding — only to realize halfway through that you misunderstood the requirements or missed critical edge cases? Then you're forced to start over, which is even more exhausting than thinking it through from the beginning.

Almost every developer has fallen into this trap. The root cause usually isn't that AI or programmers can't write good code — it's that no one clearly defined what to write in the first place. Vague requirements naturally produce vague code.

The recently viral open-source skill grill-me (as in "grill me with questions"), which has been blowing up on platforms like Bilibili, offers a counterintuitive yet remarkably effective solution: before writing a single line of code, let AI interrogate your plan like an interviewer, questioning every decision from start to finish. This article provides a systematic overview of this skill's positioning, working mechanism, and best practices.

Why You Need to "Get Grilled by AI Before Coding"

The Three Costs of Starting with a Vague Plan

Let's start with the pain points. Jumping into implementation without a clear plan typically comes with three costs:

• Misunderstood requirements: The direction was wrong from the start, and you only realize it halfway through.
• Unexplored boundaries: The assumptions you relied on don't hold — permission boundaries, exception paths, and static conditions are all blind spots.
• Starting over: You're forced to rework everything, at a cost far higher than thinking it through upfront.

Here's a real scenario: you say "I need to add a multi-tenant RBAC permission system" and dive right in. Halfway through, you discover — tenant isolation level undefined, permission model not selected, historical data migration completely unconsidered. The only option is to throw everything out.

This example is typical because multi-tenant RBAC is inherently a domain with extremely high decision density. RBAC (Role-Based Access Control) achieves fine-grained access control by binding permissions to roles and assigning roles to users — it's one of the most mainstream permission management models in enterprise applications. Multi-Tenancy refers to a single software system simultaneously serving multiple independent customer organizations, with each tenant's data and configuration isolated from others. When RBAC meets multi-tenancy, complexity increases exponentially: you need to decide whether tenant isolation happens at the database level (separate schemas or separate databases) or the application level (shared tables + tenant_id field), whether permission roles are globally unified or customizable per tenant, and how cross-tenant operations (like platform administrators) are authorized. Failing to think through any of these branches can force a complete architectural restart.

The essential insight in one sentence: The most expensive bug is a decision that no one ever questioned.

Front-Loading Rework Cost as Thinking Cost

The value of grill-me can be summarized in four key points:

1. Method: AI acts like an interviewer, asking one question at a time, walking through every decision branch in your plan.
2. Effect: Problems like misunderstood requirements and unexplored boundaries surface before coding begins, not after.
3. Cost: A single grilling session takes 10 to 45 minutes — far cheaper than spending two days building the wrong thing.
4. Essence: Slow down now, front-load "rework cost" as "thinking cost."

Think of it as a safety inspector at a construction site — you can't just start building after designing a building. The inspector walks through the entire decision tree first, confirming every branch holds up.

Understanding grill-me: Positioning and Working Mechanism

grill-me has accumulated over 400,000 installations, standing out among a dozen similar skills as a truly phenomenal tool. Its core is a carefully designed set of rules and workflows.

Four Core Instructions + One Hidden Rule

The key instructions this skill gives to AI include:

• Walk the decision tree: Follow decision dependencies branch by branch, rather than asking random questions freestyle. The "decision tree" here isn't the classification algorithm from machine learning — it's a structured decision reasoning method. Starting from the initial problem, it expands branches layer by layer along dependency relationships, with each branch representing a decision point that needs judgment. Downstream decisions can only proceed after upstream decisions are confirmed. This approach is especially critical in software architecture design because technical decisions often have strong dependencies: for example, you must determine your data storage approach before designing a caching strategy, and confirm your authentication mechanism before designing a permission model. This instruction ensures AI doesn't ask questions in a random, jumping manner but advances layer by layer in logical dependency order, building each decision on confirmed premises.
• Provide your recommended answer: Every question comes with a recommended answer. You can simply say "no, that's not right" rather than thinking from scratch.
• Ask the questions one at a time: Avoids a barrage of seven questions simultaneously crashing the planning session.
• If the answer can be found by checking the codebase, AI checks it itself: Your attention is only spent on things that genuinely require your judgment.

This last rule — "let AI check the code for questions it can answer itself" — is a hidden rule and the key to a smooth experience. It ensures you won't be interrupted by meaningless trivial questions.

The Four Phases of a grill-me Session

A complete grilling session typically takes about 45 minutes and consists of four phases:

• Phase 1 · Read the Request: AI reads your plan, scans relevant code, and formulates the first question.
• Phase 2 · Foundation Branches: Data models, ownership, lifecycle, error handling — each addressed one by one with recommended answers for you to confirm or correct.
• Phase 3 · Edge Cases: Race conditions, partial failures, soundness boundaries — most surprises hide here. This phase is the most valuable because it targets the two most classic categories of challenges in distributed systems and concurrent programming. A Race Condition refers to the unpredictability that occurs when multiple processes or threads simultaneously access shared resources, where the final result depends on execution order — for example, two users modifying the same permission record simultaneously could cause data overwrites or inconsistency without proper locking mechanisms. Partial Failure is a challenge unique to distributed environments: an operation involves multiple services or steps, some succeed while others fail, leaving the system in an inconsistent intermediate state. For example, in an RBAC scenario, role creation succeeds but permission binding fails — how do you roll back or compensate? These edge cases are extremely difficult to reproduce in normal functional testing, yet they're a high-frequency source of production incidents — which is exactly why grill-me focuses on them in Phase 3.
• Phase 4 · Comprehensive Summary: With your decisions in hand, AI outputs the complete plan for you to approve or send back for another round.

Two interesting signals to watch for: A short conversation means the problem was well-defined from the start — no need to force it longer. A long conversation means you're discussing details that should be handled later — pause, write a small piece of code to validate, then come back.

Why grill-me Went Viral

Its explosive popularity comes down to three reasons:

First, it inverts the painful default. The default behavior of all coding agents is "eager helpfulness" — ask fewer questions, ship faster. It looks efficient but actually produces mountains of throwaway rewrite code. grill-me does the opposite, turning "slow down now, quality later" into a feature.

Second, it's a modernized rubber duck debugging. Rubber Duck Debugging is a classic problem-solving method in software engineering, widely popularized by Andrew Hunt and David Thomas in The Pragmatic Programmer (1999). The core idea is elegantly simple: when you can't solve a problem, try explaining it line by line to a rubber duck (or any inanimate object) — in the process of organizing your explanation, you often discover the issue yourself. The cognitive science principle behind this is called the "Self-Explanation Effect" — externalizing implicit thinking into explicit language forces the brain to re-examine every assumption. grill-me is the modern upgrade of this concept — an opinionated duck that follows up, pushes back, and transforms from a passive thinking mirror into an active thinking adversary.

Third, the cleverness of recommended answers. Most planning sessions stall at "I haven't decided yet." By forcing AI to provide a recommended answer first, saying "no, that's not right" moves things forward much faster than "hmm, I'm not sure yet" — the conversation never goes cold.

grill-me Installation and Practical Guide

One Command to Install

Installation is dead simple — one command plus a trigger phrase:

1. Install: Use npx skills add pointing to mattpocock's repository, specifying grill-me with the --skill parameter.
2. Trigger: Simply say "grill me" or type /grill-me.
3. Feed your plan: Paste your plan — for example, "add a multi-tenant RBAC permission system" — and AI starts rapid-fire questioning, one at a time.

Notably, it uses the universal SKILL.md portable format, compatible with mainstream tools like Claude Code, Cursor, and Codex. SKILL.md is an emerging, lightweight configuration format for defining AI coding assistant behavior rules. It's essentially a Markdown file that describes a skill's trigger words, system prompts, workflow steps, and constraints in a conventional structure. The elegant aspect of this design is cross-tool compatibility: whether you use Claude Code (Anthropic's official terminal coding tool), Cursor (a VS Code-based AI editor), or OpenAI's Codex CLI, as long as the tool supports reading SKILL.md files, the same skill definition works plug-and-play. This portability prevents ecosystem fragmentation — skill developers only need to maintain one definition, and users don't need to reconfigure for different tools. It reflects how AI toolchains are evolving toward "prompts as configuration, rules as code" — communities can share and compose AI behavior rules just like sharing npm packages.

A Real Grilling Conversation

Using "add multi-tenant RBAC" as an example: AI first checks existing schemas and authentication mechanisms, then starts questioning.

• Question 1: Tenant data isolation level? Recommends RLS + tenant_id logical isolation for minimal changes. You say "RLS works." The RLS (Row-Level Security) mentioned here is a built-in security mechanism provided by modern relational databases like PostgreSQL. It allows database administrators to define policies for tables that automatically filter rows returned by each query, ensuring users can only see and operate on data belonging to them. In multi-tenant scenarios, RLS is typically combined with a tenant_id field: the database layer enforces automatic WHERE tenant_id = current_tenant() filtering on every SELECT, INSERT, UPDATE, and DELETE through policies. Compared to manually appending tenant filters in application code, RLS offers higher security (even if the application layer misses a filter, data won't leak) with minimal invasiveness, though the trade-off is increased debugging complexity and special handling needed for cross-tenant queries.
• Question 2: How to handle cross-tenant shared data? Recommends public tables with explicit markers.

It continues one question at a time until no ambiguity remains in the plan.

Three practical tips: First, the most effective approach is to paste the PRD, issue, a block of text, or even an image directly — don't describe from memory. Second, it works across tools. Third, you can use it even without a complete plan — three to five sentences of rough ideas are enough to start. The rougher the input, the better it exposes problems early.

Use Cases Beyond Coding

Its applications are broad: technical design reviews (APIs, data models, architecture), plan refinement (grill a PRD or spec before putting pen to paper), and even non-coding decisions — like "which course should I build next" for topic selection, or simulating tough interview questions for preparation.

Four Golden Rules for Using grill-me

Let's close with four best practices:

1. Grill real plans: Paste the actual PRD — don't describe from memory.
2. Let AI check the code: Don't waste your attention answering things the codebase can resolve.
3. Push to the boundaries: The real value hides in exception paths you'd never think of.
4. Pause in time: If the conversation exceeds an hour, stop. Write a small piece of code to validate, then come back.

If you take away just one line from this article, I hope it's the insight that runs throughout:

The most expensive bug is a decision that no one ever questioned.

Next time before you start coding, spend ten or fifteen minutes letting AI put you through the wringer. What you save might be countless afternoons of rework.

Key Takeaways