council

Council

Council 是一种可选的判断策略，适用于难题：不同视角有助于发现其他方案、假设或遗漏的证据。当调用者选择多个视角来进行头脑风暴、架构设计、规划或验证时，可使用此策略。说明额外上下文有用的原因，即存在什么不确定性；常规工作无需 Council。相关工具：单个意见或审阅见 Review，对计划进行单次对抗性挑战见 Premortem，为 Plan 做出单个重要选择见 Idea Genie，验收结论见 Validate。

决定综合结论的规则

这些规则适用于你主持的 Council，也适用于调用者已在其他地方收集意见（多次审阅、子 Agent 阅读结果）并要求你进行综合的情况。针对不同修订版本作出的判断属于不同对象，不能算作对同一对象达成共识。

• 不作结论。 Council 不给出 PASS、FAIL、NOT_PROVEN、就绪度或批准结论，即使有人要求将共识转化为结论也是如此。应予以拒绝，并说明该判断应由全新的 Validate 审阅负责。报告应作为咨询性发现交给调用者，不能代替该判断。
• 重复共识只算一份佐证。 如果作出判断的人员使用同一模型或同一种证据方法，那么他们之间的共识只算一份佐证，无论有多少人意见一致：基于相同输入和同一种共享方法达成的全体一致，并非独立佐证。每个共识点都要列出 methodologies（静态阅读、执行判断对象、追溯历史）；如果判断者记录了 model_identity，还要列出支持该共识点的 models。如果其中任一项只有一个值，则设置 weighs_as_one: true。
• 默认遵循调用者的方向。 与调用者已作决定相矛盾的判断应列为 caller_challenge 条目，包含全部五个字段；不得将其列为共识点，也不得悄然改变建议。
• 不得遗漏任何内容。 所有初始意见都必须在分享之前封存，每条发现都必须恰好归入一个综合类别，异议也必须保留。

运行 Council

用途	向每位参与者征求	返回给调用者
头脑风暴	不同的方案、假设和失败模式	值得考虑的想法，以及值得验证的异议
设计或规划	建议方案、权衡和证据	展示未解决决策的建议
验证	针对同一对象和验收标准的发现	咨询性发现；验收仍由全新的 Validate 审阅负责
对决	排序后的想法，以及对其他每位成员想法的评分	按跨成员共识排序的想法、评分差异和异议
面试小组	对每个 Interview 问题的回答	已达成共识和仍有分歧的答案，由调用者接受或修订

1. 固定问题、约束或验收标准、获准使用的证据以及主题摘要。选择参与者、模型固定项和实际调度边界；除非调用方通过 model-dispatch 固定混合模型，否则上下文应保持在作者的模型系列内。调用方可以为每位参与者指定各自的模型、推理力度和视角（例如架构、可靠性、安全性或简洁性）；在不同上下文中使用同一模型仍算作名单上的不同参与者，但其意见一致仍只计作一方。对于没有获准的实时适配器的所请求配置或必需环节，按名称列入 diversity_unsatisfied；可用视角仍可在注明此限制后返回，但缺少必需环节会阻止达成共识，任何一致意见都不能替代该环节。
2. 为每位参与者提供全新、独立的上下文和相同的有限资料包，绝不提供作者偏好的结论；视角引导成员审视什么，而不决定其获得什么证据。在公布任何同伴的回应前，先收集提案或判断。重复或冲突的上下文 ID 会使视角失去独立性：应在范围内修复隔离问题，或披露该情况。仅纳入与引用来源及调用方所述需求和利害相关的事实；在综合之前，不要透露自己的排名、选项评分标签，以及参与者可自行打开文件的摘要。对你起草的选项应一视同仁地认真措辞，并说明参与者可以拒绝所有选项，也可以拒绝当前提出的问题。在辩论或对决评分中，以中立标签（A、B、C）展示同伴的成果，而非成员或模型名称；报告会在每位评审的 judgment 中保留对应关系。
3. 要求提供证据、推理过程和遗漏项。对于头脑风暴，应区分新假设与有依据的主张；新颖不等于证明。
4. 综合封存的初始视角，或运行下方由调用方选择的模式。保留异议和立场变化。subject_digest 涵盖 Validate 的 Subject 所绑定的内容：ao provenance manifest 的 canonical_manifest_digest；如果没有，则对主题中相对于仓库的路径运行 shasum -a 256 <files> | LC_ALL=C sort | shasum -a 256；或者，如果主题仅以文本提供，则使用该文本的 sha256。每轮后续处理前以及综合前，都要用相同方式重新计算；如果发生变化，应指出变化并让每位参与者针对新主题重新作答，或返回未完成结果，绝不能将针对旧主题的视角合并进来。若没有可绑定的内容（头脑风暴、开放式设计问题、访谈小组），则使用记录下来的 question 的 sha256，并仅计算一次；问题措辞一旦改动，就构成一个新主题。
5. 返回 council-report.v1 及其限制；如果该用途会生成建议（例如设计或计划），则附上可选的 recommendation。只有证据支持某个选项时才优先推荐它；若选项差异不大，应说明二者都可行，并指出各自的取舍。除非调用方选择了投票规则，否则优缺点或支持者的数量都不能打破平局。Council 既不更改主题，也不授予实施或交付权限。

