team-combat

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Argument check: If no combat feature description is provided, output:

"Usage:
/team-combat [combat feature description]
— Provide a description of the combat feature to design and implement (e.g.,
melee parry system
,
ranged weapon spread
)." Then stop immediately without spawning any subagents or reading any files.

When this skill is invoked with a valid argument, orchestrate the combat team through a structured pipeline.

Decision Points: At each phase transition, use

AskUserQuestion

to present the user with the subagent's proposals as selectable options. Write the agent's full analysis in conversation, then capture the decision with concise labels. The user must approve before moving to the next phase.

参数检查：如果未提供战斗功能描述，则输出：

"Usage:
/team-combat [combat feature description]
— 提供要设计和实现的战斗功能描述（例如：
melee parry system
、
ranged weapon spread
）。" 之后立即停止，不生成任何subagent或读取任何文件。

当传入有效参数调用此技能时，将通过结构化流程统筹战斗团队。

决策节点：在每个阶段过渡时，使用

AskUserQuestion

向用户展示子代理的提案作为可选选项。在对话中写入代理的完整分析，然后用简洁的标签记录决策。用户必须批准后才能进入下一阶段。

Phase 0: Resolve Review Mode

阶段0：确定审核模式

If
```
--review [mode]
```
was passed as an argument, use that mode.
Else read
```
production/review-mode.txt
```
— use whatever is written there.
Else default to
```
lean
```
.

Modes:

```
full
```
— spawn all director and lead gates as described
```
lean
```
— skip director gates unless they are PHASE-GATE type (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE)
```
solo
```
— skip all director gate spawning entirely; run the skill without any agent gates

Store the resolved mode for use in all subsequent phases.

如果参数中包含
```
--review [mode]
```
，则使用该模式。
否则读取
```
production/review-mode.txt
```
文件，使用其中指定的模式。
若以上均无，则默认使用
```
lean
```
模式。

模式说明：

```
full
```
— 生成所有描述中提及的主管和阶段审核节点
```
lean
```
— 除非是PHASE-GATE类型（CD-PHASE-GATE、TD-PHASE-GATE、PR-PHASE-GATE、AD-PHASE-GATE），否则跳过主管审核节点
```
solo
```
— 完全跳过所有主管审核节点的生成；在无代理审核节点的情况下运行该技能

将确定后的模式存储起来，供后续所有阶段使用。

Team Composition

团队组成

game-designer — Design the mechanic, define formulas and edge cases
gameplay-programmer — Implement the core gameplay code
ai-programmer — Implement NPC/enemy AI behavior for the feature
technical-artist — Create VFX, shader effects, and visual feedback
sound-designer — Define audio events, impact sounds, and ambient combat audio
engine specialist (primary) — Validate architecture and implementation patterns are idiomatic for the engine (read from
```
.claude/docs/technical-preferences.md
```
Engine Specialists section)
qa-tester — Write test cases and validate the implementation

game-designer — 设计机制，定义公式和边缘情况
gameplay-programmer — 实现核心玩法代码
ai-programmer — 为该功能实现NPC/敌人AI行为
technical-artist — 创建视觉特效（VFX）、着色器效果和视觉反馈
sound-designer — 定义音频事件、撞击音效和战斗环境音效
engine specialist（主负责人） — 验证架构和实现模式是否符合引擎的惯用规范（读取
```
.claude/docs/technical-preferences.md
```
中的Engine Specialists章节）
qa-tester — 编写测试用例并验证实现效果

How to Delegate

任务分配方式

Use the Task tool to spawn each team member as a subagent:

```
subagent_type: game-designer
```
— Design the mechanic, define formulas and edge cases
```
subagent_type: gameplay-programmer
```
— Implement the core gameplay code
```
subagent_type: ai-programmer
```
— Implement NPC/enemy AI behavior
```
subagent_type: technical-artist
```
— Create VFX, shader effects, visual feedback
```
subagent_type: sound-designer
```
— Define audio events, impact sounds, ambient audio
```
subagent_type: [primary engine specialist]
```
— Engine idiom validation for architecture and implementation
```
subagent_type: qa-tester
```
— Write test cases and validate implementation

