grilling

逐项追问

持续询问用户，直到达成共识。逐一梳理决策树的每个分支和依赖项。一次只问一个问题——等待用户回答后再问下一个。可在环境中找到的事实：自行查找，切勿询问。决策由用户决定——逐项询问用户并等待回答。未经用户确认，不要采取行动。

命名：问题为 S«s»Q«q»，答案为 S«s»Q«q»A«n»。

步骤

1. resolve-store.sh path — 定位已克隆的存储库工具。解析路径，切勿克隆。若存储库未命名、无法解析或不存在，则以非零状态退出并说明应如何修复；若未命名 → 明确告知并且不记录任何内容（静默跳过无法与成功记录区分）。存储库 URL 仅存在于环境中——绝不硬编码，也绝不写入产物。

2. resolve-store.sh unmerged — 如果存在任何记录，则拒绝开启会话，直到负责人合并上一会话的记录，参见 recording.md。

3. resolve-store.sh preferences — 以 JSON 数组形式输出会话的 preferences 活跃集。复制即可，切勿重新输入。只注入该集合，绝不注入决策历史。

4. 将每个决策点编写为会话 JSON——包含答案在内的完整会话内容。规范见同目录下的 render/decision-context.ts；语义见 format.md。绝不手动编写问题格式；渲染器会自行附加自由文本栏。

5. 渲染两种面向用户的格式——若验证失败，会指出出错字段；修复 JSON 后重新运行：

   node --experimental-strip-types <skill-dir>/render/render.ts <session.json> --out <dir>
   

6. 将 session.html 作为产物发布；随着会话内容增长，在同一 URL 上重新部署。若无法使用 → 将 session.md 原样打印到聊天中——绝不作为文件附件，也绝不作为定时对话框（用户仍在输入时，对话框可能关闭）。

7. 用户可将页面复制的 JSON 粘贴到聊天中，也可直接在聊天中回复答案：答案 ID（"S1Q2A1" 或 "1"）；通过 "N, but actually because …" 进行更正——简写为 "N, BAB …"。目前尚无页面到 Agent 的实时通信通道（pandoscope/skills#139）。答案的含义见 reading.md。后续问题：追加新问题和已收到的答案，然后重新渲染；用户可以重新审视之前的答案。

8. 会话结束时，根据 recording.md，将每项裁定记录到存储库，并将拒绝理由嵌入会话的目标产物中。

9. check.sh <session.json> — 重新验证会话，确认引用与存储库中的原文一致；若记录仍未合并则失败，并打印待人工核验的剩余内容。

问题规则

• 选项 1 体现预测：若当前规则匹配（在 matches 中列出），则由偏好驱动；否则采用冷启动选择。不同的推荐放在选项 2；其 if 子句说明它在什么情况下优于选项 1。
• 仅当确实存在合理但尚未探索的分支时，才使用通配选项。
• if 子句说明选项何时优于推荐选项。只有当“为何不推荐”与 if 子句的否定内容不同时，才添加“为何不推荐”。
• 必须标明接近持平的情况；绝不为势均力敌的选项捏造缺点，也绝不将它们判为失误。
• 更正（"N, but actually because …"，简写为 "N, BAB …"）表示接受该选项，但以更正理由取代原先给出的理由——这是信号最强的事件；请在记录中标明。
• 只有当自由文本回答未说明拒绝理由时，才通过一个后续问题深入询问（提供 2–3 个排序后的猜测和自由文本栏）。猜测也算预测。

非目标

不自动接受偏好规则——始终由人在环路中。不要使用嵌入或 RAG 工具。不要与上游同步。