ctx-grill

name	ctx-grill
description	用一场带上下文的追问把方案、决策或想法拷问到位。适用于 /ctx-grill、「拷问这个方案」「帮我把方案过一遍问题」「压测一下我的思路」，或用户希望在动手前压测自己思路的场景。先读持久 contexts（已回答的绝不再问），按「答案会不会改变方向」逐个提问并附推荐答案，边际收益递减即停，敲定的决策写回归档。仅限交互场景——CI、循环等无人值守运行中绝不可调用。
metadata	{"short-description":"带上下文的方案拷问"}

ctx-grill

一场把方案问到「达成共识」为止的访谈。与通用 grilling 的差异有三：提问前先读已有 contexts、问题按「答案会不会改变方案方向」排序、敲定的决策写回持久层从此不再被问第二遍。访谈引擎改编自 mattpocock/skills 的 grilling（MIT）。

语言：跟随用户的语言。

步骤

1. 落地：读与本方案相关的 context 条目，把已有结论分成三类：已决定（绝不再问——引用文件即可）、有假设但未验证（低成本确认一下）、真正开放（这就是问题池）。
2. 访谈：沿决策树逐支走下去，把决策之间的依赖一个一个解开。一次只问一个问题，等到回复再问下一个。这个 skill 在边际收益递减处就停，不追求把树问空，所以问题总数本来就少，批量提问省不下多少，代价却是实在的：同一轮里可能凑上两个其实互相依赖的问题。每个问题都给出你的推荐答案、这个推荐立在什么之上、以及什么会推翻它。不要附置信度分数，它没法核对，读起来却比它实际的分量更权威。凡是事实（文件系统、工具、文档能查到的），自己去查而不是问；决策属于用户——逐个摆到用户面前，等答复。
3. 边问边排序：分支按「答案会不会改变方案方向」取用；同一分支内按依赖顺序走。每得到一个回答就重排——一个回答可能重塑整棵树。
4. 边际收益递减即停：当剩余问题都不会再改变方案方向时就停。点名哪些问题没问、为什么可以安全推迟——不要把每个分支磨到底。
5. 写回：单向的、持久的决策在敲定的当下就用 /to-ctx 归档；小决策收尾时批量归档。结束时给出：磨尖后的方案、已归档的决策、推迟的开放项。

规则

• 用户确认达成共识之前，不得着手执行方案。
• contexts 已回答的绝不再问；引用对应文件即可。
• 仅限交互场景：会话无法收到回答时（CI、循环、后台运行），拒绝执行并说明原因。
• 依赖方向：可以使用 /to-ctx；绝不调用面向用户的 skill。