grilling 与 grill-with-docs追问如何变成一种带文档的工作流原始 GitHub 文件grilling/SKILL.mdgrill-with-docs/SKILL.md配套依赖domain-modeling/SKILL.md这组 skill 实际上分得很清楚。grilling解决的是“怎么把一个方案问清楚”domain-modeling解决的是“讨论里哪些术语和决策应该沉淀成长期文档”grill-with-docs则把这两件事绑成一轮固定会话让追问不止停在口头理解而是顺手沉淀成可复用的上下文和决策记录。它不是第三套规则而是把前两套规则在同一个时刻打开。grilling把追问从态度压成协议先看grilling。如果要给它一个更稳定的中文工作定义我会把它写成围绕方案逐支下钻、逐项消依赖的压力测试式澄清。这个定义里有三层意思。第一它处理的是方案不是一般聊天第二它沿分支下钻不是平铺罗列问题第三它带压力测试性质不满足于“差不多说清”而要继续追到共享理解真正成立。无论是“拷打”“盘问”“追审”还是“逼问”都会把读者带到语气层而不是机制层。更稳的写法是保留grilling这个词同时在第一次出现时把它定义清楚它不是更凶的问答而是更彻底的方案压测。它最关键的地方不是正文写得多强硬而是 frontmatter 没有写disable-model-invocation: true。这说明它不是必须手动点名的重工作流而是一条可以被模型直接发现和触发的能力。因为“先把方案问清楚”本身就是一个独立需求用户可能明确说“帮我 grill 一下这个设计”模型也可能在准备实现前主动判断“这个方案还没压实应该先追问”。把这种工作方式翻译为中文 skill大致就是下面这样--- name: grilling description: 针对一份计划或设计进行不留情面的追问式访谈。用于在开始实现之前压测方案或当用户明确提到 “grill” 一类触发词时使用。 --- 就这份方案的每一个方面持续追问我直到我们形成共享理解。沿着设计树的每一个分支一路往下走逐个消解各项决策之间的依赖。每提出一个问题都给出你的建议答案。 一次只问一个问题等这个问题得到反馈后再继续下一个。一次抛出多个问题会让人难以跟上。 如果某个问题可以通过探索代码库得到答案那就直接去探索代码库而不是反过来问我。这份正文虽然短但每一句都在拦一个常见的失控点。第一句解决的是问题深度。这里最重要的不是“relentlessly”那种语气而是“沿着设计树的每一个分支一路往下走”。它把方案理解成一棵不断分叉的决策树而不是一页平铺的需求摘要。只问顶层问题方案看上去会很完整顺着分支往下走才会暴露出依赖、边界、默认值和回滚方式这些真正决定实现质量的东西。所谓grilling不是把同一个问题问得更凶而是承认每个决定下面还挂着一串没被说清的小决定。第二句解决的是问题节奏。一次只问一个等对方反馈后再继续这不是礼貌问题而是信息带宽问题。多个问题同时抛出回答者通常会挑容易的先答把难题延后最后讨论会看上去很热闹真正关键的分支却一直没有走到底。原文把这种感觉写成bewildering很准确不是单纯“多”而是让人失去跟踪能力。grilling把节奏收窄到“一次只推进一个分支”其实是在给高密度讨论强行加上顺序。“每提出一个问题都给出你的建议答案”也很关键。它把追问从“请你来补完”改成“我先给出一个候选判断你来校正”。这样做有两个效果一是回答成本更低对方不需要从空白处起草二是分歧暴露得更快因为用户可以直接说“不是这个方向”。很多讨论效率低不是因为没人思考而是因为双方都在等对方先落一个可反驳的具体判断。最后一句解决的是证据来源。能从代码库确认的问题就不要反手丢给用户。这条纪律把grilling和盘问区分开了。盘问是在把负担推出去追问是在把灰区压实。只要答案客观存在于代码、配置或现有文档里模型就应该自己去拿证据而不是把“找事实”伪装成“请你澄清”。这也是为什么grilling能单独成立它不是一套问话模板而是一套围绕追问深度、节奏和证据来源组织起来的工作协议。grill-with-docs它新增的不是内容而是组合关系grill-with-docs一上来就和grilling拉开了边界。它明确写了disable-model-invocation: true也就是关闭模型自动触发。这不是细节而是整条 skill 的性质声明。grilling是日常可直接启用的能力grill-with-docs则是一种更重的工作模式不仅要把方案问透还要顺手把术语和关键决策写成长期材料。这种模式很有价值但默认常驻会过度治理所以必须改成用户手动开启。把它压成中文 skill正文其实只需要这么薄--- name: grill-with-docs description: 一次不留情面的追问式访谈用来打磨方案或设计并在推进过程中同步产出文档ADR 和术语表。 disable-model-invocation: true --- 发起一次 /grilling 会话并在过程中配合使用 /domain-modeling skill。这条 skill 的设计思想恰好就藏在这份“薄”里。它不重新定义提问节奏因为提问节奏已经由grilling规定它不重写术语和 ADR 纪律因为那是domain-modeling的职责它只增加一件事让一次追问会话从一开始就带着文档沉淀的轨道运行。换句话说grill-with-docs自己不拥有一套新的正文规则它拥有的是一条组合规则。这也是它为什么必须短。组合 skill 一旦开始复述上游 skill 的正文就会立刻出现三个问题。第一是重复grilling或domain-modeling一改这里也得跟着改。第二是失焦读者会误以为grill-with-docs还有第三套自己的行为规则。第三是边界变乱到底什么属于追问什么属于文档纪律会在重复抄写中慢慢混掉。最稳的写法就是像现在这样只声明组合身份、触发边界和调用关系。如果把grilling看成“把想法逼清楚”那grill-with-docs解决的就不是更深一层的追问而是更重一层的交付。前者的终点是共享理解后者的终点是共享理解加可复用文档。这两者不是强弱关系而是不同的完成定义。domain-modeling在这里为什么是配套依赖domain-modeling在这组关系里不是主角但没有它grill-with-docs又会失去落盘的纪律。它负责的不是追问而是把讨论里真正稳定下来的东西筛出来术语一旦说清就更新CONTEXT.md决策只有在“难回退、没有上下文会让后来人意外、而且确实经过权衡”时才写进 ADR文档记录的是领域语言和关键判断而不是实现细节流水账。这部分能力非常重要但不适合在这里整份展开。原因不只是篇幅而是主轴。当前这篇的主问题是为什么grill-with-docs可以写得这么薄而且薄得合理。要回答这个问题只需要交代domain-modeling在组合里的职责不需要把它自己的格式文件和完整协议全部带进来。否则文章会从“两条 skill 的分工关系”滑向“三条 skill 的并列讲解”主线会被打散。所以把domain-modeling放在这里作为配套依赖正好能把边界说清它不是负责把方案问透的人而是负责把已经问透的东西变成长期上下文的人。这组 skill 真正值得学的设计思想把grilling、grill-with-docs和domain-modeling放在一起看最值得学的不是某句 prompt 怎么写而是它们对能力分层的处理。第一层把一个可以独立成立的核心动作单独做成 skill。grilling之所以能成立是因为“把方案问清楚”本身就是一个稳定需求它不需要文档沉淀才有价值。第二层把更重的工作流写成组合 skill并且显式关闭自动触发。grill-with-docs不是更通用而是更重。重工作流默认自动启动通常不是增强而是打扰。第三层组合 skill 只写新增关系不重复上游规则。真正稳定的组合不靠把上游 skill 的正文重新抄一遍而靠把职责切清之后只保留“谁和谁一起运行”这条新增信息。因此grill-with-docs看上去像一句话实际上压缩的是一套很完整的设计判断追问可以独立触发文档沉淀有专门纪律而两者的组合只在用户明确需要时启动。理解了这层分工它的“薄”就不再像偷懒反而像一次很克制的工程表达。