Always provide full context in each agent's prompt (design doc path, relevant code files, constraints). Launch independent agents in parallel where the pipeline allows it (e.g., Phase 3 agents can run simultaneously).

使用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: [primary engine specialist]
```
— 验证架构和实现是否符合引擎惯用规范
```
subagent_type: qa-tester
```
— 编写测试用例并验证实现效果

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

Pipeline

流程

Phase 1: Design

阶段1：设计

Delegate to game-designer:

Create or update the design document in
```
design/gdd/
```
covering: mechanic overview, player fantasy, detailed rules, formulas with variable definitions, edge cases, dependencies, tuning knobs with safe ranges, and acceptance criteria
Output: completed design document

委托给game-designer：

在
```
design/gdd/
```
目录下创建或更新设计文档，内容包括：机制概述、玩家体验预期、详细规则、带变量定义的公式、边缘情况、依赖关系、带安全范围的调节参数，以及验收标准
输出：完成的设计文档

Phase 2: Architecture

阶段2：架构设计

Delegate to gameplay-programmer (with ai-programmer if AI is involved):

Review the design document
Design the code architecture: class structure, interfaces, data flow
Identify integration points with existing systems
Output: architecture sketch with file list and interface definitions

Then spawn the primary engine specialist to validate the proposed architecture:

Is the class/node/component structure idiomatic for the pinned engine? (e.g., Godot node hierarchy, Unity MonoBehaviour vs DOTS, Unreal Actor/Component design)
Are there engine-native systems that should be used instead of custom implementations?
Any proposed APIs that are deprecated or changed in the pinned engine version?
Output: engine architecture notes — incorporate into the architecture before Phase 3 begins

Use

AskUserQuestion

Prompt: "Architecture sketch complete. Approve to proceed with parallel implementation."

Options:

[A] Proceed — spawn implementation agents (gameplay-programmer, ai-programmer, technical-artist, sound-designer)

[B] Revise the architecture first — I'll describe what needs to change

```
[C] Stop here — I'll continue later
```

Only spawn implementation agents if user selects [A].

委托给gameplay-programmer（若涉及AI则联合ai-programmer）：

审阅设计文档
设计代码架构：类结构、接口、数据流
识别与现有系统的集成点
输出：包含文件列表和接口定义的架构草图

然后生成主引擎专家来验证提议的架构：

类/节点/组件结构是否符合指定引擎的惯用规范？（例如Godot节点层级、Unity MonoBehaviour与DOTS对比、Unreal Actor/Component设计）
是否应使用引擎原生系统而非自定义实现？
提议的API是否在指定引擎版本中已被弃用或更改？
输出：引擎架构说明 — 在进入阶段3前将其整合到架构中

使用

AskUserQuestion

：

提示："架构草图已完成。请批准以启动并行实现。"

选项：

[A] 继续 — 生成实现代理（gameplay-programmer、ai-programmer、technical-artist、sound-designer）

[B] 先修改架构 — 我将描述需要更改的内容

```
[C] 在此停止 — 我稍后再继续
```

仅当用户选择[A]时才生成实现代理。

Phase 3: Implementation (parallel where possible)

阶段3：实现（尽可能并行）

Delegate in parallel:

gameplay-programmer: Implement core combat mechanic code
ai-programmer: Implement AI behaviors (if the feature involves NPC reactions)
technical-artist: Create VFX and shader effects
sound-designer: Define audio event list and mixing notes

并行委托：

gameplay-programmer：实现核心战斗机制代码
ai-programmer：实现AI行为（若该功能涉及NPC反应）
technical-artist：创建VFX和着色器效果
sound-designer：定义音频事件列表和混音说明

Phase 4: Integration

阶段4：集成

Wire together gameplay code, AI, VFX, and audio
Ensure all tuning knobs are exposed and data-driven
Verify the feature works with existing combat systems

将玩法代码、AI、VFX和音频整合在一起
确保所有调节参数均已暴露且支持数据驱动
验证该功能与现有战斗系统兼容

Phase 5: Validation

阶段5：验证

Delegate to qa-tester:

Write test cases from the acceptance criteria
Test all edge cases documented in the design
Verify performance impact is within budget
File bug reports for any issues found

委托给qa-tester：

根据验收标准编写测试用例
测试设计文档中记录的所有边缘情况
验证性能影响在预算范围内
为发现的问题提交错误报告

Phase 6: Sign-off

阶段6：验收

Collect results from all team members
Report feature status: COMPLETE / NEEDS WORK / BLOCKED
List any outstanding issues and their assigned owners

收集所有团队成员的成果
报告功能状态：COMPLETE / NEEDS WORK / BLOCKED
列出所有未解决的问题及其负责人

Error Recovery Protocol

错误恢复协议

If any spawned agent (via Task) returns BLOCKED, errors, or cannot complete:

Surface immediately: Report "[AgentName]: BLOCKED — [reason]" to the user before continuing to dependent phases
Assess dependencies: Check whether the blocked agent's output is required by subsequent phases. If yes, do not proceed past that dependency point without user input.
Offer options via AskUserQuestion with choices:
- Skip this agent and note the gap in the final report
- Retry with narrower scope
- Stop here and resolve the blocker first
Always produce a partial report — output whatever was completed. Never discard work because one agent blocked.

Common blockers:

Input file missing (story not found, GDD absent) → redirect to the skill that creates it
ADR status is Proposed → do not implement; run
```
/architecture-decision
```
first
Scope too large → split into two stories via
```
/create-stories
```
Conflicting instructions between ADR and story → surface the conflict, do not guess

如果任何通过Task生成的代理返回BLOCKED、报错或无法完成任务：

立即反馈：在进入依赖阶段前，向用户报告"[AgentName]: BLOCKED — [原因]"
评估依赖：检查被阻塞代理的输出是否为后续阶段所需。若是，在未获得用户输入前不得越过该依赖节点。
提供选项：通过AskUserQuestion提供以下选择：
- 跳过该代理，在最终报告中注明缺口
- 缩小范围后重试
- 在此停止，先解决阻塞问题
始终生成部分报告 — 输出所有已完成的工作。不得因单个代理阻塞而丢弃已完成的成果。

常见阻塞情况：

输入文件缺失（未找到剧情、无GDD文档）→ 引导至创建该文件的技能
ADR状态为Proposed → 不得实现；先运行
```
/architecture-decision
```
范围过大 → 通过
```
/create-stories
```
拆分为两个任务
ADR与任务之间存在冲突指令 → 反馈冲突，不得自行猜测

File Write Protocol

文件写入规则

All file writes (design documents, implementation files, test cases) are delegated to sub-agents spawned via Task. Each sub-agent enforces the "May I write to [path]?" protocol. This orchestrator does not write files directly.

所有文件写入操作（设计文档、实现文件、测试用例）均委托给通过Task生成的子代理。每个子代理需执行"是否允许写入[路径]？"的规则。此统筹器不直接写入文件。

Output

输出

A summary report covering: design completion status, implementation status per team member, test results, and any open issues.

Verdict: COMPLETE — combat feature designed, implemented, and validated. Verdict: BLOCKED — one or more phases could not complete; partial report produced with unresolved items listed.

一份总结报告，内容包括：设计完成状态、各团队成员的实现状态、测试结果以及所有未解决的问题。

结论：COMPLETE — 战斗功能已完成设计、实现和验证。结论：BLOCKED — 一个或多个阶段无法完成；生成包含未解决项的部分报告。

Next Steps

后续步骤

Run
```
/code-review
```
on the implemented combat code before closing stories.
Run
```
/balance-check
```
to validate combat formulas and tuning values.
Run
```
/team-polish
```
if VFX, audio, or performance polish is needed.

在关闭任务前，对已实现的战斗代码运行
```
/code-review
```
。
运行
```
/balance-check
```
以验证战斗公式和调节参数。
若需要优化VFX、音频或性能，运行
```
/team-polish
```
。