用途：/sprint 用于批量并行处理多个 GitHub issue。每个 issue 分配到独立 worktree 并强制 TDD 流程，lead agent 只负责协调，同事代理各自实现，最终生成堆叠式 PR。
主要能力：解析逗号分隔的 issue 编号；用 issue-worker 子代理并行抓取每个 issue 的目标、验收标准、边界条件与可能涉及的文件；为各 issue 创建 worktree 并激活 TDD；检测多 issue 是否触碰同一文件以预判冲突；建立 Agent Team（lead 为 delegate 模式，teammates 为每 issue 一个 general-purpose 代理，内部再调用 tester/implementer，必要时运行 /update-docs）；汇总每个代理改动的文件、API 变更、冲突与测试状态；由 pr-planner 决定 PR 顺序，依次 rebase 后创建 stacked PR，并在末尾输出汇总表。
必要用法：调用形式如 /sprint 67,68,69。Step 0 用 echo "${CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS:-not_set}" 检查环境变量；若为 not_set 或空则进入 setup-only 模式，只准备 worktree 并激活 TDD，提示用户进入各 worktree 运行 /write-tests，或设置 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 后重跑 /sprint，且不要调用 /work-on-issue 以免重复创建 worktree。worktree 创建示例：.claude/scripts/worktree-create.sh issue-<N>-<short-desc> && cd .worktrees/issue-<N>-<short-desc> && bash .claude/hooks/tdd-state.sh activate <N> && cd -。堆叠 PR 时首个 PR 以 main 为 base，后续先 git rebase 到前一支分支，再 git push --force-with-lease 并 gh pr create；rebase 冲突需上报用户而非自动解决。
适用场景：多个相关或相互独立的 issue 批量处理，追求最大并行度，单个 issue 变更约小于 200 行。
限制：单 issue 不建议使用（应改用 /work-on-issue）；紧耦合、必须串行或体量很大的 issue 不适用。Agent Teams 需环境变量设为 1，否则功能降级为仅创建 worktree。其他依赖、安装与费用信息暂未提供。