team-live-ops

团队实时运营

参数检查： 如果未提供赛季名称或活动描述，请输出：

“用法：/team-live-ops [season name or event description] [--review full|lean|solo] — 请提供赛季或实时活动的名称或描述，以便进行规划。” 然后立即停止，不得启动任何子 Agent 或读取任何文件。

使用有效参数调用此技能时，通过结构化规划流程协调实时运营团队。

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

阶段 0：解析配置

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

以上配置已解析——按原样使用；--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 会影响上方的 Decision Points 说明。关于各模式如何改变流水线行为，请参阅上方的 Decision Points 说明和 .claude/docs/automation-modes.md。

team.size：决定哪些 Agent 处于活动状态（与 review_mode 的阶段门深度和 workflow 文档相互独立）。

• individual（默认）：live-ops-designer + economy-designer。其他 Agent 通过这两位征询意见，不单独生成。
• small：+ analytics-engineer + community-manager。
• studio：+ writer + narrative-director（文档所述的完整流水线）。 在 individual 下，如果需要非核心 Agent，则通过最近的活动核心 Agent 转交，并附上一条说明。“阶段门”指任何以本流水线列出的 AskUserQuestion 决策点结束的阶段——即上方 Decision Points 中的转换，或下方流水线中写明的 Gate 步骤，无论 automation 模式如何。guided 和 autonomous 会改变如何通过阶段门（自动推进，或通过 log_decision 记录），但不会改变它是否属于阶段门，因此下方有界例外条件 (3) 在所有模式下都适用。仅限“阶段门”的 Agent 会在这些节点生成，不会在其他节点生成。此活动集范围规则适用于下方整个流水线：任何阶段若指定了活动集之外的 Agent，都应通过最近的核心 Agent 转交，而不是生成该 Agent。

在阶段 1 之前公布活动集——绝不要悄悄缩减。 生成任何内容之前，用一行说明本次运行实际会生成哪些 Agent，以及下方流水线虽有提及、但在解析出的 team.size 下不会生成哪些 Agent。例如：

活动集（team.size: <解析后的值>）：<上方针对该值列出的 Agent>。 本次运行不会生成：<本流水线提及的所有其他 Agent> — 通过 <最近的活动核心 Agent> 征询意见。如需扩展范围，请提高 team.size（或 modes.rigor）。

直接根据上方的 team.size 列表和本文件流水线中提及的 Agent 填写——不要照搬示例。不同编排器的两组 Agent 各不相同。

下方流水线读起来像是多 Agent 并行处理，但在发布时的默认配置下，实际只有一两个 Agent——team-release 列出十个，实际运行一个；team-narrative 在五个阶段中列出六个，实际只运行 writer。这种缩减是正确的： team.size 以 rigor 为优先级，较窄的默认范围是控制 token 用量的手段。 如果不说明这一点，读者就无法区分正确缩减的运行与故障流水线；而且上方“通过最近的核心 Agent 转交，并附上一条说明”的规则只会在转交时触发，永远不会说明整个运行的配置情况。

这与本文件其他位置有关跳过检查的报告规则相同：一项约束虽得到执行，却从未明确说明，对阅读输出的人来说，就和它从未得到执行无法区分。

团队组成

• live-ops-designer — 赛季结构、活动节奏、留存机制、战斗通行证
• economy-designer — 长线运营经济平衡、商店轮换内容与价格（其节奏由 live-ops-designer 设定）、货币定价、保底计时器
• analytics-engineer — 成功指标、A/B 测试设计、活动追踪、仪表板规格
• community-manager — 面向玩家的公告、活动说明、赛季宣传文案
• narrative-director — 赛季叙事主题、故事线、世界事件设定
• writer — 活动说明、奖励物品名称、赛季风味文本、公告文案

如何分配任务

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

• subagent_type: live-ops-designer — 赛季／活动结构与留存机制
• subagent_type: economy-designer — 长线运营经济平衡与奖励定价
• subagent_type: analytics-engineer — 成功指标、A/B 测试、活动数据采集
• subagent_type: community-manager — 面向玩家的沟通与宣传文案
• subagent_type: narrative-director — 赛季主题与叙事设定
• subagent_type: writer — 所有面向玩家的文本：活动说明、物品名称、文案

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

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

