grill-me

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（需求规约）