Cookoff
同样的设计，多个厨师竞争。每个实施团队根据共享的设计创建自己的计划，然后实施它。独立的计划决策自然产生变化。
测试厨房开发的一部分：
omakase-off- 厨师的选择探索（不同的方法/设计）cookoff- 同样的设计，多个厨师竞争（每个创建自己的计划+实施）
**关键洞见：**不要分享预先制作的实施计划。每个代理根据设计文档生成自己的计划，确保真正的变化。
目录结构
docs/plans/<feature>/
design.md # 输入：来自头脑风暴
cookoff/
impl-1/
plan.md # 代理1的实施计划
impl-2/
plan.md # 代理2的实施计划
impl-3/
plan.md # 代理3的实施计划
result.md # Cookoff结果和获胜者
技能依赖
| 参考 | 主要（如果安装） | 备用 |
|---|---|---|
writing-plans |
superpowers:writing-plans |
每个代理编写自己的实施计划 |
executing-plans |
superpowers:executing-plans |
按顺序执行计划任务并验证 |
parallel-agents |
superpowers:dispatching-parallel-agents |
在单条消息中分派多个任务工具 |
git-worktrees |
superpowers:using-git-worktrees |
git worktree add .worktrees/<name> -b <branch> |
tdd |
superpowers:test-driven-development |
红-绿-重构周期 |
verification |
superpowers:verification-before-completion |
运行命令，读取输出，然后声明状态 |
fresh-eyes |
fresh-eyes-review:skills (2389) |
2-5分钟的审查，用于安全、逻辑、边缘情况 |
judge |
test-kitchen:judge |
评分框架和检查列表（必须在第4阶段调用） |
code-review |
superpowers:requesting-code-review |
分派代码审查子代理 |
scenario-testing |
scenario-testing:skills (2389) |
.scratch/ E2E脚本，真实的依赖 |
finish-branch |
superpowers:finishing-a-development-branch |
验证测试，呈现选项，清理 |
何时使用
触发用户想要实施设计时：
- “执行这个计划”/“实施计划”/“让我们构建这个”
- 头脑风暴完成后，设计文档存在后
- 也可以明确调用：“cookoff this”
重要：Cookoff从设计文档工作，而不是详细的实施计划。每个代理创建自己的实施计划。
检测设计到实施的转换
Cookoff在SITUATION触发，而不是特定技能的输出。
**情况：**设计完成，即将开始实施。
信号表明设计阶段刚刚完成：
- 设计文档被编写/提交
- 用户批准了设计（“看起来不错”，“是的”，“让我们这样做”）
- 讨论从“我们要建造什么”转变为“我们如何建造它”
- 任何技能/流程即将开始实施
当你检测到这种转换时，总是提供cookoff：
在我们开始实施之前，你想如何进行？
1. Cookoff（推荐）- N个并行代理，每个创建自己的计划，选择最佳
→ 复杂性：[从设计中评估]
→ 最适合：中高复杂性功能
2. 单一实施 - 一个代理/会话实施
3. 直接编码 - 没有详细计划就开始编码
这适用于：
- 使用了哪个头脑风暴技能（超能力，其他，或没有）
- 是否存在正式的设计文档（可能是非正式的协议）
- 另一个技能可能呈现的实施选项是什么
**关键洞见：**我们不是注入到另一个技能的菜单中。我们认识到一个SITUATION（设计→实施）并确保在那一刻提供cookoff。
第1阶段：实施选项
当用户想要实施时呈现选择：
你想如何实现这个设计？
1. 单个子代理 - 一个代理计划和实施
2. Cookoff - N个并行代理，每个创建自己的计划，选择最佳
→ 复杂性：[从设计中评估]
→ 推荐：N个实施
3. 本地 - 在这个会话中计划和实施
哪种方法？
路由：
- 选项1：单个代理使用writing-plans然后executing-plans，cookoff退出
- 选项2：继续第2阶段
- 选项3：用户手动实施，cookoff退出
第2阶段：复杂性评估
阅读设计文档并评估：
- 功能范围（组件、集成、数据模型）
- 风险区域（认证、支付、迁移、并发）
- 估计的实施大小
映射到实施计数：
| 复杂性 | 范围 | 风险信号 | 实施 |
|---|---|---|---|
| 低 | 小功能 | 无 | 2 |
| 中等 | 中等功能 | 一些 | 3 |
| 高 | 大功能 | 几个 | 4 |
| 非常高 | 主要系统 | 临界区域 | 5 |
设置目录：
mkdir -p docs/plans/<feature>/cookoff/impl-{1,2,3}
宣布：
复杂性评估：中等功能，涉及认证
生成3个并行实施
每个都将根据设计创建自己的实施计划。
第3阶段：并行执行
设置工作树：
.worktrees/cookoff-impl-1/
.worktrees/cookoff-impl-2/
.worktrees/cookoff-impl-3/
分支：
<feature>/cookoff/impl-1
<feature>/cookoff/impl-2
<feature>/cookoff/impl-3
CRITICAL:在一条消息中分派所有代理
使用parallel-agents模式。发送一条包含多个任务工具调用的消息：
<single message>
Task(impl-1, run_in_background: true)
Task(impl-2, run_in_background: true)
Task(impl-3, run_in_background: true)
</single message>
不要为每个代理发送单独的消息。
子代理提示（每个都得到相同的指示，带有他们的impl编号）：
你是M个实施团队中的N。
其他团队也在并行实施相同的设计。
每个团队都创建自己的实施计划 - 你的方法可能与其他人不同。
**你的工作目录：** /path/to/.worktrees/cookoff-impl-N
**设计文档：** docs/plans/<feature>/design.md
**你的计划位置：** docs/plans/<feature>/cookoff/impl-N/plan.md
**你的工作流程：**
1. 彻底阅读设计文档
2. 使用writing-plans技能创建你的实施计划
- 保存到：docs/plans/<feature>/cookoff/impl-N/plan.md
- 做出你自己的架构决策
- 不要尝试猜测其他团队会做什么
3. 使用executing-plans技能实施你的计划
4. 每个任务都遵循TDD
5. 在声称完成之前进行验证
**完成后报告：**
- 计划创建：是/否
- 所有任务完成：是/否
- 测试结果（npm test输出）
- 文件更改计数
- 遇到的任何问题
你的目标：最佳可能的实施。祝你好运！
监控进度：
Cookoff状态（设计：认证系统）：
- impl-1：计划... → 实施5/8任务
- impl-2：计划... → 实施3/8任务
- impl-3：计划... → 实施6/8任务
第4阶段：评判
第1步：门检查
- 所有测试通过
- 设计一致性 - 实施了设计指定的内容
第2步：检查相同实施
在fresh-eyes之前，比较实施：
diff -r .worktrees/cookoff-impl-1/src .worktrees/cookoff-impl-2/src
如果实施>95%相同，请注意 - 计划步骤没有产生足够的变化。仍然继续，但在结果中标记。
第3步：对幸存者进行fresh-eyes
开始对impl-1（N个文件）进行fresh-eyes审查...
检查：安全，逻辑错误，边缘情况
fresh-eyes完成：1个次要问题
第4步：调用Judge技能
CRITICAL:现在调用test-kitchen:judge。
Judge技能包含完整的评分框架和检查列表。现在调用它，确保评分格式完全遵循。
调用：test-kitchen:judge
提供上下文：
- 实施以评判：impl-1，impl-2，impl-3（或有多少）
- 工作树位置：.worktrees/cookoff-impl-N/
- 每个实施的测试结果
- 第3步的fresh-eyes发现
- 确定的可行性标志
Judge技能将：
- 为每个实施填写完整的评分工作表
- 用整数评分（1-5，没有半分）构建评分卡
- 检查硬门（Fitness Δ≥2，任何得分=1）
- 宣布获胜者及理由
**不要总结或缩写评分。**Judge技能的输出应该是完整的工作表。
**Cookoff特定上下文：**在cookoff中，所有实施都针对相同的设计，所以Fitness应该是相似的。Fitness差距（Δ≥2）表明一个实施偏离或误解了设计 - 不是不同的方法选择。
第5阶段：完成
获胜者的验证：
在获胜者（impl-2）上运行最终验证：
- npm test：22/22通过✓
- npm run build：退出0✓
- 设计一致性：满足所有要求✓
验证完成。获胜者确认。
获胜者： 使用finish-branch
- 选项：本地合并，创建PR，保持原样，丢弃
失败者： 清理
git worktree remove .worktrees/cookoff-impl-1
git worktree remove .worktrees/cookoff-impl-3
git branch -D <feature>/cookoff/impl-1
git branch -D <feature>/cookoff/impl-3
# 直到合并前保留获胜者的工作树
# Cookoff结果：<feature>
## 设计
docs/plans/<feature>/design.md
## 实施
| Impl | 计划方法 | 测试 | Fresh-Eyes | 行数 | 结果 |
|------|---------------|-------|------------|-------|--------|
| impl-1 | 组件优先 | 24/24 | 1个次要 | 680 | 淘汰 |
| impl-2 | 数据层优先 | 22/22 | 0个问题 | 720 | 获胜者 |
| impl-3 | TDD严格 | 26/26 | 2个次要 | 590 | 淘汰 |
## 生成的计划
- impl-1：docs/plans/<feature>/cookoff/impl-1/plan.md
- impl-2：docs/plans/<feature>/cookoff/impl-2/plan.md
- impl-3：docs/plans/<feature>/cookoff/impl-3/plan.md
## 获胜者选择
原因：最干净的fresh-eyes审查，坚实的数据层优先架构
## 清理
工作树移除：2
分支删除：<feature>/cookoff/impl-1，<feature>/cookoff/impl-3
获胜者分支：<feature>/cookoff/impl-2
保存到：docs/plans/<feature>/cookoff/result.md
协调的技能
| 依赖 | 阶段 | 使用 |
|---|---|---|
writing-plans |
3 | 每个子代理创建自己的实施计划 |
executing-plans |
3 | 每个子代理实施他们的计划 |
parallel-agents |
3 | 在一条消息中分派所有子代理 |
git-worktrees |
3 | 每个实施创建工作树 |
tdd |
3 | 子代理遵循RED-GREEN-REFACTOR |
verification |
3, 5 | 在声称完成之前；在宣布获胜者之前 |
code-review |
3 | 实施完成后审查每个impl |
fresh-eyes |
4 | 质量审查 → 评判输入 |
judge |
4 | 调用评分框架（加载新鲜，确保格式合规） |
scenario-testing |
4 | 验证是否定义了场景 |
finish-branch |
5 | 处理获胜者，清理失败者 |
常见错误
分享预先制作的实施计划
- 问题：所有团队复制相同的代码，没有变化
- 解决方案：每个团队使用writing-plans从设计文档创建他们自己的计划
在单独的消息中分派代理
- 问题：串行分派而不是并行
- 解决方案：在一条消息中发送所有任务工具
不使用writing-plans + executing-plans
- 问题：子代理即兴实施
- 解决方案：每个子代理必须使用writing-plans然后executing-plans
跳过fresh-eyes
- 问题：评判没有质量信号，只有测试计数
- 解决方案：在比较之前对所有幸存者进行fresh-eyes
不检查相同实施
- 问题：在重复上浪费计算
- 解决方案：在fresh-eyes之前比较实施，如果>95%相似则标记
忘记清理
- 问题：孤立的工作树和分支
- 解决方案：总是清理失败者，编写result.md
示例调用
用户：“让我们构建这个”（头脑风暴后产生design.md）
Claude：我正在使用cookoff。
你想如何实现这个设计？
1. 单个子代理 - 一个代理计划和实施
2. Cookoff - 3个并行代理，每个创建自己的计划，选择最佳
→ 复杂性：中等功能，涉及认证
→ 推荐：3个实施
3. 本地 - 在这里计划和实施
用户：“2”
Claude：生成3个并行实施...
每个都将根据设计创建自己的实施计划。
[第3阶段：创建工作树，在一个消息中分派所有3个代理]
[每个代理：阅读设计 → 编写计划 → 实施]
Cookoff状态：
- impl-1：计划 → 实施6/8任务
- impl-2：计划 → 实施4/7任务
- impl-3：计划 → 实施5/9任务
[全部3个完成]
[第4阶段：差异检查 - 实施不同 ✓]
[对所有3个进行fresh-eyes]
| Impl | 计划方法 | 测试 | Fresh-Eyes |
|------|---------------|-------|------------|
| impl-1 | 组件优先 | 24/24 | 1个次要 |
| impl-2 | 数据层优先 | 22/22 | 0个问题 |
| impl-3 | TDD严格 | 26/26 | 2个次要 |
推荐：impl-2（最干净）
用户：“2”
[第5阶段：验证获胜者，清理失败者]
获胜者：impl-2准备合并
清理：2个工作树已移除
计划保留：docs/plans/<feature>/cookoff/