How do I install the Grill Me skill?

Run npx skillmds@latest add code-shock/grill-me in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Grill Me safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Grill Me?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Grill Me free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Grill Me?

Code-Shock (@code-shock) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Grill Me by code-shock — Agent Skill

Name: Grill Me
Rating: 4.666666666666667 (3 reviews)
Author: Code-Shock

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".

Code-Shock Updated Sep 22, 2026

File contents

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.

---name: grill-medescription: 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".---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 awarenessOnly 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.

Frequently asked questions