team-level

Team Level

如果未提供参数，则输出使用说明并退出，不启动任何 Agent，也不读取任何设计文件：

用法：/team-level [level name or area to design] [--review full|lean|solo] — 指定要设计的关卡或区域（例如，forest temple、tutorial village、final boss arena）。此处不要使用 AskUserQuestion；直接输出说明。

调用此技能时：

决策点： 在每次步骤转换时，使用 AskUserQuestion 将子 Agent 的提案作为可选项呈现给用户。在对话中写出 Agent 的完整分析，然后用简洁的标签记录决策。在 collaborative 模式下，用户必须批准后才能进入下一步。在 guided 模式下，除非某一步处于 BLOCKED 状态，否则流程会自动推进；在 autonomous 模式下，流程会端到端运行，并通过 log_decision 记录每一步的结果。automation_always_ask 类别（is_always_ask_category helper）中的决策无论处于哪种模式都始终会提示用户。参见 .claude/docs/automation-modes.md。

Phase 0: Resolve Config

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,team.size

已在上方解析 — 按原样使用；--review 会覆盖 review_mode。未阻塞 → 使用 .claude/docs/config-resolution.md 中的默认值。

review_mode 决定 director-gate 的深度，而此流程不包含 director gate： 无论 review_mode 为何，以下阶段都不会启动 CD-、TD-、PR- 或 AD-PHASE-GATE。其阶段关卡是本流程自身的决策点（定义于下方 team.size），在这些关卡工作的 Agent 是团队成员，而非 director gate。

automation 决定上方“决策点”说明的行为。有关各模式如何改变流程行为，请参见上方“决策点”说明和 .claude/docs/automation-modes.md。

team.size：决定哪些 Agent 处于启用状态（与 review_mode 的关卡深度和工作流文档相互独立）。

• individual（默认）：仅启用 level-designer。其他 Agent 由 level-designer 咨询，不单独启动。
• small：另加 systems-designer、art-director 和 qa-tester。
• studio：另加 narrative-director、world-builder 和 accessibility-specialist（文档所述的完整流程）。 在 individual 模式下，需要用到的非核心 Agent 会转由最近的启用核心 Agent 处理，并附上说明性注记。“阶段关卡”是指本流程自行列出的、以 AskUserQuestion 决策点结束的任何阶段 — 上方“决策点”中提到的步骤转换，或下方流程中列出的 Gate 步骤 — 无论 automation 模式如何。guided 和 autonomous 会改变通过关卡的方式（自动推进，或使用 log_decision 记录），但不会改变它是否属于关卡，因此下方的有界例外条件 (3) 在所有模式下都适用。仅限“阶段关卡”启动的 Agent 只会在这些关卡启动，不会在其他地方启动。此启用集范围规则适用于下方的整个流程：任何阶段中指定的 Agent 若不在启用集中，都应转由最近的核心 Agent 处理，而不是启动该 Agent。

在步骤 1 之前声明启用集 — 绝不能默默缩减。 启动任何内容之前，用一行说明本次运行实际会启动哪些 Agent，以及流程中提到但在已解析的 team.size 下不会启动哪些 Agent。例如：

Active set (team.size: <resolved>): <the agents listed for that size above>. Not spawned this run: <every other agent this pipeline names> — consulted through <nearest active core agent>. Raise team.size (or modes.rigor) to widen.

直接根据上方 team.size 列表和本文件流程中列出的 Agent 填写 — 不要照搬示例。不同的编排器对应的两个集合也各不相同。 下面的流水线看起来会并行分派给多个 Agent，但在发布时的默认配置中，它只会运行一两个 Agent——team-release 列出了 10 个 Agent，却只运行一个；team-narrative 在五个阶段中列出了 6 个 Agent，却只运行 writer。这种收敛是正确的：team.size 以严谨性为优先，精简的默认配置则是控制令牌用量的手段。如果不明确说明这一点，读者就无法区分这是正确收敛的运行，还是流水线出了问题；而上文提到的、针对每个 Agent 的“通过最近的核心 Agent 路由，并附带说明”规则会在路由时触发，却从未说明整体运行的形态。

这与本文其他位置报告跳过的检查时遵循的规则相同：对读者而言，一项已执行却从未说明的约束，与从未执行过的约束无法区分。

1. 读取需求，确定目标级别或区域（例如 tutorial、forest dungeon、hub town、final boss arena）。

