mcpField
T
the-grilling

the-grilling

github.com/kucherenkoAgent 工作流8551 次安装1 天前更新
代码仓库

关于 the-grilling

the-grilling 是一项单轮多 Agent 辩论技能,在 Reconnaissance Dossier 获批后启动。它先逐个询问目标问题,再依次运行 Proposer、Devils-Advocate 和 Synthesizer,为后续阶段整理结论。

主要功能

  1. 01单轮辩论流程
  2. 02先审视目标本身
  3. 03每次只问一个问题
  4. 04Proposer、Devils-Advocate、Synthesizer 阶段
  5. 05为后续阶段整理结论

适用场景

  1. 01在架构设计前检验目标
  2. 02检查提案中的风险与回归问题
  3. 03记录决策和未解决异议

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/kucherenko/gangsta --skill the-grilling

安装后在 Claude Code 中输入/the-grilling确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

devils-advocate-prompt.md
proposer-prompt.md
synthesizer-prompt.md

详细介绍

烤问:对抗式头脑风暴

概述

烤问是一种单轮多 Agent 辩论。提案者提出方案,魔鬼代言人发起攻击(先针对想法,再针对提案),综合者进行修订。没有多轮——每个 Agent 恰好运行一次。询问 Don 时一次只问 一个问题,绝不罗列问题。先烤问想法,再烤问提案。

触发条件

在 Don 批准《侦察档案》(侦察完成)后调用。

硬性规则(不可妥协)

  1. 没有多轮。 每个 Agent——提案者、魔鬼代言人、综合者——都恰好运行一次。不要循环返回。没有第二轮。
  2. 先讨论想法。 魔鬼代言人先攻击 Don 的目标(即想法),再攻击提案。先围绕想法烤问 Don——包括《侦察档案》中的构思框架、假设、范围和类比案例——之后才能提出任何架构方案。
  3. 一次只问一个问题。 每次与 Don 互动时,恰好只问一个问题。等待回答后再问下一个问题。即使子 Agent 输出中包含多个问题,也必须遵守此规则。参见下文的 Don 询问协议。
  4. 不要罗列问题。 给 Don 的消息中包含 2 个或更多不同问题,即为违规,即使这些问题带有编号也不例外。先问最关键的问题;得到回答后,再决定是否还需要问下一个问题。

协议(单轮)

阶段 A — 烤问想法

提出任何方案之前,协调 Agent 会参考《侦察档案》(尤其是类比案例、先前成果,以及在绿地模式下的《约束与风险调查》),围绕目标本身烤问 Don。

  1. 协调 Agent 阅读《侦察档案》,提取所有尚未解决的假设、范围歧义,以及必须由 Don 决定的类比对比事项。
  2. 按以下优先级排列问题:先问最影响想法有效性的问题(问题框定 → 隐含假设 → 范围 → 类比选择)。
  3. 一次只问一个问题。每次得到回答后,判断下一个计划中的问题是否仍然相关——Don 的回答可能已经解决该问题、使其不再适用,或引出一个更紧急的新问题。
  4. 继续询问,直到不再有关键的想法层面问题。Don 也可以说“想法已经敲定,转到架构阶段”。

想法判定(协调 Agent):

  • REJECT(拒绝)——当前表述的目标存在缺陷;Don 必须重新定义目标。暂停并请 Don 重述目标或终止。
  • CHALLENGE(质疑)——目标需要进行上述调整。纳入这些调整后,继续进入阶段 B。
  • SOUND(合理)——目标有效。继续进入阶段 B。

如果判定为 REJECT:停止。向 Don 呈现判定结果和原因。不要调度提案者。Don 可以修改目标(返回侦察阶段)或终止。

阶段 B — 提案者(单轮)

仅调度一次提案者子 Agent。它读取《侦察档案》和经完善的目标(已纳入 Don 对想法层面问题的回答),并生成一份提案。参见 proposer-prompt.md。

阶段 C — 魔鬼代言人(单轮)

仅调度一次魔鬼代言人子 Agent。它攻击该提案——包括架构缺陷、安全问题、违反章程、回归问题和可扩展性问题。阶段 A 中提出的想法层面问题已记录在案;只有当提案实质性改变目标范围时,魔鬼代言人才会重新审视这些问题。参见 devils-advocate-prompt.md。

阶段 D — Don 发表意见(一次只问一个问题)

向 Don 展示魔鬼代言人的攻击摘要。然后提问:

  1. 第一个问题:“你认同魔鬼代言人的攻击吗?”——等待回答。
  2. 根据 Don 的回答决定下一个问题。只有在必要时才问:“他们遗漏了什么顾虑吗?”——等待回答。
  3. 只有在必要时才问:“你想推翻提案中的任何部分吗?”——等待回答。

只有当之前的回答尚未明确解决问题时,才提出下一个问题。收集 Don 的所有回答。

阶段 E — 综合者(单次)

仅调度一次综合者子代理。它会纳入有效的攻击意见和老大的反馈,为提案中的有效内容辩护,并给出最终修订方案。请参阅 synthesizer-prompt.md。

综合者的输出即为最终共识。不会进行第二轮攻击。

终止

拷问在阶段 E 结束。没有纳什均衡检查,没有轮次限制,也不会在第 2 轮提前退出——因为根本没有轮次。整个辩论只有一次流程。

例外 — 尽力而为的共识: 如果综合者发现,魔鬼代言人提出了一个重大异议,而老大和提案无法在一次综合中解决该异议,综合者则改为给出尽力而为的共识,并记录尚未解决的异议:

## Best Available Consensus

