Codeck 是做什么的？
将 Codeck 作为执行桥梁，同时保持当前编码代理作为主持和协调者。将宿主产品的模型选择器视为无关：切换活跃聊天模型不同于通过 Codeck 咨询外部模型。
选择工作流
- 使用单次
ask从命名的执行器获取只读二次意见。 - 使用委员会从两个或更多真正不同的底层模型提供商获取独立意见。
- 仅当用户明确要求外部执行器实现变更时，才使用
delegate。 - 当路由不确定时，在
auto之前使用pick。
绝不要将一个模型扮演多个角色描述为多模型共识。将其标记为 single-model-multi-role。
预检
- 运行
command -v codeck。 - 如果不可用，停止并解释需要 Codeck CLI。未经用户授权不要安装它。
- 在目标项目中运行
codeck doctor和codeck list。 - 仅使用健康、已配置且其声明的模式和权限适合任务的执行器。
- 如果项目未初始化，请在运行
codeck init前询问，因为它会创建.codeck/文件。
在配置执行器、为区域网络选择提供商或解释为什么请求的模型不可用时，请阅读 references/providers.md。
准备交接
为重要工作编写简洁的 Markdown 简报。包括目标、约束、问题、验收标准，以及外部模型所需文件。优先使用文件附件，而不是在命令中嵌入长篇简报：
codeck ask <executor> "阅读附加的任务简报，并返回基于证据的审查。" -f task.md
不要包含机密、凭据、不相关的源文件或私人用户数据。告知用户任务内容何时会离开宿主产品并发送给另一个提供商。
阅读 references/artifacts.md 了解输入简报和最终工件模式。
运行多模型委员会
- 保持当前编码代理作为主持人。
- 选择至少两个由不同提供商支持的健康执行器。优先考虑能力匹配和可用性，而非品牌顺序。
- 向每位首轮专家提供相同的事实和核心问题，外加一个独特的审查角色。
- 在将一位专家的答案暴露给另一位之前，独立收集首轮回答。
- 提取主张、证据、假设、风险和分析分歧。
- 仅针对实质性分歧提出有针对性的后续问题。将相关先前的输出作为 Markdown 文件附加。
- 当满足验收标准、剩余分歧被明确记录或达到配置的轮次限制时停止。
- 当写入工件在范围内时，生成
report.md、summary.md和decisions.json；否则在响应中返回相同的结构。
当所有专家应接收相同提示时，使用 codeck compare <executor-a>,<executor-b> "<task>" -f task.md。当角色或后续问题不同时，使用单独的 codeck ask 调用。除非观察到运行实际上是并发执行的，否则不要声称并行执行。
阅读 references/moderation.md 了解角色提示、分歧处理和收敛规则。
安全路由
- 默认使用
ask，它用于只读咨询。 - 除非用户授权外部实现，否则不要添加
-y或调用delegate。 - 将权限字段视为声明，除非底层 CLI 也强制执行沙箱。
- 不要静默地替换提供商。报告请求的执行器、实际执行器/提供商以及回退原因。
- 不要硬编码当前模型 ID。从本地配置中发现或读取它们，因为提供商模型名称会更改。
- 如果少于两个不同的提供商可用，则仅作为单模型咨询继续，并说明限制。
- 保留原始外部输出或 Codeck 运行 ID，以便综合结果保持可审计。
返回结果
以主持人的结论开头。然后说明：
- 哪些执行器和底层提供商实际运行了；
- 他们在哪些方面达成一致，哪些方面存在分歧；
- 支持决策的证据是什么；
- 未解决的风险和推荐的验证方式；
- 任何回退、失败、估计使用量或区域限制。
保持简短摘要以决策为导向。将详细推理和来源归属保留在完整报告中。