team-combat

---
name: team-combat
description: "编排战斗团队：协调 game-designer、gameplay-programmer、ai-programmer、technical-artist、sound-designer 和 qa-tester，端到端地设计、实现并验证战斗功能。"
argument-hint: "[战斗功能描述]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion, TodoWrite
---
当此技能被调用时，通过结构化流水线编排战斗团队。

**决策点：** 在每个阶段转换时，使用 `AskUserQuestion` 将子代理的方案作为可选项呈现给用户。在对话中展示代理的完整分析，然后用简洁的标签记录决策。用户批准后方可进入下一阶段。

## 团队组成
- **game-designer（游戏设计师）** — 设计机制，定义公式和边缘情况（Edge Case）
- **gameplay-programmer（玩法程序员）** — 实现核心玩法代码
- **ai-programmer（AI 程序员）** — 实现与该功能相关的 NPC/敌人 AI 行为
- **technical-artist（技术美术）** — 创建 VFX（视觉效果）、着色器（Shader）效果和视觉反馈
- **sound-designer（音效设计师）** — 定义音频事件、打击音效和环境战斗音频
- **qa-tester（QA 测试员）** — 编写测试用例并验证实现

## 如何委派

使用 Task 工具将每位团队成员生成为子代理：
- `subagent_type: game-designer` — 设计机制，定义公式和边缘情况
- `subagent_type: gameplay-programmer` — 实现核心玩法代码
- `subagent_type: ai-programmer` — 实现 NPC/敌人 AI 行为
- `subagent_type: technical-artist` — 创建 VFX、着色器效果、视觉反馈
- `subagent_type: sound-designer` — 定义音频事件、打击音效、环境音频
- `subagent_type: qa-tester` — 编写测试用例并验证实现

始终在每个代理的提示中提供完整上下文（设计文档路径、相关代码文件、约束条件）。在流水线允许的情况下并行启动独立代理（例如，阶段 3 的代理可以同时运行）。

## 流水线

### 阶段 1：设计
委派给 **game-designer**：
- 在 `design/gdd/` 中创建或更新设计文档，涵盖：机制概述、玩家幻想、详细规则、含变量定义的公式、边缘情况、依赖项、含安全范围的调优旋钮（Tuning Knob）以及验收标准（Acceptance Criteria）
- 输出：完成的设计文档

### 阶段 2：架构设计
委派给 **gameplay-programmer**（如涉及 AI，同时委派 **ai-programmer**）：
- 审查设计文档
- 设计代码架构：类结构、接口、数据流
- 识别与现有系统的集成点
- 输出：架构草图，含文件列表和接口定义

### 阶段 3：实现（尽可能并行）
并行委派：
- **gameplay-programmer**：实现核心战斗机制代码
- **ai-programmer**：实现 AI 行为（如果功能涉及 NPC 反应）
- **technical-artist**：创建 VFX 和着色器效果
- **sound-designer**：定义音频事件列表和混音说明

### 阶段 4：集成
- 连接玩法代码、AI、VFX 和音频
- 确保所有调优旋钮已暴露且数据驱动
- 验证功能与现有战斗系统的兼容性

### 阶段 5：验证
委派给 **qa-tester**：
- 根据验收标准编写测试用例
- 测试设计文档中记录的所有边缘情况
- 验证性能影响在预算范围内
- 为发现的问题提交缺陷报告（Bug Report）

### 阶段 6：签收
- 收集所有团队成员的结果
- 报告功能状态：完成 / 需要修改 / 阻塞
- 列出所有未解决问题及其负责人

## 输出
一份总结报告，涵盖：设计完成状态、各团队成员的实现状态、测试结果以及任何未解决的问题。