用途
Showdown 用于在同一份设计下并行运行多个实现者（runner），让它们各自独立制定计划并通过托管 LLM 生成代码，最终评选出最佳实现。其关键设计点在于：不共享预制实现计划，每个 runner 从设计文档自行生成计划，以保证产生真实的差异。
主要能力
- 根据设计文档的复杂度评估，映射到 2 至 5 个并行 runner。
- 每个 runner 独立编写自己的实现计划并保存到独立目录。
- 通过托管 LLM 进行首轮代码生成，遵循 TDD 流程。
- 在独立 git worktree 与分支中并行执行。
- 对存活实现进行 fresh-eyes 审查，并调用 judge 技能进行打分评选。
- 输出 result.md 记录结果与优胜者，并清理失败者的 worktree 和分支。
使用方式
目录结构：docs/plans/<feature>/ 下包含 design.md，以及 speed-run/showdown/ 下的 runner-1 至 runner-N 的 plan.md 与最终 result.md。
阶段流程：
- 复杂度评估：读取设计文档，评估功能范围、风险区域与实现规模，映射到 runner 数量（低=2、中=3、高=4、极高=5）。
- 并行执行：为每个 runner 建立 worktree 与分支，在单条消息中同时派发所有 Task（run_in_background: true）。每个 runner 读取设计文档、用自己的计划、通过托管 LLM 生成代码、跑测试并用 Edit 做小幅修复。
- 评审：门控检查（测试通过、符合设计），diff 检查实现是否过度雷同，对存活者做 fresh-eyes 审查，然后调用 speed-run:judge 进行打分与优胜者评选。
- 完成：对优胜者做最终验证，用 finish-branch 收尾，清理失败者的 worktree 和分支，写入 result.md。
相关技能依赖包括 writing-plans、executing-plans、parallel-agents、git-worktrees、tdd、verification、fresh-eyes、judge、scenario-testing、finish-branch。
适用场景
需要对同一份设计尝试多种实现路径并对比质量时；希望利用托管 LLM 降低代码生成 token 消耗时；需要并行推进多个实现方案的开发流程。
限制
应避免常见错误：不要共享预制实现计划（会导致实现雷同）、不要分开发送 runner 任务（会变成串行）、不要全部用 Claude 直接生成代码、不要跳过 fresh-eyes 审查、评审前应检查实现是否雷同、并务必清理失败者的 worktree 与分支。价格、可用平台与其他收费信息暂未提供。