用途：在任何创作性工作开始前（新功能、行为变更、架构决策或非平凡计划），grill 用于把粗略想法打磨成经用户批准的设计，在设计与理解确认前不写代码。用户说 grill、grill-me、brainstorm、pressure-test、help me design 时触发。不适用场景：根因已知的纯 bugfix、机械式改名、已有书面规格待写计划或发布。
核心原则：人拥有决策权，仓库拥有事实。事实去环境里查，只把决策交给用户；设计未确认前不实现。
铁律（不可违背）：每条消息只问一个问题；每个选项必须带顺序字母标记 A/B/C/D…；每个多选问题必须恰好标出一个推荐项；每个选项要用一句话同时说清产品体验影响与具体技术机制；用户确认共同理解前不做实现（不写代码、不搭脚手架）；事实查环境，决策问用户。
沟通方式：面向同时是构建者与产品重度使用者的单一对象——每个选项既要给出产品价值（体验得到、等待或失去什么），又要保持技术精度（点名真实机制、技术选择与取舍）。不要只堆术语，也不要只说“更简单更快”的空话。
Cursor 中若存在 AskQuestion 工具，固定选项问题一律使用它：每条助手消息至多一次，选项标签以 A) / B) / C) 开头，最多一个逃生选项（如 D) Something else），推荐项须在选项文本中标出并附一行简短的 prose 推荐。
工作流：宣告“Using grill to …”，按清单逐项完成——探索上下文、范围检查、逐题打磨决策树、提出 2–3 个方案（价值与机制挂钩并标推荐）、分节呈现设计并逐节获批、明确确认共同理解、交接（默认 write-spec，除非用户放弃；有新模块/端口/IO 边界才走 solid；再 write-plan、tdd）。grill 本身不运行完整的 solid 清单。
决策树循环：事实查环境，决策一次一问，等回答再问下一个，挑战软假设，直到能用几条清晰要点总结出用户认可的设计。提问前先做一次决定预览（列出整条清单的形状，不含答案），问完后做一次真实的复查而非脚本式“还有别的吗”。
限制：官方文本未提供更多细节，价格、平台与效果暂未提供。