# Grill Me

针对方案或设计的高强度追问式面试（adversarial design review / grill...

- Repository: https://github.com/feiskyer/claude-code-settings (1668 stars)
- Category: Design
- License: MIT
- Last updated: 2026-09-27
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add feiskyer/claude-code-settings --skill grill-me -g -a claude-code -y`
Codex: `npx skills add feiskyer/claude-code-settings --skill grill-me -g -a codex -y`
Cursor: `npx skills add feiskyer/claude-code-settings --skill grill-me -g -a cursor -y`
Gemini CLI: `npx skills add feiskyer/claude-code-settings --skill grill-me -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add feiskyer/claude-code-settings`

## Description

针对方案或设计的高强度追问式面试（adversarial design review / grill session），暴露假设漏洞与缺失约束，过程中同步维护领域模型（术语表和 ADR）。手动调用 /grill-me。

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 追问会话

## 启动步骤

触发后，先执行以下检查：
1. 检查项目根目录是否已有 `CONTEXT.md` 或 `CONTEXT-MAP.md`，有则读取
2. 检查 `docs/adr/` 是否已有 ADR 记录，有则了解已有决策
3. 然后开始追问

## 核心规则

针对方案的每一个方面进行不留死角的追问，直到我们达成共识。沿着设计决策树逐一走下去，逐条解决决策之间的依赖关系。每个问题给出你的推荐答案。

一次只问一个问题，等我回复后再继续下一个。一次抛出多个问题会让人无所适从。

如果某个事实可以通过探索代码库获得，就直接查找，不要问我。但决策权在我, , 每个决策都提给我，等我回答。

**在我明确确认达成共识之前，不要开始执行方案。**

---

# 领域建模（内置流程）

追问过程中，一旦有决策结晶，就立即建立和完善项目的领域模型, , 挑战术语、构造边界场景、在第一时间写下术语表和决策记录。

## 文件结构

大多数仓库只有单一上下文：

```
/
├── CONTEXT.md
├── docs/
│   └── adr/
│       ├── 0001-event-sourced-orders.md
│       └── 0002-postgres-for-write-model.md
└── src/
```

如果根目录存在 `CONTEXT-MAP.md`，则表示仓库有多个上下文，地图指向各自位置：

```
/
├── CONTEXT-MAP.md
├── docs/
│   └── adr/                          ← 系统级决策
├── src/
│   ├── ordering/
│   │   ├── CONTEXT.md
│   │   └── docs/adr/                 ← 上下文专属决策
│   └── billing/
│       ├── CONTEXT.md
│       └── docs/adr/
```

懒创建, , 只在有内容可写时才创建文件。如果 `CONTEXT.md` 不存在，在第一个术语确定时创建它。如果 `docs/adr/` 不存在，在第一个 ADR 需要时创建它。

## 追问过程中的行为

### 对照术语表质疑

当用户使用的术语与 `CONTEXT.md` 中已有定义冲突时，立即指出："你的术语表把'取消'定义为 X，但你现在似乎是指 Y, , 到底是哪个？"

### 磨尖模糊表达

当用户使用含糊或多义的词汇时，提出精确的规范术语："你说的'账户', , 是指 Customer 还是 User？这是两个不同概念。"

### 讨论具体场景

讨论领域关系时，用具体场景压力测试。构造探索边界条件的场景，迫使用户精确界定概念之间的边界。

### 与代码交叉验证

当用户陈述某物如何运作时，检查代码是否一致。如果发现矛盾，立即暴露："你的代码取消的是整个 Order，但你刚说可以部分取消, , 哪个是对的？"

### 即时更新 CONTEXT.md

术语一旦敲定，立即更新 `CONTEXT.md`，不要攒着批量处理。格式参见下方「CONTEXT.md 格式」章节。

`CONTEXT.md` 必须完全不含实现细节。不要把它当规格文档、草稿本或实现决策仓库。它只是术语表。

### 审慎提供 ADR

仅当以下三条全部成立时才创建 ADR：

1. **难以逆转**, 将来改变主意的代价可观
2. **缺乏上下文则令人费解**, 未来读者会困惑"为什么这样做？"
3. **确实是权衡的结果**, 存在真正的替代方案，且你基于具体理由选了其一

---

# 参考：CONTEXT.md 格式

## 结构

```md
# {上下文名称}

{一两句话描述这个上下文是什么、为什么存在。}

## 语言

**订单（Order）**:
{一两句话定义该术语}
_避免使用_: Purchase, transaction

**发票（Invoice）**:
向客户发送的交付后付款请求。
_避免使用_: Bill, payment request

**客户（Customer）**:
下订单的个人或组织。
_避免使用_: Client, buyer, account
```

> 注：示例语言应跟随项目主语言。中文项目用中文术语，英文项目用英文术语。

## 规则

The rest: https://github.com/feiskyer/claude-code-settings/blob/HEAD/skills/grill-me/SKILL.md