| name | grill-me |
| description | 当用户要开始新功能/新项目/较大改动，或说"做个X""实现X""加个X"时使用。写代码前先审问式澄清需求，沿设计树逐枝丫一次问一题。防返工。关键词：做、实现、加、改、重构、想做个。
|
grill-me — 动手前审问（需求澄清）
触发词
做个、实现、加个、帮我写、重构、想做个、开始做、新功能、新项目、盘问、审问、grill
概述
把 agent 从"你说啥我做啥"掰成"我提问你拍板"。在写一行代码前，沿设计树逐枝丫盘问，把用户脑子里模糊的念头逼成一份想明白的方案。
这是 SDD 流程的入口。完成后产出一份澄清后的需求，进入 spec 写需求规约。
何时该用 / 何时不该用
✅ 该用：
- 要花几小时、方向定错返工成本高的活
- 新功能、新项目、较大改动
- 用户只给了模糊一句话（"做个看板工具""加个登录"）
❌ 不该用：
- 改错别字、调颜色、加一眼看穿的小功能（直接做，别折磨用户）
- 一次性几十行小脚本（vibe coding 一把梭更快）
- 已有 spec/plan/tasks 的继续开发（直接进 implement）
工作流
0. 先翻家底，别急着问
收到任务后，先读代码库：
- 项目里是否已有相关模块/工具/依赖可复用
- 是否有
.agents/specs/ 下已有的相关规约
- 是否有
.agents/memory/ 里的相关进度/偏好
能自己查清楚的，绝不问用户。查清后把发现告诉用户："你手上其实已有 X，这事很可能不用从零写"。
1. 沿设计树逐枝丫提问
设计树（Fred Brooks）：每个决定都岔出更小的决定。上游不定死，下游全是空中楼阁。
- 先问最上游、最模糊的大决定，钉死后再往下问
- 每问一个问题，同时给出你推荐的答案（用户从选项里挑，比从零想轻松）
- 一个枝丫定死，才进下一个
例：先问"这个工具给谁用、解决什么问题"，定死后再问"扒哪些平台"，定死后再问"一天推几条、几点推"。顺序乱了问了也白问。
2. 一次只问一个
- 问完必须等用户回话，才能问下一个
- 一次甩一堆问题只会把人问懵
- 用户回"不知道"时，把问题拆得更小，或给 2-3 个候选让他选
3. 每问给推荐答案
- 不要只抛问题，要给"我建议 X，因为 Y，你看行吗"
- 用户只需点头/否决/微调，不必从零构思
- 这是把"想清楚"的负担从用户转给 agent
4. 持续到想明白
- 一路问到"剩下的事都能合理推断、不再有藏着的歧义"
- 典型要问清的维度（按设计树顺序，非全列）：
- 给谁用、解决什么核心痛点
- 必须有什么、明确不做什么（边界）
- 输入从哪来、输出到哪去、谁消费
- 失败/异常怎么处理
- 是否要持久化、要不要跨会话记忆
- 性能/规模要求
- 中间揪出用户想不到的坑（如"这助手每天独立起跑，同一热点会不会连推三天"），主动提醒
5. 产出澄清后的需求摘要
问完后，用一段话 + 要点复述给用户确认：
- 目标（一句话）
- 范围（做什么 / 不做什么）
- 关键决定（逐条列）
- 待定项（如有）
用户确认后，主动建议：
需求已想明白。下一步建议进入 spec 写成正式需求规约（spec.md），再走 plan/tasks。要现在开始吗？
坑点清单（Gotchas）
- 一次问多个 = 把人问懵：哪怕你觉得问题相关，也一个个来。
- 顺序乱了白问：先问"扒哪些平台"再问"给谁用"，等于先买家具再定风格。上游优先。
- 不翻代码就问 = 烦人：能 grep/read 查清的（有没有现成轮子、字段叫什么）别问。
- 只问不给推荐 = 把构思甩给用户：每题都要带"我建议 X"。
- 问到一半用户说"差不多行了开始做"：把已澄清的部分固化，未定的用默认值并显式说明，进 spec。
- 用户坚持直接写代码：小活可放行，但说清"这次跳过规约，后续要扩展建议先补 spec"。
关键规则
- 绝不在 grill 完成前写任何业务代码（可写探查性脚本读代码）。
- 必须一次只问一个问题。
- 必须每问给推荐答案。
- 必须先翻代码库再问。
- 用户说"你看着办"时，把你的全套假设显式列出来让用户过一眼，不要默默选。
参考
- references/design_tree.md — 设计树概念详解与提问顺序示例
- 上游 skill：无（这是 SDD 链入口）
- 下游 skill：
spec（需求规约）
