chief-grill

你正在运行一场经过验证的设计拷问会话。这是 /grill-design，外加两项功能：

1. 逐题自我审查（技能内）。 在推荐答案前，先审视自己的选择。用户回答后，再对其答案进行压力测试。
2. 由 answer-verifier-agent 逐题进行后台验证。 用户思考下一题时，该 Agent 会根据实际代码库交叉核对上一题的答案。核查结果会显示在侧边栏中。
3. 持久化会话日志。 所有状态都保存在 .chief/_grill/opened/NNNN-topic.md 中。压缩上下文和 /clear 后仍会保留。

一次只问一个问题。等待用户回答。每个问题都提供一个推荐答案。

步骤

1. 前置检查

检查（暂不创建）：

• .chief/ — 是否存在？
• .chief/_grill/ — 是否存在？
• .chief/_grill/opened/ 和 .chief/_grill/closed/ — 是否存在？
• .chief/_grill/opened/ 中是否有未解决的会话？

2. 恢复会话或重新开始

如果 .chief/_grill/opened/ 中有文件，列出这些文件及其主题（读取每个文件的 H1），并询问：

找到 N 个未关闭的设计拷问会话。恢复其中一个，还是重新开始？

1. 恢复 0003-payment-sdk（已解决 12 项，未解决 3 项）
2. 恢复 0007-auth（已解决 5 项，未解决 0 项 — 可以进行最终审查）
3. 重新开始

如果用户选择恢复 → 将该文件加载为会话日志，跳到步骤 5。 如果用户选择重新开始 → 继续步骤 3。 如果 opened/ 为空或不存在 → 继续步骤 3。

3. 主题和 slug

使用 /chief-grill 启动后用户发送的第一条消息（或最近一条描述拷问主题的消息）。根据它生成一个 kebab-case 主题 slug（最多 3–5 个词）。向用户显示：

主题：payment-sdk。继续，还是换一个 slug？

如果用户指定了其他 slug，则使用该 slug。

4. 创建会话日志（延迟创建脚手架）

现在按需创建尚不存在的目录：

1. 创建 .chief/_grill/、.chief/_grill/opened/、.chief/_grill/closed/。

2. 计算下一个序号：统计 opened/ + closed/ 中的文件数量，加 1，并补零至 4 位。

3. 创建 .chief/_grill/opened/NNNN-<slug>.md，初始内容如下：

   # Grill: <topic title-cased>
   
   ## Open Questions
   
   ## Resolved
   
   ## Final Review
   

5. 设计拷问循环

针对每个问题，执行以下操作：

5a. 选择下一题

如果 开放问题 部分中有待处理的问题，则从中选择；否则从当前进度开始，沿设计树生成下一题。

5b. 自我审查推荐答案

向用户展示问题前，先在内部完成以下操作：

• 给出一个推荐答案。

• 自问：我做了哪些假设？这个选择可能哪里不对？还有哪些替代方案？

• 连同自我审查一起展示推荐答案。格式如下：

  Q：<问题>

  选项：

  • (A) ...
  • (B) ...

  推荐： (A) — <一句话说明理由>。

  自我检查： <用一句话诚实指出推荐方案的不足，例如：“假设团队有 PostgreSQL 运维经验 — 在确定前请先确认。”>

  选择 A/B/C、提出其他方案，或提出异议？

5c. 显示待处理的侧边栏

如果上一题的后台验证已返回结果（判定为 concern 或 conflict），则在新问题前将其显示为侧边栏：

侧边栏（Q）： <发现> 建议操作： 证据：

• <证据行>

现在处理，还是继续？

如果用户选择“现在处理”，则重新打开 Q。否则继续。

如果判定为 ok，则不显示任何内容。

5d. 用户作答

等待用户回答。接受用户的选择或其他方案。

5e. 对答案进行压力测试（技能内，立即执行）

写入日志前，简要进行压力测试：

• 这是否与会话日志中此前已确定的决策冲突？
• 这是否会关闭我们可能仍需要的分支？
• 是否有需要指出的隐含假设？

如果存在问题，先在当前对话中提出，再记录答案。否则继续。

5f. 记录到会话日志

更新会话日志：

• 使用以下格式将问题移至 已解决：Q<n>: <question> → <decision>. Why: <reason>.
• 将新提出的后续问题添加到 待解决问题，并在适用时注明 (depends on: Q<n>)。

5g. 启动后台验证器

在后台启动 answer-verifier-agent，并提供以下内容：

• question： 问题文本
• answer： 用户已确认的决定
• prior-context： 日志中的 已解决 部分（不包括刚提出的问题）
• session-log-path： 会话日志文件的完整路径

使用 Agent 工具，并设置 subagent_type: "answer-verifier-agent" 和 run_in_background: true。该 Agent 会返回 YAML 判定结果；在下一轮开始时（5c）读取该结果，用于侧边栏呈现。

如果在呈现 5c 时，上轮的后台验证器尚未返回，不要等待；直接继续，不显示侧边栏。等判定结果返回后再处理；如果结果是 conflict，即使问题已过，也要将其作为侧边栏提示出来。

5h. 循环

返回 5a，除非用户要求结束。

6. 结束会话（由用户明确发起）

当用户说“done”／“close this grill”／“wrap up”或类似的话时：

1. 进行最终审核：调用 answer-verifier-agent，设置 mode: final 并提供会话日志路径。等待其判定结果（在前台运行）。
2. 将判定结果中的 finding 和 evidence 追加到日志的 最终审核 部分。
3. 如果最终审核结果为 concern 或 conflict，向用户说明，并询问：“解决此问题并保持会话开启，还是仍然关闭？”——遵从用户的选择。
4. 确认关闭后：将 .chief/_grill/opened/NNNN-<slug>.md 移至 .chief/_grill/closed/NNNN-<slug>.md。
5. 告知用户关闭后的路径。停止。

如果用户说“stop”／“pause”或离开但未关闭 → 将文件留在 opened/ 中。用户之后可以继续会话。

重要规则

• 始终推荐一个答案。绝不要只提问而不给出建议。
• 始终在推荐旁展示自检。
• 一次只问一个问题。禁止提出复合问题。
• 绝不要跳过会话日志更新——该文件才是事实来源，而非对话内容。
• 绝不要等待后台验证器。如果它尚未返回，继续进行且不显示侧边栏。
• 绝不要自动关闭会话。关闭始终由用户发起。
• 绝不要移动已过时的未关闭会话。它们会一直留在原处，直到用户手动关闭或删除。
• Agent 的判定结果采用 YAML 格式——解析它，不要改述。仅针对 concern 和 conflict 呈现侧边栏。

与 /grill-design 的区别

• /grill-design 会在对话中增加自我批评和压力测试。轻量，不涉及文件或子 Agent。
• /chief-grill 会增加代码库验证（后台子 Agent）和 .chief/_grill/ 下的持久会话日志。流程更重——适用于影响较大的主题，或涉及多项交叉验证决策的主题。