用实际路径替换 [path]。 工作产物应放在 production/live-ops/[season-slug]/ 下，其中 [season-slug] 是将参数转换为 slug 后的形式——全部小写，空格替换为连字符。每位 Agent 使用一个文件，以免并行阶段共用同一文件：

阶段／Agent	写入路径
1 live-ops-designer	production/live-ops/[season-slug]/brief.md
2 narrative-director	production/live-ops/[season-slug]/narrative.md
3 economy-designer	production/live-ops/[season-slug]/economy.md
4 analytics-engineer	production/live-ops/[season-slug]/analytics.md
5 narrative-director	production/live-ops/[season-slug]/narrative-text.md
5 writer	production/live-ops/[season-slug]/copy.md
6 community-manager	production/live-ops/[season-slug]/comms.md

这些都是工作草稿；design/live-ops/seasons/ 下的最终文档将由这些草稿汇编而成（输出文档）。

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

在流程允许的情况下，并行启动互不依赖的 Agent（阶段 3 和 4 可同时运行）。

流程

阶段 1：赛季／活动范围界定

委派给 live-ops-designer：

• 定义赛季或活动：类型（季节性、限时活动、挑战）、持续时间、主题方向
• 列出内容清单：有哪些新内容（模式、物品、挑战、剧情节点）
• 定义留存机制：本赛季期间，哪些内容能促使玩家每天／每周回归
• 确定资源预算：需要创作多少新内容，以及可复用多少内容
• 输出：包含范围、内容清单和留存机制概述的赛季简报

阶段 2：叙事主题

委派给 narrative-director：

• 阅读阶段 1 的赛季简报
• 设计赛季叙事主题：本次活动如何与游戏世界关联？
• 确定玩家在活动期间会逐步发现的核心剧情钩子
• 找出本赛季可以推进的现有背景故事线索
• 输出：叙事框架文档（主题、剧情钩子、背景故事关联）

阶段 3：经济系统设计（与阶段 4 并行）

委派给 economy-designer：

• 阅读赛季简报和 design/live-ops/economy-rules.md 中的现有经济规则
• 设计奖励路线：免费档位的进度安排、付费档位的价值主张
• 规划赛季内经济：赛季货币、商店轮换内容、定价
• 为任何随机元素定义保底计时器机制和防非酋机制
• 确认付费档位中没有付费取胜物品
• 输出：包含奖励表、定价和货币流转的经济系统设计文档

阶段 4：分析与成功指标（与阶段 3 并行）

委派给 analytics-engineer：

• 阅读赛季简报
• 定义成功指标：参与率目标、留存率提升目标、战斗通行证完成率
• 设计赛季期间要进行的 A/B 测试（例如，不同的奖励发放节奏）
• 指明本赛季内容所需的新遥测事件
• 输出：包含成功标准和埋点要求的分析计划

阶段 5：内容撰写（并行）

仅在收集到阶段 3 和阶段 4 的结果后开始。并行委派：

• narrative-director（如有需要）：撰写本赛季的游戏内叙事文本（过场动画脚本、NPC 对话、世界事件描述）
• writer：撰写所有面向玩家的文本——活动名称、奖励物品描述、挑战目标文本、赛季风味文本
• 两者都应阅读阶段 2 的叙事框架文档

阶段 6：玩家沟通计划

委派给 community-manager：

• 阅读赛季简报、经济系统设计和叙事框架
• 起草赛季上线公告（语气、重点内容、针对不同平台的版本）
• 规划沟通节奏：上线前预告、上线日公告、赛季中期提醒、最后一周的限时紧迫感宣传
• 起草第 1 天补丁说明中的已知问题部分占位内容
• 输出：包含每个沟通节点文案草稿的沟通日历

阶段 7：审核与签字确认

收集所有阶段的输出，并呈现一份整合后的赛季计划：

• 赛季概要（阶段 1）
• 叙事框架（阶段 2）
• 经济系统设计与奖励表（阶段 3）
• 分析计划与成功指标（阶段 4）
• 书面内容清单（阶段 5）
• 沟通日历（阶段 6）

向用户呈现摘要，包含：

