第一课完成安装和项目初始化后，Agent 已经知道工单放在哪里、标签怎么用、领域文档从哪里读。接下来终于可以谈需求了。但先别急着让它写规格，更别急着生成代码。“给用户加一个取消订阅入口”“后台支持批量导出”“订单失败后自动重试”，这些话听起来都像需求，实际上只说了一个方向。业务术语、状态变化、异常路径和验收边界还没有被讲清楚。此时 Agent 写得越快，通常只是把猜测更快地变成代码。第二课只解决一个问题：怎样用/grill-with-docs让 Agent 一次问清一个关键决定，并把已经达成共识的术语和架构选择立即写进项目文档。/grill-with-docs到底在做什么这个 skill 不是普通的需求问卷，也不是帮你生成 PRD。它把两种能力组合在一起：/grilling 负责沿着决策树追问，一次只问一个问题 /domain-modeling 负责校准术语，并把结论写入 CONTEXT.md 或 ADR前者让需求变清楚，后者让共识不会随着对话窗口一起消失。完整的工程链路是：grill-with-docs - to-spec - to-tickets - implement - code-review/grill-with-docs位于最前面。它负责把模糊需求问清楚；下一课的/to-spec才负责把已经谈清楚的内容整理成规格。两者不能反过来，否则规格只是把模糊表达排版得更正式。哪些需求值得先 grill不是每个改动都要开一场长访谈。下面几类需求最值得使用：产品只给出目标，没有说明状态变化和验收边界；同一个词在产品、运营和代码里含义不一致；会改变多个业务对象、权限规则或上下游系统；团队正在争论方案，但真正的分歧还没有被说出来；需求里出现“自