2. 收集上下文（按章节阅读每份设计文档：使用 Grep 工具并在内容模式下以 ^# 为模式查找所需标题，再通过 offset 和 limit 读取相应范围）：

   • 如果 design/gdd/game-concept.md 或 design/game-brief.md 存在，则阅读游戏概念文档；在 rigor: minimal 时，后者是一页式简报，用于替代前者
   • 阅读游戏支柱文档 design/gdd/game-pillars.md
   • 阅读 design/levels/ 中现有的关卡文档
   • 阅读 design/narrative/ 中相关的叙事文档
   • 阅读该区域所在地域或派系的世界观构建文档

如何委派

使用 Agent 工具将每位团队成员作为子 Agent 启动：

• subagent_type: narrative-director — 叙事目的、角色、情感弧线
• subagent_type: world-builder — 背景设定、环境叙事、世界规则
• subagent_type: level-designer — 空间布局、节奏、遭遇、导航
• subagent_type: systems-designer — 敌人配置、战利品表、难度平衡
• subagent_type: art-director — 视觉主题、调色板、灯光、资源需求
• subagent_type: accessibility-specialist — 导航清晰度、色盲安全性、认知负荷
• subagent_type: qa-tester — 测试用例、边界测试、试玩检查清单

向每位 Agent 提供简要说明——不要倾倒所有上下文。 只读取一次共享输入，并在提示中传递提炼后的简要内容：只提供每位 Agent 实际需要的内容，绝不要提供你已经读过的文档路径（拿到路径的 Agent 会重新读取整个文件）。只有当某份文档你尚未读过且仅该 Agent 需要时，才传递其路径。

每条 Agent 提示都必须以返回约定结尾：“将完整输出写入 [path]——该指定路径是你在下方有限例外范围内获得写入授权的路径，因此无需另行请求批准即可写入。仅返回 (1) 写入的路径，(2) 不超过 5 条的决策摘要，(3) 任何 BLOCKED/CONCERNS 项目，每项一行。不要复述你读过的文档。” 如果没有这项约定，Agent 会把读过的所有内容都返回到本会话中。

将 [path] 替换为真实路径。 工作文件应放在 production/levels/[level-name]/ 下，并按下文“保存到”步骤中的规则生成 slug。每位 Agent 对应一个文件，因此并行步骤之间不会共用文件：

步骤 / Agent	写入位置
1 narrative-director	production/levels/[level-name]/narrative.md
1 world-builder	production/levels/[level-name]/lore.md
1 art-director	production/levels/[level-name]/visual-direction.md
2 level-designer	production/levels/[level-name]/layout.md
3 systems-designer	production/levels/[level-name]/systems.md
4 art-director	production/levels/[level-name]/production-concepts.md
4 accessibility-specialist	production/levels/[level-name]/accessibility.md
5 qa-tester	production/qa/test-cases/[level-name]-cases.md — 测试用例、边界情况、试玩检查清单、验收标准

这些是工作草稿；持久记录是你根据这些草稿整理编写的关卡设计文档（design/levels/[level-name].md）。

为何这不违反协作协议。 CLAUDE.md 要求 Agent 在 Write/Edit 之前询问“我可以将其写入 [filepath] 吗？”。在此启动的子 Agent 无需询问即可写入，这是有意设定的有限例外，并非疏忽——与已对 consistency-check 追加到 active.md 所做的处理相同。只有同时满足以下三项条件时，例外才适用：(1) 路径是你在提示中指定的，因此用户在批准该阶段时也批准了目标位置；(2) 这是 production/、docs/ 或 tests/ 下的新文件，绝不修改现有源文件或配置；(3) 生成该文件的阶段本身受 AskUserQuestion 门控，须经确认后流程才能继续。除此之外，Agent 必须先询问。不要通过逐个询问子 Agent 来“修正”此问题——每个阶段都向每位 Agent 单独发出提示会让编排器无法使用，这正是设立此例外的原因。

3. 按顺序编排关卡设计团队：

第 1 步：叙事与视觉方向（narrative-director + world-builder + art-director，并行）

同时启动这 3 个 Agent——先发出全部 3 个 Agent 调用，再等待任何结果。

启动 narrative-director Agent，以便：

• 定义此区域的叙事目的（这里会发生哪些故事情节？）
• 确定关键角色、对话触发条件和传说元素
• 指定情感弧线（玩家进入、探索期间和离开时应有怎样的感受？）

启动 world-builder Agent，以便：