• 内容范围：将要创建的内容
• 经济系统健康检查：奖励路线是否公平，且不存在诱导消费？
• 分析准备情况：成功标准是否已定义并完成埋点？
• 伦理审查：根据 design/live-ops/ethics-policy.md 检查阶段 3 的经济系统设计
  • 如果文件不存在：标记“伦理审查已跳过：未找到 design/live-ops/ethics-policy.md。经济系统设计尚未依据伦理政策进行审查。建议在开始生产前创建该文件。”将此标记加入赛季设计输出文档。后续步骤中添加：创建 design/live-ops/ethics-policy.md。
  • 如果文件存在且发现违规：标记“伦理警示：[阶段 3 经济系统设计中的元素]违反了[政策规则]。在解决此问题之前，禁止批准。”不要给出 COMPLETE 判定，也不要编写输出文档。使用 AskUserQuestion 提供以下选项：修改经济系统设计 / 提供有记录的理由以覆盖该问题 / 取消。如果用户选择修改：重新启动 economy-designer 以产出修正后的设计，然后返回阶段 7 审查。如果用户选择取消：以 Verdict: BLOCKED 结束——“由于尚未解决的伦理违规，实时运营设计已取消。请解决标记的问题，然后重新运行 /team-live-ops。”
• 待解决问题：开始生产前仍需作出的决定

请用户批准赛季计划后，再委派给制作团队。只有在用户批准且不存在尚未解决的伦理违规时，才给出 COMPLETE 判定。如果伦理违规尚未解决，以 Verdict: BLOCKED 结束。

输出文档

所有文档均保存到 design/live-ops/ — 但协调器必须先询问是否可以写入。 design/ 不属于受限写入例外涵盖的三个目录（production/、docs/、tests/），因此，分配这些路径的子 Agent 必须先询问。不要扩大例外范围来绕过这一要求。 遵循 team-level的做法：子 Agent 将工作成果写入production/，因为该例外涵盖此目录；**由你**汇总最终文档，并通过 AskUserQuestion询问——“我可以将赛季计划写入design/live-ops/…` 吗？”——仅在用户批准后写入。

路径：

• seasons/S[N]_[name].md — 赛季设计文档（来自阶段 1-3）
• seasons/S[N]_[name]_analytics.md — 分析计划（来自阶段 4）
• seasons/S[N]_[name]_comms.md — 沟通日历（来自阶段 6）

错误恢复协议

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

如果任何已启动的 Agent 返回 BLOCKED、出错或无法完成：立即说明情况，不要越过它所阻塞的依赖项，并始终提供部分报告。 被跳过的 Agent 所负责的部分应保留为明确标出的缺口——绝不要自行填入内容。完整流程：.claude/docs/error-recovery-protocol.md。

如果 BLOCKED 状态无法解决，以 Verdict: BLOCKED 而非 COMPLETE 结束。

文件写入协议

子 Agent 会将工作产物写入 production/，遵循上文“为何这不会违反协作协议”中记录的有限例外——路径由你指定，产物是 production/、docs/ 或 tests/ 下的新文件，并且该阶段由 AskUserQuestion 门控。子 Agent 不会在这些范围内每次写入时都征求许可；超出范围则必须询问。design/live-ops/ 下的最终文档——赛季设计、分析计划、沟通日历——属于例外：编排者会在自己发出“我可以写……吗？”提示后（见上文“输出文档”）自行汇编并写入这些文档。

输出

摘要应涵盖：赛季主题和范围、经济设计亮点、成功指标、内容列表、沟通计划，以及任何需要用户在制作前作出决定的未决事项。

结论：完成 — 赛季计划已制定并移交制作。

后续步骤

• 对赛季设计文档运行 /design-review，进行一致性验证。
• 运行 /sprint-plan，为本赛季安排内容创作工作（对于没有冲刺的 workflow: minimal，请改为将其添加到简报的构建顺序中）。
• 赛季内容准备好部署后，运行 /team-release。
• 如果运行因伦理标记而以 受阻 状态结束：根据 design/live-ops/ethics-policy.md 修订经济设计，然后重新运行 /team-live-ops；在计划完成之前，请勿执行上述三个步骤。