team-narrative

团队叙事

如果未提供参数，则输出使用说明并退出，不启动任何 Agent：

用法：/team-narrative [narrative content description] [--review full|lean|solo] — 描述要处理的故事内容、场景或叙事领域（例如，boss encounter cutscene、faction intro dialogue、tutorial narrative）。此处不要使用 AskUserQuestion；直接输出使用说明。

使用参数调用此技能时，通过结构化流程协调叙事团队。

决策点： 在每个阶段转换时，使用 AskUserQuestion 将子 Agent 的提案作为可选项呈现给用户。 在对话中写出 Agent 的完整分析，然后用简洁标签记录决定。 在 collaborative 模式下，用户必须批准后才能进入下一阶段。 在 guided 模式下，除非某个阶段被阻塞，否则流程会自动推进； 在 autonomous 模式下，流程会端到端运行，并通过 log_decision 记录每个阶段的结果。 automation_always_ask 类别中的决策（is_always_ask_category 辅助函数）无论处于何种模式都必须征求用户意见。请参阅 .claude/docs/automation-modes.md。

阶段 0：解析配置

!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。

在所有模式下，Phase 4 的 ND-CONSISTENCY 都是例外：它是此流水线自身的审查，而非可选的 director gate，因此 review_mode 永远不会跳过它（由 team.size 决定谁来执行——参见 Phase 4）。

automation 控制上方的 Decision Points 说明。有关各模式如何改变流水线行为，请参阅上方的 Decision Points 说明和 .claude/docs/automation-modes.md。

team.size：哪些 Agent 处于激活状态（与 review_mode 的 gate 深度和工作流文档相互独立）。

• individual（默认）：仅 writer；只有在明确出现支柱冲突时才调用 narrative-director。其他 Agent 由 writer 征询，不会单独启动。
• small：narrative-director + writer；当 review_mode 为 full 时，还包括 localization-lead 和 world-builder（在 lean 和 solo 下由 writer 征询）。
• studio：六位 Team Composition Agent 全部参与，不受 review_mode 影响（即文档所述的完整流水线）。 在 individual 下需要非核心 Agent 时，由最近的激活核心 Agent 处理，并附上说明性备注。“阶段门”指此流水线明确列出的、以 AskUserQuestion 决策点结束的任何阶段——即上方 Decision Points 中的转换，或下方流水线中写明的 Gate 步骤——不受 automation 模式影响。guided 和 autonomous 会改变通过阶段门的方式（自动推进，或通过 log_decision 记录），而不会改变其性质，因此下述有界例外条件 (3) 在所有模式的阶段门处均成立。仅限“阶段门”的 Agent 会在这些节点启动，其他时候不会启动。此激活集范围规则适用于下方整个流水线：任何阶段指定的 Agent 若不在激活集中，就由最近的核心 Agent 处理，而不会启动该 Agent。

在 Phase 1 之前公布激活集——绝不能默默缩减。 启动任何内容之前，用一行说明本次运行实际会启动哪些 Agent，以及下方流水线提到但在解析出的 team.size 下不会启动哪些 Agent。例如：

Active set (team.size: <已解析值>): <上方列出的该规格对应的 agents>. Not spawned this run: <此流水线提到的其他所有 agents> — consulted through <nearest active core agent>. Raise team.size (or modes.rigor) to widen.

直接依据上方的 team.size 列表和此文件自身流水线中提到的 Agent 填写，不要依据示例。每个编排器的两组内容都不同。

下方流水线看起来像是多 Agent 扇出流程，但在随附的默认设置下实际只有一两个 Agent——team-release 提到了十个，实际只运行一个；team-narrative 在五个阶段中提到了六个，实际只运行 writer。这种缩减是正确的： team.size 以严谨度为先，较窄的默认设置是控制 token 用量的手段。 若不说明这一点，读者便无法区分这是正确缩减还是流水线故障；而上方“由最近的核心 Agent 处理，并附上说明性备注”的逐 Agent 规则会在路由时触发，却永远不会说明整次运行的总体形态。

这与此文件其他位置有关跳过检查的报告规则相同：一项约束即使已执行，若从未明示，对阅读输出的人来说，也无法与从未执行区分开来。

团队构成

• narrative-director — 故事线、角色设计、对话策略、叙事愿景
• writer — 对话创作、背景设定条目、物品描述、游戏内文本
• world-builder — 世界规则、派系设计、历史、地理、环境叙事
• art-director — 角色视觉设计、环境视觉叙事、过场动画／电影化基调
• level-designer — 服务于叙事的关卡布局、节奏、环境叙事节点
• localization-lead — 本地化准备情况——标记不可本地化字符串、文化假设和 i18n 缺口

如何委派

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

• subagent_type: narrative-director — 故事线、角色设计、叙事愿景
• subagent_type: writer — 对话创作、背景设定条目、游戏内文本
• subagent_type: world-builder — 世界规则、派系设计、历史、地理
• subagent_type: art-director — 角色视觉档案、环境视觉叙事、电影化基调
• subagent_type: level-designer — 服务于叙事的关卡布局、节奏
• subagent_type: localization-lead — 本地化准备情况——标记不可本地化字符串、文化假设和 i18n 缺口

