用途
Showdown 用于针对同一份设计文档并行生成多个实现方案并进行竞赛式择优。其定位是“同样的设计，多个 runner 竞争”：每个 runner 从共享设计文档出发，各自独立制定实现计划，再通过托管的 LLM 生成代码。由于规划决策彼此独立，实现方案之间会自然产生差异，从而为后续评审提供多个候选实现。
使用时需要声明：“I'm using speed-run:showdown for parallel competition via hosted LLM.”
主要能力
- 复杂度评估与 runner 数量映射：读取设计文档后评估功能范围（组件、集成、数据模型）、风险区域（认证、支付、迁移、并发）与预估实现规模，并据此决定 runner 数量：低复杂度（小型功能、无风险信号）用 2 个；中（中型功能、部分风险）用 3 个；高（大型功能、多个风险信号）用 4 个；极高（大型系统、关键区域）用 5 个。
- 隔离的并行执行：为每个 runner 建立独立 git worktree 与分支，例如
.worktrees/speed-run-runner-1/与<feature>/speed-run/runner-1。关键要求是在单条消息中派发全部 runner 的 Task 调用（run_in_background: true），以实现并行而非串行。 - 独立规划：每个 runner 通过 writing-plans 从设计文档生成自己的 plan.md，避免所有 runner 复制同一份代码。目录结构为
docs/plans/<feature>/speed-run/showdown/runner-N/plan.md。 - 进度监控：跟踪各 runner 的状态流转，例如 planing → 通过 Cerebras 生成 → 修复 N/M → 测试通过。
- 评审（Judging）：先做门槛检查（全部测试通过、符合设计），再对各实现做 diff 检查是否 >95% 相同（相同则说明规划阶段没有产生足够差异，需在结果中标注但仍继续），随后对所有幸存实现执行 fresh-eyes 审查（安全、逻辑错误、边界情况），最后调用
speed-run:judge技能，由其填写完整评分工作表、Speed-Run Metrics 表、构建 1-5 整数分记分卡、检查硬性门槛（Fitness Δ≥2、任一项得分为 1）并宣布优胜者及理由（含 token 效率）。 - 收尾与清理：对优胜者执行最终验证（测试、构建、设计符合性），使用 finish-branch；清理落选者的 worktree 与分支；写入 result.md。
使用方式
流程分为四个阶段：
Phase 1：复杂度评估 —— 读取设计文档，评估功能范围、风险区域与实现规模，映射为 runner 数量，并广播评估结果与并行计划。
Phase 2：并行执行 —— 创建 worktree 与分支；在单条消息中派发全部 runner（每个 Task 设置 run_in_background: true）；runner 提示词参见 references/runner-agent-prompt.md；随后监控进度。
Phase 3：评审 ——
- 门槛检查：全部测试通过、设计符合性。
- 检查实现是否雷同：
diff -r .worktrees/speed-run-runner-1/src .worktrees/speed-run-runner-2/src，若 >95% 相同则标注。 - 对幸存实现执行 fresh-eyes 审查。
- 调用
speed-run:judge，并为其提供：待评审实现清单、worktree 位置、各 runner 测试结果、fresh-eyes 发现、speed-run 指标（托管 LLM 调用次数、修复轮次、每个 runner 的生成时间）。评审输出应为完整工作表，不得摘要或缩写。
Phase 4：完成 —— 对优胜者做最终验证（测试、构建、设计符合性），用 finish-branch 收尾；落选者执行清理：
git worktree remove .worktrees/speed-run-runner-1
git worktree remove .worktrees/speed-run-runner-3
git branch -D <feature>/speed-run/runner-1
git branch -D <feature>/speed-run/runner-3
最后写入 result.md，存放路径为 docs/plans/<feature>/speed-run/showdown/result.md，内容包括设计文档链接、runner 对比表（规划思路、测试、fresh-eyes、行数、LLM 调用、修复轮次、结果）、各 runner 生成的计划路径、优胜者选择理由与 token 节省估算。
依赖的技能
| 能力 | 首选（若已安装） | 回退方案 |
|---|---|---|
| writing-plans | superpowers:writing-plans | 每个 runner 编写自己的计划 |
| executing-plans | superpowers:executing-plans | 顺序执行计划任务 |
| parallel-agents | superpowers:dispatching-parallel-agents | 单条消息中派发多个 Task 工具 |
| git-worktrees | superpowers:using-git-worktrees | git worktree add .worktrees/<name> -b <branch> |
| tdd | superpowers:test-driven-development | RED-GREEN-REFACTOR 循环 |
| verification | superpowers:verification-before-completion | 先运行命令、读取输出，再声明状态 |
| fresh-eyes | fresh-eyes-review:fresh-eyes-review (2389) | 2-5 分钟审查安全、逻辑、边界情况 |
| judge | speed-run:judge | 带检查清单的评分框架（Phase 4 必须调用） |
| scenario-testing | scenario-testing:scenario-testing (2389) | .scratch/ E2E 脚本、真实依赖 |
| finish-branch | superpowers:finishing-a-development-branch | 验证测试、给出选项、清理 |
适用场景
适用于已经产出设计文档、需要在不共享实现计划的前提下并行探索多个实现路径的场景，尤其适合中高风险功能（如涉及认证、支付、迁移、并发）。在 showdown 中所有 runner 面向同一设计，因此 Fitness 应当相近；若出现 Δ≥2 的差距，通常意味着某个 runner 偏离或误解了设计，而非采用了不同的合理方案。
限制与常见错误
- 共享预先写好的实现计划：会导致所有 runner 复制同一份代码、没有差异；应让每个 runner 用 writing-plans 从设计文档自行生成计划。
- 在分开的多条消息中派发 runner：会变成串行派发；应在单条消息中发送全部 Task 工具调用。
- 所有代码生成都直接用 Claude：违背 speed-run 的初衷（省 token）；runner 必须使用托管 LLM 完成首轮生成。
- 跳过 fresh-eyes：评审将缺少质量信号；应在比较前对所有幸存实现执行 fresh-eyes。
- 不检查实现是否雷同：会在重复实现上浪费算力；应在 fresh-eyes 之前先 diff 各实现。
- 忘记清理：会残留 worktree 与分支；应始终清理落选者并写入 result.md。