• 提供此区域的背景设定（历史、派系分布、生态）
• 定义环境叙事的机会
• 指定影响此区域玩法的世界规则

启动 art-director Agent，以便：

• 确定此区域的视觉主题目标——这些是布局的输入，而非布局的输出
• 定义此区域的色温和光照氛围（与相邻区域有何不同？）
• 指定造型语言方向（棱角分明的堡垒？有机洞穴？衰败的宏伟感？）
• 列出用于帮助玩家辨认方向的主要视觉地标
• 如果 design/art/art-bible.md 存在，则读取该文件——所有方向都必须以既定的美术圣经为依据。按章节读取：使用 Grep 工具查找所需标题（模式 ^#，内容模式），再使用 Read 按 offset 和 limit 读取对应范围。

艺术总监在第 1 步提出的视觉目标必须作为明确约束传递给第 2 步的关卡设计师。布局决策应在视觉方向的框架内进行，而非先于视觉方向。

关卡：使用 AskUserQuestion 展示第 1 步的全部 3 项输出（叙事概要、背景设定基础、视觉方向目标），并在继续第 2 步前征求确认。

第 2 步：布局与遭遇设计（level-designer）

启动 level-designer Agent，并将第 1 步的完整输出作为上下文传入：

• 叙事概要（来自 narrative-director）
• 背景设定基础（来自 world-builder）
• 视觉方向目标（来自 art-director）——布局必须符合这些目标，不得与之冲突

level-designer 应：

• 设计空间布局（主线、可选路线、秘密区域）——确保主要路线与第 1 步的视觉地标目标一致
• 定义节奏曲线（紧张峰值、休息区域、探索区域）——与 narrative-director 提出的情感弧线协调
• 安排遭遇，并逐步提升难度
• 设计环境谜题或导航挑战
• 定义用于寻路的兴趣点和地标——这些必须与 art-director 指定的视觉地标相符
• 指定入口、出口以及与相邻区域的连接

相邻区域依赖项检查：生成布局后，检查 design/levels/ 中 level-designer 引用的每个相邻区域。如果任何被引用区域的 .md 文件不存在，则指出这一缺口：

“关卡将 [area-name] 作为相邻区域引用，但 design/levels/[area-name].md 不存在。”

使用 AskUserQuestion 并提供以下选项：

• (a) 使用占位引用继续——在关卡文档中将该连接标记为 UNRESOLVED，并在摘要报告的未解决跨关卡依赖项部分列出
• (b) 暂停，并先运行 /team-level [area-name] 来创建该区域

不得编造缺失相邻区域的内容。

关卡：使用 AskUserQuestion 展示第 2 步的布局（包括任何未解决的相邻区域依赖项），并在继续第 3 步前征求确认。

第 3 步：系统集成（systems-designer）

启动 systems-designer Agent，以便：

• 指定敌人组合和遭遇公式
• 定义战利品表和奖励布置
• 根据预期玩家等级/装备平衡难度
• 设计区域专属机制或环境危害
• 指定资源分布（生命值补给、存档点、商店）

关卡：使用 AskUserQuestion 展示第 3 步的输出，并在继续第 4 步前征求确认。

第 4 步：制作概念与无障碍设计（art-director + accessibility-specialist，并行）

注意：art-director 在第 1 步完成了方向性设计（视觉主题、色彩目标、氛围）。本轮是针对具体地点的制作概念：在布局最终确定后，各个特定空间会是什么样子？

向 art-director agent 提供第 2 步确定的布局，并启动该 agent：

• 为关键空间（入口、关键遭遇区域、地标、出口）制定针对具体地点的概念规格
• 指明哪些美术资产是该区域专属的，哪些可从全局资源库共享
• 为每个关键空间定义视线与灯光设置（这些设置现在依据布局确定，而非方向性设计）
• 指明针对该区域布局的 VFX 需求（天气区域、粒子、氛围效果）
• 标记布局与第 1 步目标在视觉方向上存在冲突的地点，并将其列为制作风险

并行启动 accessibility-specialist agent，以便：

• 审查关卡布局的导航清晰度（玩家能否在不依赖颜色的情况下辨别方向？）
• 检查关键路径的指引是否除颜色之外还使用了形状、图标或声音提示
• 审查谜题机制的认知负担，并标记任何要求同时记住超过 3 种状态的内容
• 检查关键游戏区域是否为色盲玩家提供了足够的对比度
• 输出：附带严重程度的无障碍问题清单（BLOCKING / RECOMMENDED / NICE TO HAVE）