先阅读正史。 在阶段 1 之前，阅读现有的共享输入——叙事圣经或基调指南、design/narrative/ 下的角色和派系文件，以及世界规则。绝不要让 Agent 虚构正史：如果没有相关内容，请明确说明，并在起草任何内容前征求用户意见。

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

每条 Agent 提示词都以交付约定结尾：“将完整输出写入 [path]——该指定路径属于下述有限例外范围内的写入授权，因此请直接写入，无需另行请求批准。仅返回 (1) 写入的路径，(2) 不超过 5 条要点的决策摘要，(3) BLOCKED/CONCERNS 项，每项各占一行。不要复述你读过的文档。”如果没有这段约定，Agent 会把读过的所有内容都返回到当前会话中。

用真实路径替换 [path]。 Agent 将草稿写入 production/narrative/[content-slug]/——此路径位于下述有限例外范围内。最终文档应放在 design/narrative/，该目录不在例外范围内，因此由你在获得一次批准后写入（参见“写入最终文档”）：

Agent	草稿写入位置（[path]）	最终文档（由你写入）
narrative-director	production/narrative/[content-slug]/brief.md	design/narrative/[content-slug]-brief.md
world-builder	production/narrative/[content-slug]/lore-[topic].md	design/narrative/lore/[topic].md
writer	production/narrative/[content-slug]/dialogue-[scene-slug].md	design/narrative/dialogue/[scene-slug].md
art-director	production/narrative/[content-slug]/visual-direction.md	design/narrative/[content-slug]-visual-direction.md
level-designer	production/narrative/[content-slug]/level-integration.md	design/narrative/[content-slug]-level-integration.md
localization-lead	production/narrative/[content-slug]/i18n-review.md	保留在 production/ 中——这是审查文件，不是设计文档

最终目标位置并非可自由选择。 design/narrative/ 会被 /asset-spec、/design-review、/localize、/onboard、 /project-stage-detect、/team-level 和 cd-narrative 总监关卡读取。 写在其他任何位置的产物对这七者来说都不可见。

上述 [path] 约定有一个前提：路径是由你指定的。如果某个技能说明了约定，却没有指定具体目标位置，就会让每次运行都自行编造一个位置，这样便失去了约定的意义。出于同样的原因，/team-qa 第 4 阶段也有相同要求。

这为何不违反协作协议。 CLAUDE.md 要求 Agent 在使用 Write/Edit 前先询问“我可以将此内容写入 [filepath] 吗？”。在此处启动的子 Agent 会不经询问直接写入，这是有意设置、范围明确的例外，而非疏忽——这与此前允许 consistency-check 追加写入 active.md 的处理相同。只有以下三项条件全部满足时，例外才成立：(1) 路径是你在提示词中指定的，因此用户在批准该阶段时也批准了目标位置；(2) 这是 production/、docs/ 或 tests/ 下的新产物，绝不能修改现有源文件或配置；(3) 生成该产物的阶段本身受 AskUserQuestion 把关，必须通过后流水线才能继续。除此之外，Agent 必须先询问。不要试图通过逐个询问子 Agent 来“修正”这一点——每个阶段都要向每个 Agent 发一次提示，会让编排器无法使用，这正是设置此例外的原因。

在流水线允许的情况下，并行启动相互独立的 Agent（例如，第 2 阶段的 Agent 可以同时运行）。

流水线

第 1 阶段：叙事方向

委派给 narrative-director：

• 明确此内容的叙事目的：它服务于故事中的哪个节点？
• 确定涉及的角色、他们的动机，以及这如何融入整体故事线
• 设定情感基调和节奏目标
• 指明任何相关的背景设定依赖项或由此引入的新背景设定
• 输出：包含故事要求的叙事简报

第 2 阶段：世界基础（并行）

并行委派——在等待任何结果之前，同时发出全部三个 Agent 调用：

• world-builder：为与此内容相关的派系、地点和历史创建或更新背景设定条目。对照现有背景设定检查矛盾。为新条目设定正史级别。
• writer：根据角色语音档案撰写角色对白。确保所有台词都少于 120 个字符，使用具名占位符表示变量，并确保内容已做好本地化准备。
• art-director：为此内容中出现的关键角色制定角色视觉设计方向（轮廓、视觉原型、鲜明特征）。为每个关键空间指定环境叙事视觉元素（道具构成、灯光说明、空间布局）。为任何过场动画或脚本序列定义色调搭配和电影化方向。

**阶段关卡：**收集全部三个第 2 阶段的输出，然后在开始第 3 阶段前应用 Decision Points 规则——展示背景设定、对白和视觉方向摘要，并通过 AskUserQuestion 捕获批准；在 collaborative 模式下执行此操作（在 guided 模式下自动推进，除非某项结果为 BLOCKED；在 autonomous 模式下使用 log_decision）。

第 3 阶段：关卡叙事整合

委派给 level-designer：

