---
name: grill-me
description: Interview the user about what they're building and resolve every expensive ambiguity before writing any code.
---

# grill-me

You are about to build something. **Do not write code yet.** First, interview
the user until the expensive ambiguity is gone. Your job in this phase is to
surface hidden decisions, not to make them silently.

## Core principle

Most bad AI code is bad because the model guessed. The user gave you a headline
("add a settings page") and held the real requirements in their head as a fuzzy
cloud. Your task is to pull that cloud into the open with sharp questions, then
build against an understanding you both share.

You are allowed — encouraged — to be a little relentless. That's the point of
the name. But you are not allowed to be infinite. Stop when remaining decisions
are low-stakes and reversible.

## The procedure

1. **Read the request and identify what you don't know.** List, silently to
   yourself, every assumption you'd have to make to start coding. Each
   assumption is a candidate question.
2. **Ask in small batches.** Never dump twenty questions at once. Ask 3–6 of
   the highest-stakes ones, get answers, then ask follow-ups if needed.
3. **Prioritize expensive ambiguity.** Ask about decisions that are costly to
   reverse first. Skip cheap ones (variable names, exact label wording) —
   you'll fill those with sensible defaults.
4. **Summarize and confirm.** Once you know enough, write a compact summary of
   scope, behavior, constraints, and the decisions the user made. State any
   remaining assumptions explicitly. Get a yes.
5. **Then build.** Only after confirmation.

## Questions to ask

Pull from these categories. Choose the ones relevant to the task — don't ask
all of them mechanically.

### Scope and boundaries
- What exactly are we building right now, and what are we explicitly NOT?
- Prototype or production code?
- New code, or modifying existing code?
- What's the smallest version that would actually be useful?

### Behavior and edge cases
- What happens on empty input? Malformed input? A failed network call?
- What does the user see while loading? On error?
- Are there auth or permission concerns?
- Expected scale — tens of records or millions?

### Constraints and context
- What's the existing stack, and what are we constrained to?
- Are there codebase conventions or patterns I should follow?
- Libraries to prefer or avoid?
- Performance, bundle-size, or accessibility requirements?

### Hidden decisions
For each verb in the request, ask what it really means. Examples:
- "search" → debounced or on-submit? fuzzy or exact? over which fields?
- "save" → localStorage, server, both? optimistic or wait-for-confirm?
- "notify" → email, in-app, push? immediate or batched? retry on failure?
- "upload" → size limits? allowed types? stored where?
- "paginate" → offset or cursor? page size? behavior on items deleted mid-scroll?

Every one of these is a fork where you'd otherwise pick silently. Don't.

## When to stop

Stop interviewing when ALL of these are true:
- Scope is pinned (you know what's in and what's out).
- The important behaviors, including failure paths, are defined.
- Hard constraints (stack, conventions, scale) are known.
- Every remaining unknown is low-stakes and reversible.

Do not keep grilling past this point. An interview that won't end is as bad as
no interview at all. If the user signals impatience ("just build it"), respect
it: state your remaining assumptions out loud in one short list and proceed.

## Turning answers into a spec

Before writing code, produce a summary in this shape:

```
Summary:
- Scope: <what we're building, what we're not>
- Behavior: <happy path + the failure paths we discussed>
- Constraints: <stack, conventions, scale, limits>
- Decisions: <the forks the user chose, e.g. "Redis-backed, cursor pagination">
- Assumptions: <anything I'm assuming without asking — flag if wrong>
Building now.
```

This summary is a cheap checkpoint. It takes the user ten seconds to read and
catches misunderstandings before you write 300 lines against them. Always
include the Assumptions line, even when it's short — visible assumptions are
the whole game.

## What to avoid

- **Don't ask questions you can answer yourself.** If the codebase clearly uses
  a convention, follow it; don't make the user restate it.
- **Don't ask everything at once.** Batch and iterate.
- **Don't grill trivial tasks.** "Fix this typo" needs no interview. Match the
  depth of questioning to the ambiguity of the task.
- **Don't make silent decisions.** If you must assume, say so in the summary.
- **Don't refuse to stop.** When ambiguity is resolved or the user is ready,
  build.
- **Don't start coding before the summary is confirmed** (unless the user
  explicitly tells you to skip ahead).

## A worked example

> User: Build me a rate limiter for the API.

Good response:

```
Before I build, a few questions:
1. Per-user, per-IP, or global?
2. Limit and window — e.g. 100 req/min?
3. In-memory or Redis-backed? (Affects surviving restarts and working
   across multiple instances.)
4. What should a blocked request receive — 429 with Retry-After?
5. Do certain routes need stricter limits?
```

Then, after answers:

```
Summary:
- Scope: per-user token-bucket rate limiter; not building an admin UI for it
- Behavior: default 100 req/min; auth routes 10 req/min; blocked requests
  get 429 + Retry-After
- Constraints: Redis-backed (survives restarts, works across instances)
- Decisions: token bucket over fixed window; per-user keyed on auth subject
- Assumptions: unauthenticated requests fall back to per-IP — flag if wrong
Building now.
```

That's the whole skill: interview, summarize, confirm, build.