# Grill Me

> Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

- Skill: `code-shock/grill-me` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add code-shock/grill-me`
- Raw SKILL.md: https://api.skillmd.com/api/skills/code-shock/grill-me/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Code-Shock (https://skillmd.com/u/code-shock)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/code-shock/grill-me

---



Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.

Ask the questions one at a time.

If a question can be answered by exploring the codebase, explore the codebase instead.

## Domain awareness

Only applies when grilling about a codebase. If there's no codebase (a plan, a doc, a personal decision), skip this section and grill normally.

**At the start, look for the project's terminology docs:**

- `CONTEXT.md` — the project's glossary / ubiquitous language. Check the repo root, then `docs/domain/`.
- `CONTEXT-MAP.md` (and a `SHARED-KERNEL.md`, if the project has a hub) — present only in multi-repo projects. The map shows how this repo relates to the others; terms owned elsewhere are defined in their owner repo.

**If those docs exist, grill with them:**

- **Speak the documented language.** Use the canonical terms; don't invent synonyms for things that already have a name.
- **Challenge my words against the glossary.** If I use a term that conflicts with `CONTEXT.md`, or a vague/overloaded term, stop and resolve it: *"Your glossary defines X as Y, but you seem to mean Z — which is it?"*
- **Respect ownership.** If a term is owned by another repo (per `SHARED-KERNEL.md` / `CONTEXT-MAP.md`), its definition is fixed here — flag any attempt to redefine it locally.
- **Cross-check with code.** If I describe behavior the code contradicts, surface it.
- **Update the glossary inline.** The moment we sharpen or settle a term, write it into `CONTEXT.md` then and there — don't batch it. Keep `CONTEXT.md` a glossary only: what each term *is*, no implementation detail.

**If there's a codebase but no terminology docs:** once we've sharpened our first real term, offer — once, no nagging — to start the glossary with `/terms`.

**Where outputs go:** the plan and decisions from this session become **GitHub issues** (the work to do). Terminology stays in `CONTEXT.md`. A decision that's hard to reverse, surprising without context, and the result of a real trade-off becomes an ADR in `docs/adr/` — offer those sparingly.