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