• 查看叙事简报和背景设定基础
• 设计关卡中的环境叙事元素
• 放置叙事触发器、对话区域和探索发现点
• 确保节奏兼顾玩法与故事

阶段 4：审查与一致性

使用 Agent 启动 narrative-director，并通过 ND-CONSISTENCY （.claude/docs/director-gates/nd-consistency.md）。此阶段会在每种审查 模式下运行——这是此流水线自身的审查，并非可选的 director gate。传入 该 gate 列出的上下文（阶段 2–3 的草稿路径、叙事圣经或语气指南、世界规则、 受影响角色和派系的档案）——此处已列出，因此不要在本会话中读取 gate 文件——并添加：

• 确认叙事节奏与关卡设计相符
• 检查所有谜团是否都有记录在案的“真实答案”

根据结论采取行动：APPROVE → 阶段 5。CONCERNS → 展示列出的 不一致之处，并通过 AskUserQuestion 询问是否修改（重新启动负责每项内容的 Agent）或接受这些问题。REJECT → 不要启动阶段 5；必须先修复矛盾。NOT ASSESSED [missing input] → 指出缺少的输入，然后补充该输入并重新运行 gate，或在报告的一致性审查结果中注明 ND-CONSISTENCY: NOT ASSESSED — [input]；绝不能将其视为 APPROVE （.claude/docs/director-gates.md）。

当 team.size: individual 时， narrative-director 不在活动集合中，因此 不会启动该 gate。写作者会根据相同标准检查草稿，并在输出中明确说明：“ND-CONSISTENCY 未运行——team.size: individual 时 narrative-director 不处于活动状态；写作者已自行检查一致性。”自查结果不等于 gate 的结论，报告不得将其作为 gate 结论呈现。

阶段 5：润色（并行）

并行委派——在等待任何结果之前发出所有 Agent 调用：

• writer：最终自查——确认没有任何行超出对话框限制、所有文本都使用字符串键（而不是原始字符串），占位变量名称保持一致
• localization-lead：验证是否符合国际化要求——检查字符串键命名约定，标出任何包含无法经受翻译的硬编码格式的字符串，确认会扩展的语言有足够的字符数余量（德语／芬兰语通常会增加 30%），确认文本中没有需要按语言区域提供不同版本的文化假设
• world-builder：为所有新增的传说条目敲定正史级别

写入最终文档

你持有所有草稿。列出上表中的最终文档，然后通过 AskUserQuestion 一次性询问：“可以将这 [N] 份叙事文档写入 design/narrative/ 吗？”——获得批准后再写入。production/narrative/[content-slug]/ 下的草稿保留为工作记录。

错误恢复流程

首先，验证产物。 如果返回约定指定了路径，请先确认该路径存在，再将阶段视为完成——指定的产物若未写入磁盘，该阶段即告失败，无论回复读起来多么流畅。 Agent 可能耗费整个阶段，却只返回看似合理的前言，实际什么也没写；这既不属于 BLOCKED，也不属于错误或“无法完成”，因此下面的触发条件永远不会生效。恢复执行时，请指出尚未满足的约定；上下文通常仍然保留。

如果任何已启动的 Agent 返回 BLOCKED、发生错误或无法完成：立即说明情况，不要越过它所阻塞的依赖项继续执行，并且始终生成部分报告。 被跳过的 Agent 所负责的部分应明确标为缺失，不得自行填补内容。完整流程：.claude/docs/error-recovery-protocol.md。

常见阻塞情况：

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

文件写入协议

子代理会将草稿写入你指定的 production/narrative/[content-slug]/ 路径，依据上文“为何这不违反协作协议”中记录的有限例外——该路径由你指定，产物是在 production/、docs/ 或 tests/ 下新建的，且该阶段受 AskUserQuestion 控制。子代理在这些范围内写入时无需逐次征求许可；超出范围则必须询问。唯一的例外是 design/narrative/ 下的最终文档：你持有所有草稿，因此在“编写最终文档”中那次“我可以写……吗？”得到许可后，由你亲自编写。

输出

一份总结报告，涵盖：叙事概要状态、创建或更新的设定条目、撰写的对话台词、关卡叙事整合点、一致性审查结果，以及任何尚未解决的矛盾——包括用户选择不修复的任何本地化问题，并注明字符串键。

结论：COMPLETE — 叙事内容已交付。

如果 ND-CONSISTENCY 的回答为 NOT ASSESSED，且报告（第 4 阶段）中也保留了这一状态，则结论应明确说明这一点——不得只写 COMPLETE：

结论：COMPLETE — consistency NOT ASSESSED ([input]) — 叙事内容已交付；由于缺少 [input]，无法进行一致性审查。

如果因依赖项未解决而导致流程停止（例如，用户未解决设定矛盾或缺失的前置条件）：

结论：BLOCKED — [原因]

后续步骤

• 对叙事文档运行 /design-review，进行一致性验证。
• 对话定稿后，运行 /localize extract，提取需要翻译的新字符串。
• 运行 /dev-story，在引擎中实现对话触发器和叙事事件。