用途
Cookoff 用于从设计阶段进入实现阶段的场景。当设计文档已经完成、用户准备开始实现时，Cookoff 会提供一种“同一设计、多个实现团队竞争”的方式：每个实现团队基于共享的设计文档各自制定实现计划，再独立完成实现，最终通过评审选出最佳方案。
它属于 Test Kitchen Development 体系，与 omakase-off（探索不同方案/设计）互补。其核心洞见是：不要共享预先做好的实现计划，让每个智能体从设计文档自行生成计划，从而确保真正的方案差异。
主要能力
- 在设计到实现的过渡点主动提供 Cookoff 选项。
- 根据设计文档评估复杂度，并映射到实现数量（低=2、中=3、高=4、极高=5）。
- 为每个实现创建独立的 git worktree 与分支。
- 在单条消息中并行派发所有实现智能体。
- 每个智能体使用 writing-plans 创建自己的实现计划，再用 executing-plans 实现，并遵循 TDD 与验证流程。
- 在评审阶段进行门禁检查、重复实现检测、fresh-eyes 审查，并调用 judge 技能按评分框架打分。
- 对胜出者做最终验证，使用 finish-branch 处理合并/PR/保留/丢弃，并清理落选者的 worktree 与分支。
- 生成 result.md 记录结果。
使用方式
触发时机：用户想要实现某个设计时，例如“Execute this plan”“Implement the plan”“Let's build this”，或在头脑风暴完成、设计文档存在之后。也可显式调用：“cookoff this”。
重要：Cookoff 基于设计文档工作，而不是详细的实现计划。每个智能体自行创建实现计划。
检测设计到实现的过渡：Cookoff 在“情境”触发，而非某个特定技能的输出。信号包括：设计文档被写入/提交、用户批准设计（“looks good”“yes”“let's do it”）、讨论从“构建什么”转向“如何构建”、任何技能/流程即将开始实现。检测到该过渡时，应始终提供 Cookoff 选项。
流程分为五个阶段：
- 实现选项：提供单子智能体、Cookoff、本地实现三种选择。
- 复杂度评估：阅读设计文档，评估功能范围、风险区域、实现规模，映射实现数量，创建目录并宣布。
- 并行执行：创建 worktree 与分支，在单条消息中派发所有 Task 工具（run_in_background: true），每个子智能体读取设计文档、用 writing-plans 写自己的计划、用 executing-plans 实现、遵循 TDD、完成前验证，并报告结果。
- 评审：门禁检查（测试通过、符合设计）、检测实现是否高度雷同（>95% 相似则标记）、对幸存者做 fresh-eyes、调用 test-kitchen:judge 按完整评分工作表打分并宣布胜出者。
- 完成：对胜出者做最终验证，使用 finish-branch 处理，清理落选者，写入 result.md。
目录结构：
docs/plans/<feature>/ design.md cookoff/ impl-1/plan.md impl-2/plan.md impl-3/plan.md result.md
适用场景
- 设计已完成、准备开始实现时。
- 中高复杂度的功能。
- 希望获得多种独立实现方案并择优时。
限制
- 需要设计文档作为输入，而非详细实现计划。
- 依赖多个技能（writing-plans、executing-plans、parallel-agents、git-worktrees、tdd、verification、code-review、fresh-eyes、judge、scenario-testing、finish-branch），部分有主/备选来源。
- 若实现高度雷同（>95%），说明规划阶段未产生足够差异，仍会继续但会在结果中标记。
- 评分使用整数分（1-5，无半分），并检查硬门禁（Fitness Δ≥2、任一项得分为 1）。
- 具体收费、价格、平台支持等信息暂未提供。