独立比较是默认方式。多个模型可以拓宽所提供的视角；仅仅意见一致，并不能证明有所改进。

可选模式

仅加载调用方选择的模式：

• 有限辩论或多数规则：辩论。看到先前回答后作出的回应受同伴观点影响，不再是新的独立视角；多数意见不能确立事实或验收结果。
• 成员相互评分：对决。
• Council 回答 Interview：访谈小组。
• 验证评审之间经修复后仍未解决的分歧：评审分歧。

调用者异议

如果评判意见建议更改调用者指定的内容（合并调用者区分开的内容、删去调用者要求保留的内容、反转已声明的方向），请将其记录在 synthesis.caller_challenge 中。多方独立意见一致反对调用者是一个强烈信号，但仍不构成决定依据：调用者掌握评判者未获知的上下文。每个条目包含五个字段：

• caller_stated：调用者的方向，照录原话，不要改述。
• judges_recommend：建议的更改、支持者，以及他们的意见是独立形成还是受同侪意见影响；绝不要把讨论中的投票说成独立意见。
• reasoning：最有力的论据。
• context_possibly_missing：评判者确实未获知的内容；缺少此字段的条目，就是换了个标签的多数意见洗白。
• cost_if_wrong：如果调用者的方向是对的，会造成什么损失。

可选字段 judge_count 至少需要两位支持者；可选字段 disagreement_kind 用于说明异议属于 preference、security 还是 feasibility 缺陷。调用者的方向仍是默认选项，举证责任在评判者；调用者了解分歧类型后作出决定。停止条件：每条与调用者所述方向矛盾的评判意见，都必须出现在 caller_challenge 中，包含全部五个字段，且不出现在任何其他综合结论类别中。被质疑的决定能否撤销，应根据实际撤销成本和现有授权写入 Plan；评议组不得自行假定其中任何一项。

综合结论部分

报告结尾必须明确综合呈现共识与分歧：列出共识要点及其方法分布；列出分歧要点、各方引用的证据，以及分歧属于证据缺口（指出能够确定结论的事实或检查项）还是由调用者决定的判断；以少数意见的原话保留其结论；列出尚未解决的假设以及所有 caller_challenge 条目。只有每位评判者的每项发现都恰好归入其中一个类别时，综合结论才算完整；从综合结论中悄然删去某项发现，就是多数意见洗白。运行事实（上限、名单、阈值、票数、停止原因、未返回的评判者）应写入 synthesis.notes。

只有在单一修复方案能同时解决两个缺陷时，两位评判者对缺陷的发现才算同一个要点；判断时应分别阅读每项缺陷及其修复方案，而不是看措辞或是否涉及同一位置。只有在建议相同更改时，提案或回答才算同一个要点。同一行上的发现如果失效模式不同，就应分开处理；相互对立的建议属于分歧；拿不准时应分开，因为错误合并会夸大一致程度。合并后的要点仍须保留每位评判者各自的证据。

输出

<skill-dir> 是包含此 SKILL.md 的目录。Claude Code 将其显示为“此技能的基本目录”；Codex 会列出此技能的 SKILL.md 路径；在 AgentOps 源代码检出目录中，该路径为 skills/council。运行命令前，请将 <skill-dir> 替换为该目录的绝对路径。工作目录仍为用户的仓库。如果宿主没有显示此技能的安装位置，请使用你读取的 SKILL.md 所在目录。如果无法确定该目录，不要猜测路径，也不要运行当前仓库中同名的脚本；请说明捆绑脚本不可用，并根据其 架构 手动检查报告字段。

• 目标位置： 调用方选定的受保护外部非 Git 存储位置；保留现有的旧版证据。如果未提供目标位置，不得回退到工作区：应在对话中直接返回报告，不写入任何文件。
• 文件名： council-report.json。
• 格式： council-report.v1 JSON（架构）：冻结的 question 和 subject_digest、任何 recommendation、每位评审者的 context_id、methodology、引用的 evidence 和 omissions，以及上述综合分析分类。记录每个 judgment 的模式、轮次和候选摘要。报告不得包含 verdict 或 readiness 字段；如果 judgment 或 recommendation 仅为表示 verdict 的词语，则会被拒绝。
• 验证命令： bash "<skill-dir>/scripts/validate-output.sh" <council-report.json>，或使用标准输入传入内联报告：bash "<skill-dir>/scripts/validate-output.sh" -。

超时、出错或返回不含证据的判断的评审者，不计入共识统计，并应在 synthesis.notes 中列为未返回，附上其 context ID 和原因，绝不能列为 judges 条目。如果符合条件的初始判断少于两个，应报告独立覆盖不足，而不是综合出依据不足的共识；如果无法形成有效报告，应返回未完成结果及现有回执，不得捏造评审者记录。