Grill With Docs

---
name: grill-with-docs
description: 追问澄清（带文档）：像面试一样边问边沉淀文档——术语写进 CONTEXT.md 术语表、难以逆转的决策记成 ADR。边界/边缘情况由 AI 判断并推荐，用户只做确认。当需要边问边产出项目文档时使用。A relentless interview that also writes CONTEXT.md and ADRs as it goes.
---

# 追问澄清（带文档）

Run a `/grilling` session, using the `/domain-modeling` skill.

## 与 grill-me 的区别

- `grill-me` 只问不记（stateless）。
- `grill-with-docs` 边问边沉淀（stateful）：术语写进 `CONTEXT.md`（术语表，用 domain-modeling 的 CONTEXT-FORMAT 格式）；难以逆转、需要解释的决策记成 ADR（用 domain-modeling 的 ADR-FORMAT 格式）。

## 边界条件（edge cases）的处理

非开发人员无法判断边界/边缘情况。这是你的工作，不是用户的：

- 边界情况包括：空态、加载中、部分数据、出错、无权限、离线、撤销、取消、返回再访、重复提交、极端输入等。
- 由**你**判断并**推荐**关键边界条件，不要问用户「还有哪些边界情况」这类开放问题。
- 把你推荐的边界条件写进 `CONTEXT.md` 或 ADR，作为「已达成共识的假设」，让用户只做「确认 / 微调」，不做开放式判断。
- 用户只需要回答他们能答的：目标用户、痛点、成功标准、偏好；其余你补齐并记录。

## 追问范围（面向非开发人员，务必遵守）

你只问「产品 / 需求」问题，**绝不问「开发 / 技术」问题**。技术决策、术语定义、边界条件都由你判断并推荐，用户只确认。

✅ 可以问（产品 / 需求）：
- 给谁用（目标用户）、他们的使用场景和痛点
- 核心想解决什么问题、为什么现在做
- 怎样算成功（用户能看到的结果）
- 风格 / 调性偏好（正式 / 活泼、简洁 / 丰富等）
- 范围与优先级（哪些必须有、哪些可以以后再说）
- 预算、时间、约束（仅当用户主动提到）

❌ 不要问（开发 / 技术，由你决定）：
- 用什么技术栈 / 框架 / 语言
- 接口、数据结构、架构、模块怎么拆
- 怎么写测试、测什么、用什么工具
- 边界 / 异常情况怎么处理（见「边界条件」节，你推荐并落档）

⚠️ 例外：部署 / 上线需要问用户要「资源」（不是问技术方案）：
- 部署的技术方案（用 `deploy-to-vercel`、怎么配）由你决定；
- 但上线所需的**资源 / 账号 / 凭证**必须问用户提供：Vercel 账号登录、GitHub 授权、
  Token、域名、环境变量（API Key 等）——这些只有用户有，你无法自己搞定；
- 到「上线」那一步时，主动告诉用户需要他提供什么（账号 / Token / 域名），
  并给出一步步怎么提供的指引；技术配置仍由你完成。

对模糊术语：**由你提出一个明确的中文定义并写进 `CONTEXT.md`**，让用户「确认 / 微调」，不要让用户来定义技术名词。`domain-modeling` 只用来**你内部**把术语和决策落档，不要拿术语辨析题去问用户。