等待两个 agent 都返回后再继续。

关卡：使用 AskUserQuestion 呈现第 4 步的两项结果。如果 accessibility-specialist 返回了任何 BLOCKING 问题，请醒目突出显示，并提供以下选项：

• (a) 返回 level-designer 和 art-director，要求他们在第 5 步之前重新设计已标记的元素
• (b) 将其记录为已知的无障碍缺陷，并在最终报告中明确记录该问题后继续第 5 步

在用户确认任何 BLOCKING 无障碍问题之前，切勿继续第 5 步。

第 5 步：QA 规划（qa-tester）

启动 qa-tester agent，以便：

• 为关键路径编写测试用例
• 找出边界和边缘情况（流程中断、软锁）
• 为该区域创建游戏测试清单
• 定义关卡完成的验收标准

4. 汇总关卡设计文档，将团队所有输出整合到关卡设计模板格式中。

编排器已经持有每个子 agent 的输出——**请自行汇总文档；不要重新启动 level-designer 并原样重新发送所有输出。**第二次启动 agent 会额外产生新的 agent 开销，还要重新传输一遍编排器已经持有的上下文，只为搬运编排器已经持有的文本。汇总成关卡设计模板格式后，通过 AskUserQuestion 直接询问用户：“我可以将汇总后的关卡设计写入 design/levels/[level-name].md 吗？”获得批准后，写入文件。

5. 获得批准后保存到 design/levels/[level-name].md。 [level-name] 参数应为 slug 格式——全部小写，空格替换为连字符 （forest dungeon → forest-dungeon.md）——相邻区域检查中的 [area-name] 也应以相同方式转换为 slug。

6. 输出摘要，包含：区域概览、遭遇数量、预估资产 清单、叙事节拍、任何跨团队依赖项或待解决问题、尚未设计但已引用的相邻区域所涉及的未解决跨关卡依赖项（每项标记为 UNRESOLVED），以及无障碍问题和其解决状态。

文件写入协议

每个 Agent 的产物（叙述性文档、测试检查清单）由产出它们的子 Agent 编写，遵循上文「为何这不违反协作协议」中记录的有限例外——路径由你指定，产物是在 production/、docs/ 或 tests/ 下新建的，且该阶段由 AskUserQuestion 门控。在这些范围内，子 Agent 无需在每次写入前征求许可；超出范围则必须询问。唯一的例外是最终编译的关卡设计文档：协调 Agent 已掌握所有输入，因此会在自己发出「我可以写入……吗？」提示（步骤 4）后，自行编译并写入该文件——仅仅为了让一个 Agent 写入协调 Agent 已经掌握的文本而重新启动它，纯属额外开销。

结论：已完成——关卡设计文档已产出，团队的所有输出均已编译。 结论：受阻——一个或多个 Agent 受阻，或跳过了某个 Agent（.claude/docs/error-recovery-protocol.md 第 5 步）；已生成部分报告，并列出未解决事项。

后续步骤

• 运行 /design-review design/levels/[level-name].md，验证已完成的关卡设计文档。
• 设计获批后，运行 /dev-story 实现关卡内容。
• 运行 /qa-plan 为此关卡生成 QA 测试计划。

错误恢复协议

首先，验证产物。 如果返回约定中指定了路径，请先检查该路径是否存在，再将此阶段视为已完成——指定的产物若未写入磁盘，则此阶段即告失败，无论回复读起来多么流畅。 Agent 可能耗费整个阶段，最后只返回一段看似可信的引言，却什么也没写；这既不属于受阻、错误，也不属于「无法完成」，因此下面的触发条件永远不会生效。请明确指出未满足的约定并恢复执行；上下文通常仍然保留。

如果任何已启动的 Agent 返回受阻、出错或无法完成：立即说明情况，不要越过其所阻碍的依赖项继续推进，并始终生成部分报告。 被跳过的 Agent 所负责的部分应作为明确列出的缺口保留——绝不要自行补写内容。完整流程：.claude/docs/error-recovery-protocol.md。

常见阻碍：

• 缺少输入文件（未找到故事、缺少 GDD）→ 转到创建该文件的技能
• ADR 状态为 Proposed → 不要实现；待其确定后，使用 /architecture-decision accept ADR-NNNN 接受它
• 范围过大 → 通过 /create-stories 拆分为两个故事
• ADR 与故事之间的指示相互冲突 → 指出冲突，不要猜测