**Proposal:** <Final revised solution>

### Resolved Points
- <Points where all parties agree>

### Unresolved Objections
1. <Objection> — Risk: HIGH/MEDIUM/LOW — Mitigation: <if any>
2. ...

### Don's Decision Required
Accept this consensus (with documented risks), reject and restart, or table.

老大问询协议(硬性规则)

每次与老大交互时,一次只问一个问题。等待老大回答后,再问下一个问题。

此规则优先于任何会在一条消息中打包多个问题的模板或子代理输出。协调 Agent(运行拷问的 Agent)必须:

  1. 找出子代理向老大提出的所有问题
  2. 按重要性排序(先问最关键的决策)
  3. 提出第一个问题,并等待老大回答
  4. 收到回答后重新评估:下一个计划中的问题是否仍有必要?如果回答已解决该问题,则跳过。
  5. 提出下一个仍有必要的问题,并再次等待回答
  6. 重复以上步骤,直到没有剩余的必要问题
  7. 收集老大的所有回答,并批量传递给下一个子代理

反面模式 — 捆绑问题列表: 绝不要在同一条消息中向老大发送编号问题列表。即使子代理输出了“问老大的问题”列表,协调 Agent 也必须每条消息依次只问一个问题,并跳过已变得无关的问题。

问题工具架构(硬性规则)

使用 question 工具向老大提问时,每个选项都必须包含两个字段,且字段值必须是非空字符串:

label: string       — concise display text, 1-5 words
description: string — explanation of what choosing this option means

description 绝不能为 null、undefined 或省略。 即使是“Yes”或“No”这样显而易见的选项,也要提供描述:

Bad:  { label: "Yes" }
Bad:  { label: "Yes", description: null }
Good: { label: "Yes", description: "I agree with the Devil's-Advocate's attack" }
Good: { label: "No",  description: "I reject the attack — the proposal stands" }

违反此架构会导致工具调用因验证错误而失败。

适用于:

  • 阶段 A 的想法拷问(每个想法级问题)
  • 阶段 D 老大发表意见
  • 尽力而为的共识决策
  • 综合者或提案者向老大提出的任何问题

原因: 相比同时回答三个问题,老大能更好地回答一个问题。捆绑提问会迫使其在不同问题间切换思路,导致决策质量下降。

重复检测(单次模式说明)

在单次模式下,阶段 A 的想法拷问与阶段 C 的魔鬼代言人攻击之间出现重复是预期且可以接受的——两者都从不同角度审视想法。综合者会标记真正重复的内容,避免最终共识对同一项顾虑重复计数。

子代理提示词

提案者、魔鬼代言人和综合者作为子代理运行,使用本目录中的提示词:

  • proposer-prompt.md — 提案者的提示词模板
  • devils-advocate-prompt.md — 魔鬼代言人的提示词模板
  • synthesizer-prompt.md — 综合者的提示词模板
派遣说明

调用 Task 工具派遣每个子代理时:

  1. 从该 Agent 的技能目录中读取其提示词文件
  2. 填写模板占位符(档案内容、Don 的构想拷问回答、Devils-Advocate 的输出、Don 的反馈等)
  3. 将 subagent_type 设置为指定的 Gangsta Agent——根据需要使用 "proposer"、"devils-advocate" 或 "synthesizer"。不要使用 "general" 或 "general-purpose"——它们在 Gangsta 安装中无效。
  4. 将完整填写后的提示词作为 prompt 参数传入

重要——平台 Agent 类型: Gangsta 安装中有效的 subagent_type 值是指定的自定义 Agent:"associate"、"soldier"、"the-inspector"、"proposer"、"devils-advocate"、"synthesizer"。内置的 "general" 和 "explore" Agent 已禁用。**绝不要使用 "general-purpose"、"Task"、"oracle"、"fixer"、"explorer" 或 "council"——这些都无效。**完整的平台映射请参阅 using-gangsta/references/opencode-tools.md。

输出

拷问阶段不会生成独立的对话记录文件。相反,负责协调的 Agent 会在辩论结束时生成一份拷问结论摘要。该摘要将直接传递至下一阶段(会谈阶段),纳入契约。

拷问结论必须包含:

  • 构想判定: REJECT / CHALLENGE / SOUND,并记录 Don 在阶段 A 对构想层面问题的回答
  • 关键决策: 达成的每项架构/设计决策及其理由
  • 已否决的备选方案: 每个曾考虑但最终舍弃的选项及其理由(包括侦察档案中未采纳的类比方案)
  • 未解决的异议: 已知但接受的风险(如触发「最佳可行共识」机制)
  • 终止原因: 单轮完成/最佳可行共识

负责协调的 Agent 会在上下文中保留此摘要——不会将其另存为独立文件。

检查点

---
heist: <heist-name>
phase: the-grilling
status: completed
timestamp: <ISO 8601>
next-action: Proceed to The Sit-Down
artifacts: []
note: Grilling Conclusions passed in-context to The Sit-Down for inclusion in the Contract
---

Omerta 合规检查

  • 引介规则:Proposer、Devils-Advocate 和 Synthesizer 不直接交流——所有沟通均通过此技能协调
  • 事实规则:所有质疑和提案都必须引用侦察档案、宪章或具体技术事实
  • 可用性规则:完成后保存对话记录和检查点
  • 禁止多轮规则:每个 Agent 恰好运行一次——不得循环进行反复质疑
  • 构想优先规则:阶段 A 先拷问构想,再由阶段 B 提出架构
  • 一次只问一个问题规则:不得向 Don 提出打包在一起的问题列表

评论

支持 Markdown