Claude Code Game Studios/team-narrative技能规范深度解析五阶段叙事管线、并行编排与一致性保障【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios/team-narrative是 Claude Code Game StudiosCCGS技能体系中负责统筹叙事团队的部门级技能team 类技能。本文以其行为测试规范 team-narrative.md 为绝对主线完整拆解其五阶段叙事管线、每个阶段的人工确认机制、五个覆盖关键故障模式的测试用例以及并行 Agent 编排与May I write写入协议背后的设计意图。读完本文你将掌握如何把 narrative-director、world-builder、writer、level-designer、localization-lead 五个叙事域 Agent 组织成一条既高效又防失控的内容生产流水线并理解 CCGS 用行为测试规范固化技能行为的工程方法。一、技能定位team 类技能中的叙事编排者在 CCGS 的 catalog.yaml 中team-narrative被登记为category: team、priority: medium其权威规范路径即 CCGS Skill Testing Framework/skills/team/team-narrative.md。team 类别共包含 team-combat、team-narrative、team-audio、team-level、team-ui、team-qa、team-release、team-polish、team-live-ops 九个部门级技能它们共同的特点是编排多个专业 Agent 完成一个部门的产出。根据 quality-rubric.md 中team类别的五项通过指标T1–T5这类技能必须满足指标通过标准T1 — 具名 Agent 列表技能明确声明它调用哪些 Agent 以及调用顺序T2 — 独立任务并行输入互不依赖的 Agent 必须在同一条消息中以多个 Task 调用并行启动T3 — BLOCKED 即时上报任何被调用 Agent 返回 BLOCKED 或失败时技能必须立即上报并暂停依赖它的工作绝不静默跳过T4 — 汇集全部裁决后再推进依赖阶段必须等待所有并行 Agent 完成后才能继续T5 — 无参数报错缺少必需参数如功能名时技能输出用法提示并停止不启动任何 Agent/team-narrative的规范正是围绕这五项指标逐一落实的它具名五个 Agent、在 Phase 2 和 Phase 5 强制并行、在任何 Agent BLOCKED 时立即上报、在每个阶段转换处用AskUserQuestion汇集人工裁决、在无参数时只输出用法指引。二、五阶段叙事管线全貌规范文档在 Skill Summary 中给出了管线的总体骨架可概括为一条单向依赖链Phase 1 叙事方向narrative-director ↓ AskUserQuestion 审批 Phase 2 世界基础 对白起草world-builder 与 writer 并行 ↓ AskUserQuestion 审批 Phase 3 关卡叙事整合level-designer ↓ AskUserQuestion 审批 Phase 4 一致性复审narrative-director 再次上场 ↓ AskUserQuestion 审批 Phase 5 打磨 本地化合规writer、localization-lead、world-builder 并行 ↓ 叙事总结报告 由子 Agent 按 May I write? 协议交付文档Phase 1叙事方向narrative-director管线首先调用 narrative-director。根据 narrative-director.md 的 Agent 规范该 Agent 的领域为故事架构、角色设计方向、世界构建监督、ND-CONSISTENCY 门禁、对白质量复审它不拥有美术风格、技术系统、制作排期与玩法规则。其输出是一份叙事简报narrative brief必须明确界定故事节拍story beat涉及的角色情感基调emotional tone世界观依赖lore dependencies从 Agent 规范的测试用例可以看出narrative-director 输出的裁决采用ND-CONSISTENCY: CONSISTENT / INCONSISTENT固定词汇且裁决必须引用具体已核实事实如200 年时间线Great Collapse 事件而非泛泛的与世界观不符。这意味着 Phase 1 的叙事简报本身就带有可被后续阶段核验的事实锚点。Phase 2世界基础与对白起草并行Phase 2 是管线的第一个并行点world-builder 与 writer 在同时发出 Task 调用后并行执行而非串行等待。规范明确断言Phase 2 显式地并行派生 world-builder 和 writerStatic Assertions 第 12 条且断言层要求world-builder 和 writer 的 Task 调用在 Phase 2 中同时发出而非顺序执行。两个 Agent 的职责边界由各自的规范文件锁定world-builder.md负责世界观传说架构——派系及其文化/政府/动机、世界历史、地理与生态、宇宙论与形而上学、世界规则以及跨世界文档的内部一致性强制。它不写 NPC 对白对白写入请求会被重定向给 writer。writer.md负责游戏内书面内容——NPC 对白含分支树、图鉴条目、物品与能力描述、环境文本、任务文本、教程文本。它不设计世界历史与世界规则遇到传说冲突时向 narrative-director 上报而不是自行裁决。从 writer 的 Agent 规范看其产出必须依据角色声线档案character voice profiles写作Case 5 要求逐条遵守声线指南短句、行话、I will 不用缩写等这解释了为什么 Phase 2 的输入 fixture 中要求存在design/narrative/characters/下的声线档案——没有声线档案writer 的产出质量无法被保证。Phase 3关卡叙事整合level-designerPhase 3 在 Phase 2 审批通过后启动 level-designer产出环境叙事布局environmental storytelling layout、触发器摆放trigger placement与节奏计划pacing plan。根据 level-designer.md 的规范其领域为关卡布局、遭遇设计、节奏与张力弧线、环境叙事、空间谜题其裁决词汇为APPROVED / REVISION NEEDED。该 Agent 不拥有对白、美术风格与敌人 AI 行为逻辑环境叙事是其将叙事落地到空间层面的关键环节。Phase 4一致性复审narrative-director 重新上场Phase 4重新派生 narrative-director断言明确要求narrative-director 在 Phase 4 被重新派生用于一致性复审执行三件事对照声线档案复审全部对白、核验世界观一致性、确认节奏随后批准或标记问题。这是编审分离的体现——写作者与审查者角色分离narrative-director 既在 Phase 1 定方向又在 Phase 4 做质检。Phase 5打磨与本地化合规并行Phase 5 是第二个并行点也是并行度最高的阶段writer、localization-lead、world-builder 三个 Agent 同时启动断言要求三个 Task 调用同时发出。三者分工writer执行最终自审包括所有对白行不超过 120 字符使用字符串键而非原始字符串等检查Coverage Notes 中明确提及localization-lead依据 localization-lead.md 校验 i18n 合规——该 Agent 拥有 i18n 架构、字符串抽取流程、locale 测试方法论、翻译管线设计与 locale 特定格式规则复数、RTL、日期/数字格式但它不写游戏叙事内容、不写 i18n 调用代码、不亲自翻译world-builder最终确定正典层级canon levels收口世界观事实。管线结束时编排者产出叙事总结报告并让子 Agent 以May I write to [path]?协议交付叙事文档——编排者自身绝不直接写文件详见第五节。最终裁决只有两种取值全部阶段成功为COMPLETE存在未解决的依赖问题则为BLOCKED。三、五个测试用例从顺风顺水到全线崩坏的边界推演规范的核心价值在于五个测试用例Test Cases它们构成对该技能行为的可执行验收清单。每个用例都定义了 Fixture前置场景、Input、Expected behavior预期行为链与 Assertions断言。下文完整展开。Case 1Happy Path——五阶段全通叙事文档交付Fixture目标功能已有游戏概念与 GDD如design/gdd/faction-intro.md角色声线档案已存在于design/narrative/characters/已有传说词条可供交叉引用如design/narrative/lore/新旧内容之间不存在传说矛盾。Input/team-narrative faction introduction cutscene for the Ironveil faction预期行为链11 步Phase 1 派生 narrative-director产出定义故事节拍、涉及角色、情感基调与传说依赖的叙事简报AskUserQuestion呈现叙事简报用户批准后才进入 Phase 2Phase 2 并行派生 world-builder 与 writer前者为 Ironveil 派系产出传说词条后者依据角色声线档案起草对白AskUserQuestion呈现世界基础与对白草稿批准后进入 Phase 3Phase 3 派生 level-designer产出环境叙事布局、触发器摆放与节奏计划AskUserQuestion呈现关卡叙事计划批准后进入 Phase 4Phase 4 narrative-director 对照声线档案复审全部对白、核验传说一致性、确认节奏批准或标记问题AskUserQuestion呈现复审结果批准后进入 Phase 5Phase 5 并行派生 writer、localization-lead、world-builderwriter 最终自审localization-lead 校验 i18n 合规world-builder 敲定正典层级呈现最终总结报告子 Agent 在写入前询问May I write the narrative document to [path]?裁决为COMPLETE。关键断言Phase 1 必须先于任何其他 Agent 派生 narrative-directorAskUserQuestion出现在 Phase 1 输出之后、Phase 2 启动之前Phase 2 的 world-builder 与 writer 必须同时发出 Task 调用Phase 2 审批通过前不得启动 level-designerPhase 4 重新派生 narrative-directorPhase 5 三个 Agent 同时启动总结报告必须包含叙事简报状态、创建/更新的传说词条、已写对白行数、关卡叙事整合点、一致性复审结果编排者不得直接写任何文件交付后裁决为COMPLETE。Case 2发现传说矛盾——world-builder 在 writer 之前拦截冲突Fixture已有词条design/narrative/lore/ironveil-history.md记载 Ironveil 派系成立于 200 年前Phase 1 的叙事简报却称其成立于 50 年前writer 已在 Phase 2 与 world-builder 并行派生。Input/team-narrative ironveil faction introduction cutscene预期行为链Phase 1–2 正常开始Phase 2 中 world-builder 发现叙事简报与既有传说的事实矛盾建国时间冲突world-builder 返回BLOCKED理由为Lore contradiction found — founding date conflicts withdesign/narrative/lore/ironveil-history.md编排者立即上报矛盾world-builder: BLOCKED — Lore contradiction: founding date in narrative brief (50 years ago) conflicts with existing canon (200 years ago inironveil-history.md)编排者评估依赖writer 的对白依赖正典传说——矛盾未解决前 writer 的草稿无法定稿AskUserQuestion呈现三个选项修订叙事简报以匹配既有正典200 年前更新既有词条以反映新正典50 年前停在这里先到传说文档中解决矛盾writer 的输出被保留并标记为待正典解决——工作不被丢弃在矛盾解决或用户明确选择跳过之前编排者不进入 Phase 3。关键断言矛盾必须在 Phase 3 开始前上报编排者不得静默二选一AskUserQuestion至少提供三个选项且包含先停下解决writer 草稿保留在部分报告中而非丢弃用户未解决矛盾前不得启动 Phase 3若用户选择停下解决裁决为BLOCKED而非COMPLETE。这与 world-builder.md 的 Case 3 行为完全同构Agent 规范要求 world-builder 在遇到矛盾时不按请求写入新词条、同时陈述两个版本、提出解决选项、必要时上报 narrative-director——技能的 BLOCKED 上报机制正是对 Agent 规范中不得静默覆盖既有传说原则的管线级落实。Case 3无参数调用——只给用法不派任何 AgentFixture任意项目状态。Input/team-narrative不带参数预期行为技能检测到未提供参数输出用法指引例如Usage:/team-narrative [narrative content description]— describe the story content, scene, or narrative area to work on (e.g.,boss encounter cutscene,faction intro dialogue,tutorial narrative)然后不启动任何 Agent 直接退出。关键断言无参数时不派生任何 Agent用法消息包含正确调用格式与参数示例技能不尝试从项目文件中猜测或推断叙事主题不使用AskUserQuestion——输出是直接指引。这对应 quality-rubric 的 T5 指标缺少必需参数时输出用法提示并停止。Case 4本地化合规——localization-lead 标记不可翻译字符串FixturePhase 1–4 全部成功Phase 5 开始writer 与 world-builder 无问题完成localization-lead 发现某对白行使用了硬编码的格式化日期字符串如On March 12th, Year 3该字符串无法在不使用 locale 感知格式化器的情况下经受各 locale 的翻译。Input/team-narrative ironveil faction introduction cutscenePhase 5 场景预期行为链Phase 5 并行派生 writer、localization-lead、world-builderlocalization-lead 完成复审并标记String keydialogue.ironveil.intro.003contains a hardcoded date format (March 12th, Year 3) that will not localize correctly — requires a locale-aware date placeholder编排者在总结报告中上报该本地化阻塞项该本地化问题在最终报告中被标注为BLOCKING而非咨询性建议AskUserQuestion呈现选项现在修复该字符串writer 修订该行标注缺口并按现状交付叙事文档停下来先解决再定稿若用户选择带标注继续裁决为COMPLETE并记录本地化债务若用户选择停下裁决为BLOCKED。关键断言localization-lead 在 Phase 5 与 writer、world-builder 同时派生硬编码日期格式被识别为本地化阻塞项而非静默放过问题报告中包含具体字符串键与原因AskUserQuestion提供现在修复 vs 标记后继续的选项若用户不带修复继续裁决需记录本地化债务技能不在未经用户批准的情况下自动改写问题行。该用例与 localization-lead.md 的领域定义精确对齐该 Agent 拥有locale 特定格式化规则复数、RTL、日期/数字格式其 Case 3 明确指出俄罗斯语的复数形态缺失CLDR 三种复数类别属于本地化质量缺陷而非风格小问题。本用例将同一原则延伸到了日期格式硬编码日期无法存活于 locale 感知翻译必须使用占位符。同时Coverage Notes 特别区分了阻塞性本地化问题硬编码格式与咨询性问题如德语/芬兰语文本 30% 膨胀警告——咨询性问题遵循同样模式但不改变裁决。Case 5writer 被阻塞——缺少角色声线档案FixturePhase 1 narrative-director 产出的叙事简报引用两个角色Commander Varek 与 Advisor Selenedesign/narrative/characters/下两者都无声线档案Phase 2 开始world-builder 正常推进。Input/team-narrative ironveil surrender negotiation scene预期行为链Phase 1 完成叙事简报列出 Commander Varek 与 Advisor Selene 两个角色Phase 2 中 writer 与 world-builder 并行派生writer 返回BLOCKEDCannot produce dialogue — no voice profiles found for Commander Varek or Advisor Selene indesign/narrative/characters/. Voice profiles required to match character tone and speech patterns.编排者立即上报writer: BLOCKED — Missing prerequisite: character voice profiles for Commander Varek and Advisor Seleneworld-builder 的输出被保留产出包含传说词条的部分报告AskUserQuestion呈现选项先创建声线档案转给 narrative-director 或设计工作流内联提供最小声线指示并以该上下文重试 writer停下先创建声线档案再继续没有 writer 输出时编排者不进入 Phase 3。关键断言writer 的阻塞在 Phase 3 开始前上报world-builder 已完成的传说输出保留在部分报告中缺失前提声线档案被具体点名角色名 预期文件路径AskUserQuestion至少提供一个解决缺失前提的选项编排者不伪造声线档案或凭空发明角色声音writer 处于 BLOCKED 且无用户明确授权时Phase 3 不启动。该用例是依赖分析的样板writer 的对白产出依赖声线档案这一前提缺前提时宁可阻塞也不降质产出。这与 writer.md 的 Case 4物品描述引用未定义的Berserker state机制时拒绝写出可能误导玩家的描述一脉相承——不写会制造错误预期的内容是 writer 的协议底线。四、静态断言结构的可机检性除行为用例外规范还包含一组静态断言Structural Assertions用于在不运行技能的情况下检查技能文件本身的形态是否符合约定具有必需的前置元数据字段name、description、argument-hint、user-invocable、allowed-tools至少包含 2 个阶段标题Phase Headings包含裁决关键词COMPLETE、BLOCKED包含 File Write Protocol 章节文件写入委托给子 Agent——编排者不直接写文件子 Agent 在任何写入前强制May I write to [path]?结尾包含下一步交接引用/design-review、/localize extract、/dev-story包含 Error Recovery Protocol错误恢复协议章节AskUserQuestion在阶段转换处、继续之前使用Phase 2 显式并行派生 world-builder 与 writerPhase 5 显式并行派生 writer、localization-lead 与 world-builder。静态断言与行为断言双轨并行构成了 CCGS 测试框架结构可机检 行为可推演的验收体系这也是 CCGS Skill Testing Framework/CLAUDE.md 中先读 catalog.yaml 拿 spec 路径 → 读技能 → 读 spec → 逐用例评估断言工作流的基础。五、协议合规不可破坏的十条红线Protocol Compliance 章节列出了技能每次运行都必须满足的协议约束每个阶段输出之后、下一阶段启动之前都使用AskUserQuestion并行派生Phase 2world-builder writer与 Phase 5writer localization-lead world-builder在等待结果前就发出全部 Task 调用编排者不直接写任何文件——所有写入委托给子 Agent每个子 Agent 在任何写入前执行May I write to [path]?协议任何 Agent 的 BLOCKED 状态立即上报——绝不静默跳过当部分 Agent 完成、部分阻塞时总是产出部分报告裁决严格为COMPLETE或BLOCKED不使用其他值Next Steps 交接引用/design-review、/localize extract与/dev-story。其中编排者不写文件、写入全由子 Agent 按 May I write 协议执行是 CCGS 全框架的通用写入守则quality-rubric 的team类之外pipeline类的 P3 指标也要求每个产物创建前询问 May I write而非一次性批量批准。而部分报告机制保证了故障的代价可控Case 2 中 world-builder 阻塞时 writer 草稿保留、Case 5 中 writer 阻塞时 world-builder 的传说词条保留——已完成的劳动永不因他人失败而丢失。六、覆盖说明哪些场景不单独测试为什么Coverage Notes 明确了本规范测试策略的取舍边界是理解测试设计意图的关键Phase 3 与 Phase 4 的正常路径由 Case 1 隐式验证不单独设用例——它们的失败模式遵循标准的 Error Recovery Protocol错误恢复协议中的以更窄范围重试Retry with narrower scope与跳过该 AgentSkip this agent两条解决路径不单独测试——它们遵循与 Case 2、Case 5 相同的AskUserQuestion 部分报告模式本地化问题区分咨询性如德语/芬兰语 30% 膨胀警告与阻塞性硬编码格式Case 4 只覆盖阻塞性咨询性场景遵循同样模式但不改变裁决writer 在 Phase 5 的所有对白行 ≤ 120 字符使用字符串键而非原始字符串检查由 Case 4 的本地化合规场景隐式覆盖。这种显式测关键路径、隐式覆盖公共模式的策略避免了为每个分支重复造轮子同时确保最危险的故障模式传说矛盾、缺前提、本地化阻塞都有独立用例钉死。七、在 CCGS 框架中运行与测试该技能从源码结构与框架约定可以推断/team-narrative的行为测试可通过 CCGS 的 skill 测试工作流执行。根据 CCGS Skill Testing Framework/CLAUDE.md标准流程为读取 catalog.yaml获取该技能的spec:路径即CCGS Skill Testing Framework/skills/team/team-narrative.md与category:team读取技能本体位于.claude/skills/team-narrative/SKILL.md与本文档对应的规范文件逐用例评估断言评估结果可写入results/并回填catalog.yaml的last_spec/last_spec_result字段。框架的 CLAUDE.md 特别提醒本目录下的规范描述的是当前实际行为而非理想行为规范由阅读技能写成因此可能固化了技能自身的缺陷当技能实际表现异常时应先修正技能本体再更新规范以匹配修正后的行为。规范失败应视为需要调查而非技能绝对错误。对技能改进框架提供/skill-improve [name]闭环测试 → 诊断 → 提出修复 → 重写 → 重测 → 保留或回退。这使team-narrative这类技能可以持续演进而规范文件始终是对当前行为的可执行快照。八、总结从规范看部门级技能编排的设计哲学/team-narrative规范浓缩了 CCGS 部门级技能编排的完整方法论方向先行叙事方向Phase 1必须先于一切内容生产且每阶段输出都需人工确认——AskUserQuestion不是可选项而是协议红线并行加速依赖独立的阶段Phase 2 双 Agent、Phase 5 三 Agent强制并行把流水线节拍压到最短编审分离narrative-director 既立方向又做终审Phase 1 与 Phase 4写作者与审查者角色分离杜绝自审盲区故障显性化任何 BLOCKED 立即上报、绝不静默跳过未解决的依赖传说矛盾、缺声线档案、本地化阻塞永远以部分报告 人工裁决收尾且已完成的工作永不丢弃写入受控编排者不碰文件系统所有写入由子 Agent 逐次执行May I write?协议裁决二分最终状态只有COMPLETE与BLOCKED配合静态断言与行为断言使技能行为可测试、可回归、可改进。对于希望在自己的多 Agent 工作流中复刻这套模式的技术团队本规范与其配套的 narrative-director.md、world-builder.md、writer.md、level-designer.md、localization-lead.md 五份 Agent 规范构成了一套可直接对照落地的参考实现Agent 领域边界、裁决词汇、阻塞上报格式、写入协议一应俱全——这正是一个可测试、可编排、可交接的游戏叙事生产流水线应有的形态。【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Claude Code Game Studios `/team-narrative` 技能规范深度解析：五阶段叙事管线、并行编排与一致性保障
Claude Code Game Studios/team-narrative技能规范深度解析五阶段叙事管线、并行编排与一致性保障【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios/team-narrative是 Claude Code Game StudiosCCGS技能体系中负责统筹叙事团队的部门级技能team 类技能。本文以其行为测试规范 team-narrative.md 为绝对主线完整拆解其五阶段叙事管线、每个阶段的人工确认机制、五个覆盖关键故障模式的测试用例以及并行 Agent 编排与May I write写入协议背后的设计意图。读完本文你将掌握如何把 narrative-director、world-builder、writer、level-designer、localization-lead 五个叙事域 Agent 组织成一条既高效又防失控的内容生产流水线并理解 CCGS 用行为测试规范固化技能行为的工程方法。一、技能定位team 类技能中的叙事编排者在 CCGS 的 catalog.yaml 中team-narrative被登记为category: team、priority: medium其权威规范路径即 CCGS Skill Testing Framework/skills/team/team-narrative.md。team 类别共包含 team-combat、team-narrative、team-audio、team-level、team-ui、team-qa、team-release、team-polish、team-live-ops 九个部门级技能它们共同的特点是编排多个专业 Agent 完成一个部门的产出。根据 quality-rubric.md 中team类别的五项通过指标T1–T5这类技能必须满足指标通过标准T1 — 具名 Agent 列表技能明确声明它调用哪些 Agent 以及调用顺序T2 — 独立任务并行输入互不依赖的 Agent 必须在同一条消息中以多个 Task 调用并行启动T3 — BLOCKED 即时上报任何被调用 Agent 返回 BLOCKED 或失败时技能必须立即上报并暂停依赖它的工作绝不静默跳过T4 — 汇集全部裁决后再推进依赖阶段必须等待所有并行 Agent 完成后才能继续T5 — 无参数报错缺少必需参数如功能名时技能输出用法提示并停止不启动任何 Agent/team-narrative的规范正是围绕这五项指标逐一落实的它具名五个 Agent、在 Phase 2 和 Phase 5 强制并行、在任何 Agent BLOCKED 时立即上报、在每个阶段转换处用AskUserQuestion汇集人工裁决、在无参数时只输出用法指引。二、五阶段叙事管线全貌规范文档在 Skill Summary 中给出了管线的总体骨架可概括为一条单向依赖链Phase 1 叙事方向narrative-director ↓ AskUserQuestion 审批 Phase 2 世界基础 对白起草world-builder 与 writer 并行 ↓ AskUserQuestion 审批 Phase 3 关卡叙事整合level-designer ↓ AskUserQuestion 审批 Phase 4 一致性复审narrative-director 再次上场 ↓ AskUserQuestion 审批 Phase 5 打磨 本地化合规writer、localization-lead、world-builder 并行 ↓ 叙事总结报告 由子 Agent 按 May I write? 协议交付文档Phase 1叙事方向narrative-director管线首先调用 narrative-director。根据 narrative-director.md 的 Agent 规范该 Agent 的领域为故事架构、角色设计方向、世界构建监督、ND-CONSISTENCY 门禁、对白质量复审它不拥有美术风格、技术系统、制作排期与玩法规则。其输出是一份叙事简报narrative brief必须明确界定故事节拍story beat涉及的角色情感基调emotional tone世界观依赖lore dependencies从 Agent 规范的测试用例可以看出narrative-director 输出的裁决采用ND-CONSISTENCY: CONSISTENT / INCONSISTENT固定词汇且裁决必须引用具体已核实事实如200 年时间线Great Collapse 事件而非泛泛的与世界观不符。这意味着 Phase 1 的叙事简报本身就带有可被后续阶段核验的事实锚点。Phase 2世界基础与对白起草并行Phase 2 是管线的第一个并行点world-builder 与 writer 在同时发出 Task 调用后并行执行而非串行等待。规范明确断言Phase 2 显式地并行派生 world-builder 和 writerStatic Assertions 第 12 条且断言层要求world-builder 和 writer 的 Task 调用在 Phase 2 中同时发出而非顺序执行。两个 Agent 的职责边界由各自的规范文件锁定world-builder.md负责世界观传说架构——派系及其文化/政府/动机、世界历史、地理与生态、宇宙论与形而上学、世界规则以及跨世界文档的内部一致性强制。它不写 NPC 对白对白写入请求会被重定向给 writer。writer.md负责游戏内书面内容——NPC 对白含分支树、图鉴条目、物品与能力描述、环境文本、任务文本、教程文本。它不设计世界历史与世界规则遇到传说冲突时向 narrative-director 上报而不是自行裁决。从 writer 的 Agent 规范看其产出必须依据角色声线档案character voice profiles写作Case 5 要求逐条遵守声线指南短句、行话、I will 不用缩写等这解释了为什么 Phase 2 的输入 fixture 中要求存在design/narrative/characters/下的声线档案——没有声线档案writer 的产出质量无法被保证。Phase 3关卡叙事整合level-designerPhase 3 在 Phase 2 审批通过后启动 level-designer产出环境叙事布局environmental storytelling layout、触发器摆放trigger placement与节奏计划pacing plan。根据 level-designer.md 的规范其领域为关卡布局、遭遇设计、节奏与张力弧线、环境叙事、空间谜题其裁决词汇为APPROVED / REVISION NEEDED。该 Agent 不拥有对白、美术风格与敌人 AI 行为逻辑环境叙事是其将叙事落地到空间层面的关键环节。Phase 4一致性复审narrative-director 重新上场Phase 4重新派生 narrative-director断言明确要求narrative-director 在 Phase 4 被重新派生用于一致性复审执行三件事对照声线档案复审全部对白、核验世界观一致性、确认节奏随后批准或标记问题。这是编审分离的体现——写作者与审查者角色分离narrative-director 既在 Phase 1 定方向又在 Phase 4 做质检。Phase 5打磨与本地化合规并行Phase 5 是第二个并行点也是并行度最高的阶段writer、localization-lead、world-builder 三个 Agent 同时启动断言要求三个 Task 调用同时发出。三者分工writer执行最终自审包括所有对白行不超过 120 字符使用字符串键而非原始字符串等检查Coverage Notes 中明确提及localization-lead依据 localization-lead.md 校验 i18n 合规——该 Agent 拥有 i18n 架构、字符串抽取流程、locale 测试方法论、翻译管线设计与 locale 特定格式规则复数、RTL、日期/数字格式但它不写游戏叙事内容、不写 i18n 调用代码、不亲自翻译world-builder最终确定正典层级canon levels收口世界观事实。管线结束时编排者产出叙事总结报告并让子 Agent 以May I write to [path]?协议交付叙事文档——编排者自身绝不直接写文件详见第五节。最终裁决只有两种取值全部阶段成功为COMPLETE存在未解决的依赖问题则为BLOCKED。三、五个测试用例从顺风顺水到全线崩坏的边界推演规范的核心价值在于五个测试用例Test Cases它们构成对该技能行为的可执行验收清单。每个用例都定义了 Fixture前置场景、Input、Expected behavior预期行为链与 Assertions断言。下文完整展开。Case 1Happy Path——五阶段全通叙事文档交付Fixture目标功能已有游戏概念与 GDD如design/gdd/faction-intro.md角色声线档案已存在于design/narrative/characters/已有传说词条可供交叉引用如design/narrative/lore/新旧内容之间不存在传说矛盾。Input/team-narrative faction introduction cutscene for the Ironveil faction预期行为链11 步Phase 1 派生 narrative-director产出定义故事节拍、涉及角色、情感基调与传说依赖的叙事简报AskUserQuestion呈现叙事简报用户批准后才进入 Phase 2Phase 2 并行派生 world-builder 与 writer前者为 Ironveil 派系产出传说词条后者依据角色声线档案起草对白AskUserQuestion呈现世界基础与对白草稿批准后进入 Phase 3Phase 3 派生 level-designer产出环境叙事布局、触发器摆放与节奏计划AskUserQuestion呈现关卡叙事计划批准后进入 Phase 4Phase 4 narrative-director 对照声线档案复审全部对白、核验传说一致性、确认节奏批准或标记问题AskUserQuestion呈现复审结果批准后进入 Phase 5Phase 5 并行派生 writer、localization-lead、world-builderwriter 最终自审localization-lead 校验 i18n 合规world-builder 敲定正典层级呈现最终总结报告子 Agent 在写入前询问May I write the narrative document to [path]?裁决为COMPLETE。关键断言Phase 1 必须先于任何其他 Agent 派生 narrative-directorAskUserQuestion出现在 Phase 1 输出之后、Phase 2 启动之前Phase 2 的 world-builder 与 writer 必须同时发出 Task 调用Phase 2 审批通过前不得启动 level-designerPhase 4 重新派生 narrative-directorPhase 5 三个 Agent 同时启动总结报告必须包含叙事简报状态、创建/更新的传说词条、已写对白行数、关卡叙事整合点、一致性复审结果编排者不得直接写任何文件交付后裁决为COMPLETE。Case 2发现传说矛盾——world-builder 在 writer 之前拦截冲突Fixture已有词条design/narrative/lore/ironveil-history.md记载 Ironveil 派系成立于 200 年前Phase 1 的叙事简报却称其成立于 50 年前writer 已在 Phase 2 与 world-builder 并行派生。Input/team-narrative ironveil faction introduction cutscene预期行为链Phase 1–2 正常开始Phase 2 中 world-builder 发现叙事简报与既有传说的事实矛盾建国时间冲突world-builder 返回BLOCKED理由为Lore contradiction found — founding date conflicts withdesign/narrative/lore/ironveil-history.md编排者立即上报矛盾world-builder: BLOCKED — Lore contradiction: founding date in narrative brief (50 years ago) conflicts with existing canon (200 years ago inironveil-history.md)编排者评估依赖writer 的对白依赖正典传说——矛盾未解决前 writer 的草稿无法定稿AskUserQuestion呈现三个选项修订叙事简报以匹配既有正典200 年前更新既有词条以反映新正典50 年前停在这里先到传说文档中解决矛盾writer 的输出被保留并标记为待正典解决——工作不被丢弃在矛盾解决或用户明确选择跳过之前编排者不进入 Phase 3。关键断言矛盾必须在 Phase 3 开始前上报编排者不得静默二选一AskUserQuestion至少提供三个选项且包含先停下解决writer 草稿保留在部分报告中而非丢弃用户未解决矛盾前不得启动 Phase 3若用户选择停下解决裁决为BLOCKED而非COMPLETE。这与 world-builder.md 的 Case 3 行为完全同构Agent 规范要求 world-builder 在遇到矛盾时不按请求写入新词条、同时陈述两个版本、提出解决选项、必要时上报 narrative-director——技能的 BLOCKED 上报机制正是对 Agent 规范中不得静默覆盖既有传说原则的管线级落实。Case 3无参数调用——只给用法不派任何 AgentFixture任意项目状态。Input/team-narrative不带参数预期行为技能检测到未提供参数输出用法指引例如Usage:/team-narrative [narrative content description]— describe the story content, scene, or narrative area to work on (e.g.,boss encounter cutscene,faction intro dialogue,tutorial narrative)然后不启动任何 Agent 直接退出。关键断言无参数时不派生任何 Agent用法消息包含正确调用格式与参数示例技能不尝试从项目文件中猜测或推断叙事主题不使用AskUserQuestion——输出是直接指引。这对应 quality-rubric 的 T5 指标缺少必需参数时输出用法提示并停止。Case 4本地化合规——localization-lead 标记不可翻译字符串FixturePhase 1–4 全部成功Phase 5 开始writer 与 world-builder 无问题完成localization-lead 发现某对白行使用了硬编码的格式化日期字符串如On March 12th, Year 3该字符串无法在不使用 locale 感知格式化器的情况下经受各 locale 的翻译。Input/team-narrative ironveil faction introduction cutscenePhase 5 场景预期行为链Phase 5 并行派生 writer、localization-lead、world-builderlocalization-lead 完成复审并标记String keydialogue.ironveil.intro.003contains a hardcoded date format (March 12th, Year 3) that will not localize correctly — requires a locale-aware date placeholder编排者在总结报告中上报该本地化阻塞项该本地化问题在最终报告中被标注为BLOCKING而非咨询性建议AskUserQuestion呈现选项现在修复该字符串writer 修订该行标注缺口并按现状交付叙事文档停下来先解决再定稿若用户选择带标注继续裁决为COMPLETE并记录本地化债务若用户选择停下裁决为BLOCKED。关键断言localization-lead 在 Phase 5 与 writer、world-builder 同时派生硬编码日期格式被识别为本地化阻塞项而非静默放过问题报告中包含具体字符串键与原因AskUserQuestion提供现在修复 vs 标记后继续的选项若用户不带修复继续裁决需记录本地化债务技能不在未经用户批准的情况下自动改写问题行。该用例与 localization-lead.md 的领域定义精确对齐该 Agent 拥有locale 特定格式化规则复数、RTL、日期/数字格式其 Case 3 明确指出俄罗斯语的复数形态缺失CLDR 三种复数类别属于本地化质量缺陷而非风格小问题。本用例将同一原则延伸到了日期格式硬编码日期无法存活于 locale 感知翻译必须使用占位符。同时Coverage Notes 特别区分了阻塞性本地化问题硬编码格式与咨询性问题如德语/芬兰语文本 30% 膨胀警告——咨询性问题遵循同样模式但不改变裁决。Case 5writer 被阻塞——缺少角色声线档案FixturePhase 1 narrative-director 产出的叙事简报引用两个角色Commander Varek 与 Advisor Selenedesign/narrative/characters/下两者都无声线档案Phase 2 开始world-builder 正常推进。Input/team-narrative ironveil surrender negotiation scene预期行为链Phase 1 完成叙事简报列出 Commander Varek 与 Advisor Selene 两个角色Phase 2 中 writer 与 world-builder 并行派生writer 返回BLOCKEDCannot produce dialogue — no voice profiles found for Commander Varek or Advisor Selene indesign/narrative/characters/. Voice profiles required to match character tone and speech patterns.编排者立即上报writer: BLOCKED — Missing prerequisite: character voice profiles for Commander Varek and Advisor Seleneworld-builder 的输出被保留产出包含传说词条的部分报告AskUserQuestion呈现选项先创建声线档案转给 narrative-director 或设计工作流内联提供最小声线指示并以该上下文重试 writer停下先创建声线档案再继续没有 writer 输出时编排者不进入 Phase 3。关键断言writer 的阻塞在 Phase 3 开始前上报world-builder 已完成的传说输出保留在部分报告中缺失前提声线档案被具体点名角色名 预期文件路径AskUserQuestion至少提供一个解决缺失前提的选项编排者不伪造声线档案或凭空发明角色声音writer 处于 BLOCKED 且无用户明确授权时Phase 3 不启动。该用例是依赖分析的样板writer 的对白产出依赖声线档案这一前提缺前提时宁可阻塞也不降质产出。这与 writer.md 的 Case 4物品描述引用未定义的Berserker state机制时拒绝写出可能误导玩家的描述一脉相承——不写会制造错误预期的内容是 writer 的协议底线。四、静态断言结构的可机检性除行为用例外规范还包含一组静态断言Structural Assertions用于在不运行技能的情况下检查技能文件本身的形态是否符合约定具有必需的前置元数据字段name、description、argument-hint、user-invocable、allowed-tools至少包含 2 个阶段标题Phase Headings包含裁决关键词COMPLETE、BLOCKED包含 File Write Protocol 章节文件写入委托给子 Agent——编排者不直接写文件子 Agent 在任何写入前强制May I write to [path]?结尾包含下一步交接引用/design-review、/localize extract、/dev-story包含 Error Recovery Protocol错误恢复协议章节AskUserQuestion在阶段转换处、继续之前使用Phase 2 显式并行派生 world-builder 与 writerPhase 5 显式并行派生 writer、localization-lead 与 world-builder。静态断言与行为断言双轨并行构成了 CCGS 测试框架结构可机检 行为可推演的验收体系这也是 CCGS Skill Testing Framework/CLAUDE.md 中先读 catalog.yaml 拿 spec 路径 → 读技能 → 读 spec → 逐用例评估断言工作流的基础。五、协议合规不可破坏的十条红线Protocol Compliance 章节列出了技能每次运行都必须满足的协议约束每个阶段输出之后、下一阶段启动之前都使用AskUserQuestion并行派生Phase 2world-builder writer与 Phase 5writer localization-lead world-builder在等待结果前就发出全部 Task 调用编排者不直接写任何文件——所有写入委托给子 Agent每个子 Agent 在任何写入前执行May I write to [path]?协议任何 Agent 的 BLOCKED 状态立即上报——绝不静默跳过当部分 Agent 完成、部分阻塞时总是产出部分报告裁决严格为COMPLETE或BLOCKED不使用其他值Next Steps 交接引用/design-review、/localize extract与/dev-story。其中编排者不写文件、写入全由子 Agent 按 May I write 协议执行是 CCGS 全框架的通用写入守则quality-rubric 的team类之外pipeline类的 P3 指标也要求每个产物创建前询问 May I write而非一次性批量批准。而部分报告机制保证了故障的代价可控Case 2 中 world-builder 阻塞时 writer 草稿保留、Case 5 中 writer 阻塞时 world-builder 的传说词条保留——已完成的劳动永不因他人失败而丢失。六、覆盖说明哪些场景不单独测试为什么Coverage Notes 明确了本规范测试策略的取舍边界是理解测试设计意图的关键Phase 3 与 Phase 4 的正常路径由 Case 1 隐式验证不单独设用例——它们的失败模式遵循标准的 Error Recovery Protocol错误恢复协议中的以更窄范围重试Retry with narrower scope与跳过该 AgentSkip this agent两条解决路径不单独测试——它们遵循与 Case 2、Case 5 相同的AskUserQuestion 部分报告模式本地化问题区分咨询性如德语/芬兰语 30% 膨胀警告与阻塞性硬编码格式Case 4 只覆盖阻塞性咨询性场景遵循同样模式但不改变裁决writer 在 Phase 5 的所有对白行 ≤ 120 字符使用字符串键而非原始字符串检查由 Case 4 的本地化合规场景隐式覆盖。这种显式测关键路径、隐式覆盖公共模式的策略避免了为每个分支重复造轮子同时确保最危险的故障模式传说矛盾、缺前提、本地化阻塞都有独立用例钉死。七、在 CCGS 框架中运行与测试该技能从源码结构与框架约定可以推断/team-narrative的行为测试可通过 CCGS 的 skill 测试工作流执行。根据 CCGS Skill Testing Framework/CLAUDE.md标准流程为读取 catalog.yaml获取该技能的spec:路径即CCGS Skill Testing Framework/skills/team/team-narrative.md与category:team读取技能本体位于.claude/skills/team-narrative/SKILL.md与本文档对应的规范文件逐用例评估断言评估结果可写入results/并回填catalog.yaml的last_spec/last_spec_result字段。框架的 CLAUDE.md 特别提醒本目录下的规范描述的是当前实际行为而非理想行为规范由阅读技能写成因此可能固化了技能自身的缺陷当技能实际表现异常时应先修正技能本体再更新规范以匹配修正后的行为。规范失败应视为需要调查而非技能绝对错误。对技能改进框架提供/skill-improve [name]闭环测试 → 诊断 → 提出修复 → 重写 → 重测 → 保留或回退。这使team-narrative这类技能可以持续演进而规范文件始终是对当前行为的可执行快照。八、总结从规范看部门级技能编排的设计哲学/team-narrative规范浓缩了 CCGS 部门级技能编排的完整方法论方向先行叙事方向Phase 1必须先于一切内容生产且每阶段输出都需人工确认——AskUserQuestion不是可选项而是协议红线并行加速依赖独立的阶段Phase 2 双 Agent、Phase 5 三 Agent强制并行把流水线节拍压到最短编审分离narrative-director 既立方向又做终审Phase 1 与 Phase 4写作者与审查者角色分离杜绝自审盲区故障显性化任何 BLOCKED 立即上报、绝不静默跳过未解决的依赖传说矛盾、缺声线档案、本地化阻塞永远以部分报告 人工裁决收尾且已完成的工作永不丢弃写入受控编排者不碰文件系统所有写入由子 Agent 逐次执行May I write?协议裁决二分最终状态只有COMPLETE与BLOCKED配合静态断言与行为断言使技能行为可测试、可回归、可改进。对于希望在自己的多 Agent 工作流中复刻这套模式的技术团队本规范与其配套的 narrative-director.md、world-builder.md、writer.md、level-designer.md、localization-lead.md 五份 Agent 规范构成了一套可直接对照落地的参考实现Agent 领域边界、裁决词汇、阻塞上报格式、写入协议一应俱全——这正是一个可测试、可编排、可交接的游戏叙事生产流水线应有的形态。【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考