需要多角色分工产出游戏叙事内容（剧情、世界观、关卡叙事）时…

在 Claude Code 的 team skill 体系内，按 review_mode、automation、team.size 三级配置编排叙事团队，分五个阶段产出 narrative brief、lore、对白、视觉方向与关卡叙事整合，并强制约定产物路径与返回契约。

适用场景

解决思路

1. 无参数调用时直接输出用法指引并退出，不 spawn 任何 agent：`/team-narrative [narrative content description]`，描述要做的故事内容/场景/叙事区域（如 `boss encounter cutscene`、`faction intro dialogue`、`tutorial narrative`）；此处不要用 `AskUserQuestion`，直接输出指引。
2. Phase 0 解析配置：`source "${CLAUDE_PROJECT_DIR:-.}/.claude/hooks/yaml-helper.sh"` 后执行 `resolve_config --keys review_mode,automation,team.size`；结果直接采用，`--review` 覆盖 `review_mode`；无输出则使用 `.claude/docs/config-resolution.md` 中的默认值。
3. 按 `review_mode` 设定 gate 深度：`full` 按描述 spawn 全部 director 与 lead gate；`lean` 只保留 PHASE-GATE 类型（CD-PHASE-GATE、TD-PHASE-GATE、PR-PHASE-GATE、AD-PHASE-GATE）；`solo` 完全跳过 director gate，整个 skill 不跑任何 agent gate。
4. 按 `automation` 决定决策点行为：`collaborative` 必须用户批准才能进入下一阶段；`guided` 自动推进除非某阶段 BLOCKED；`autonomous` 端到端运行并用 `log_decision` 记录每阶段结果；`automation_always_ask` 类别（`is_always_ask_category` helper）无论何种模式都始终询问。
5. 按 `team.size` 决定活跃 agent 集：`individual`（默认）只用 `writer`，仅在出现明确 pillar 冲突时调用 `narrative-director`，其他 agent 通过 writer 咨询而不单独 spawn；`small` 用 `narrative-director` + `writer` +（按 review_mode）`localization-lead`、`world-builder`；`studio` 启用全部叙事 agent 并做 per-system writer review。
6. 在 Phase 1 之前用一行宣告活跃集：说明本次实际会 spawn 哪些 agent，以及 pipeline 中列出但本次不会 spawn 的 agent 是通过哪个最近的活跃 core agent 咨询，并提示可通过提升 `team.size`（或 `modes.rigor`）扩大；不要让折叠静默发生。
7. 严格定义 "phase gate"：任何以 `AskUserQuestion` 决策点结束、之后才推进的阶段才算 gate；没有决策点的阶段不算 gate，被限定为 "phase gates only" 的 agent 不为其 spawn。
8. 非活跃集内的 agent 一律路由到最近的活跃 core agent 并附 informational note，而不是单独 spawn；该活跃集限定贯穿整条 pipeline。
9. 用 `Agent` 工具把每个成员 spawn 为 subagent 并指定 `subagent_type`：`narrative-director`（故事弧线、角色设计、叙事愿景）、`writer`（对白、lore 条目、游戏内文本）、`world-builder`（世界规则、势力、历史、地理）、`art-director`（角色视觉画像、环境视觉叙事、过场基调）、`level-designer`（服务叙事的关卡布局、节奏）、`localization-lead`（本地化就绪度）。
10. 给每个 agent 写精简 brief，不要倾倒上下文：共享输入只读一次，把每个 agent 真正需要的那几行内联传入；已经读过的文档绝不要传文件路径（拿到路径的 agent 会把整份文件重读一遍）；只有自己没读过、且仅该 agent 需要的文档才传路径。
11. 每个 agent prompt 末尾都加返回契约："把完整输出写到 `[path]` —— 该命名路径即你在下述有界例外下的写授权，无需另行申请批准。只返回 (1) 写入的路径，(2) ≤5 条决策摘要 bullets，(3) 任何 BLOCKED/CONCERNS 项各一行。不要复述你读过的文档。" 否则 agent 会把读到的所有内容回灌进当前会话。
12. 把 `[path]` 替换成真实路径，本 skill 的目的地是 `design/narrative/`，每个 agent 一个文件：`narrative-director` → `design/narrative/[content-slug]-brief.md`；`world-builder` → `design/narrative/lore/[topic].md`；`writer` → `design/narrative/dialogue/[scene-slug].md`；`art-director` → `design/narrative/[content-slug]-visual-direction.md`。
13. 明确目的地不是自由选择：`design/narrative/` 会被 `/asset-spec`、`/design-review`、`/localize`、`/onboard`、`/project-stage-detect`、`/team-level` 以及 `cd-narrative` director gate 读取；写到别处等于这七处都看不见。给返回契约命名具体目的地是它的前提，只写契约不给目的地会让每次运行各自发明路径。
14. 遵守有界写文件例外（替代逐次询问）：subagent 在三条同时成立时才可不问而写——(1) 路径是你在 prompt 中命名的，用户批准该阶段即批准了目的地；(2) 是 `production/`、`docs/`、`tests/` 下的新产物，绝不是对已有源码或配置的编辑；(3) 产生它的阶段本身由 `AskUserQuestion` 把关。三条之外 agent 必须先问；不要为了"修复"而改成每个 subagent 每阶段都问一次。
15. Phase 1 Narrative Direction：交给 `narrative-director`——定义该内容的叙事目的（服务哪个故事节拍）、涉及角色及其动机与在整体弧线中的位置、设定情绪基调与节奏目标、指明 lore 依赖或本次新增的 lore；产出带故事需求的 narrative brief。
16. Phase 2 World Foundation 并行：在等待任何结果前先同时发出三个 `Agent` 调用——`world-builder` 为相关势力、地点、历史创建或更新 lore 条目，与既有 lore 交叉检查矛盾，为新条目设定 canon level；`writer` 按 voice profile 起草角色对白，确保所有行在 120 字符以内、使用命名占位符、可本地化；`art-director` 定义关键角色的视觉设计方向（剪影、视觉原型、辨识特征），为每个关键空间指定环境视觉叙事元素（道具构成、灯光说明、空间排布），并为过场或脚本序列定义色调与镜头方向。
17. Phase 2 phase gate：收齐三份 Phase 2 输出后，在进入 Phase 3 前应用决策点规则——呈现 lore、对白、视觉方向摘要，并在 `collaborative` 模式下用 `AskUserQuestion` 取得批准（`guided` 除非结果 BLOCKED 否则自动推进；`autonomous` 用 `log_decision`）。
18. Phase 3 Level Narrative Integration：交给 `level-designer`——审阅 narrative brief 与 lore 基础、设计关卡中的环境叙事元素、放置叙事触发器/对白区域/发现点、确保节奏同时服务玩法与故事。
19. Phase 4 Review and Consistency：交给 `narrative-director`——对照角色 voice profile 审查所有对白、核对新旧 lore 条目一致性、确认叙事节奏与关卡设计对齐、检查每个谜团都有记录在案的 "true answer"。
20. Phase 5 Polish 并行：`writer` 终审自查（没有任何行超出对白框约束、所有文本用 string key 而非裸字符串、占位符变量名一致）；`localization-lead` 校验 i18n 合规（string key 命名规范、标记在翻译中无法存活的硬编码格式化字符串、核对会膨胀语言如德语/芬兰语通常 +30% 的字符余量、确认文本中没有需要 locale 特定变体的文化假设）；`world-builder` 敲定所有新 lore 条目的 canon level。
21. 错误恢复先验证产物：若返回契约给出了路径，在把该阶段当作完成之前先检查路径是否存在——命名产物不在磁盘上就是失败的阶段，无论响应读起来多流畅；以指出未满足契约为由 resume 该 agent（上下文通常还在）。
22. 任何被 spawn 的 agent 返回 BLOCKED、报错或无法完成时：立刻暴露，不要越过它阻塞的依赖继续推进，并且始终产出部分报告；完整流程见 `.claude/docs/error-recovery-protocol.md`。
23. 常见 blocker 的处理：输入文件缺失（找不到 story、缺 GDD）→ 转向创建它的 skill；ADR 状态为 Proposed → 不要实现，先跑 `/architecture-decision`；范围过大 → 用 `/create-stories` 拆成两个 story；ADR 与 story 指令冲突 → 暴露冲突，不要猜。
24. File Write Protocol：所有文件写入（叙事文档、对白文件、lore 条目）都委托给通过 `Agent` spawn 的 sub-agent，遵循上述有界例外；orchestrator 本身不直接写文件。
25. 输出总结报告：narrative brief 状态、创建/更新的 lore 条目、写出的对白行数、关卡叙事整合点、一致性审查结果、任何未解决的矛盾。交付完成时 Verdict: `COMPLETE`；因依赖未解决（如用户未解决的 lore 矛盾或缺失前置条件）而停下时 Verdict: `BLOCKED` — [reason]。
26. Next Steps：对叙事文档跑 `/design-review` 做一致性校验；对白定稿后跑 `/localize extract` 提取新字符串用于翻译；跑 `/dev-story` 在引擎内实现对白触发器与叙事事件。

适用边界 · 注意事项

• 不适用于非叙事类内容（纯系统设计、技术文档、无剧情/世界观诉求的改动）。
• 在默认 `team.size: individual` 下不要期待多 agent fan-out：pipeline 虽然列出六个 agent、五个阶段，实际只跑 `writer` 一人，其余按路由规则咨询。
• 依赖 `.claude/hooks`、`Agent`/`AskUserQuestion` 工具与 `design/narrative/` 下游消费链（`/asset-spec`、`/design-review`、`/localize` 等）的 Claude Code 项目之外，这套编排与写文件例外不成立。