ctx-grilllisted

# ctx-grill 一场把方案问到「达成共识」为止的访谈。与通用 grilling 的差异有三：提问前先读已有 contexts、问题按「答案会不会改变方案方向」排序、敲定的决策写回持久层从此不再被问第二遍。访谈引擎改编自 [mattpocock/skills](https://github.com/mattpocock/skills) 的 `grilling`（MIT）。 **语言**：跟随用户的语言。 ## 步骤 1. **落地**：读与本方案相关的 context 条目，把已有结论分成三类：已决定（绝不再问——引用文件即可）、有假设但未验证（低成本确认一下）、真正开放（这就是问题池）。 2. **访谈**：沿决策树逐支走下去，把决策之间的依赖一个一个解开。一次只问一个问题，等到回复再问下一个。这个 skill 在边际收益递减处就停，不追求把树问空，所以问题总数本来就少，批量提问省不下多少，代价却是实在的：同一轮里可能凑上两个其实互相依赖的问题。每个问题都给出你的推荐答案、这个推荐立在什么之上、以及什么会推翻它。不要附置信度分数，它没法核对，读起来却比它实际的分量更权威。凡是*事实*（文件系统、工具、文档能查到的），自己去查而不是问；*决策*属于用户——逐个摆到用户面前，等答复。 3. **边问边排序**：分支按「答案会不会改变方案方向」取用；同一分支内按依赖顺序走。每得到一个回答就重排——一个回答可能重塑整棵树。 4. **边际收益递减即停**：当剩余问题都不会再改变方案方向时就停。点名哪些问题没问、为什么可以安全推迟——不要把每个分支磨到底。 5. **写回**：单向的、持久的决策在敲定的当下就用 `/to-ctx` 归档；小决策收尾时批量归档。结束时给出：磨尖后���方案、已归档的决策、推迟的开放项。 ## 规则 - 用户确认达成共识之前，不得着手执行方案。 - contexts 已回答的绝不再问；引用对应文件即可。 - 仅限交互场景：会话无法收到回答时（CI、循环、后台运行），拒绝执行并说明原因。 - 依赖方向：可以使用 `/to-ctx`；绝不调用面向用户的 skill。