tutorial-workflow

Tutorial Workflow

本 skill 处理“教程是否真的教会玩家玩”，不只看教程能不能跑通。通用层只保留跨游戏成立的教程判断方法；单个游戏的章节拆法、起手路线、案例和专有机制必须下沉到该游戏教程实现、覆盖矩阵或专项文档。

触发

• 用户提到教程、新手引导、onboarding。
• 用户指出教程像规则书、只教按钮、看不懂、不是真实游玩。
• 新增、重写、压缩或审查某个游戏的教程步骤、文案、测试或 E2E。
• 教程要证明“基础流程 / 首回合 / 端到端 / 这个游戏怎么运作”。

必读

• 当前游戏规则真相源：src/games/<gameId>/rule/*.md、docs/games/<gameId>/** 或对应来源资料。
• tutorial-design。
• e2e-verification。
• game-audit-workflow。
• 当前 tutorial.ts、语言包、教程测试和教程 E2E。

通用层落点

准备修改本 skill 或 tutorial-design 前，先判四件事：

1. 这条规则放到第 100 个游戏里是否仍成立。
2. 它约束的是“怎么判断教程合格”，还是当前游戏这次怎么拆章。
3. 它是否偷带当前游戏的专有机制、章节名、起手路线、UI 壳层或地图结构。
4. 另一个游戏没有这套回合 / 资源 / 战斗结构时，它是否仍可执行。

任一答案是否定，就不得进入通用层；写到当前游戏教程实现、覆盖矩阵、docs/games/<gameId>/** 或专项 skill。

核心合同

1. 教程按玩家因果链组织

每个章节或截图链都必须让玩家回答：

• 刚才发生了什么。
• 现在为什么轮到这个动作。
• 做完会改变什么。

不得按代码模块、测试顺序、截图生成顺序或验收清单排序。注入态、预设局面或中段场景必须先解释前一步如何导致当前状态；不能让玩家从基础动作突然跳到终局、特殊结算或胜负页。

2. 先文案，后实现

• 文案方向未锁定前，不改 tutorial.ts、语言包、测试或 E2E。
• 用户正在审文案或要求“先给文案”时，先停在完整文案稿；只有用户认可后才实施。
• 文案来源和章节边界按 tutorial-design 执行：除必要 UI 操作句、当前局面指向和短过渡句外，玩法 / 机制 / 卡牌效果解释只能取规则书原文、卡面原文或已锁定规则真相源；没有原文就标缺口，不能自写解释补上。
• 玩家可见文案不得混入作者话术、实现关系、验收要求、测试结论或内部流程词。

3. 教程要教玩法，不只教按钮

基础教程至少要覆盖：

• 游戏目标、一个基础回合动作和结束 / 胜负条件。
• 首局必须会读的基础数据和常驻 UI，例如生命 / 伤害、资源、回合收入、行动可用性、准备槽、分数 / 战力或等价核心读数；教程要说明它们在哪里、怎么读、何时变化。
• 第一个正式决策入口，而不是低信息量外壳或中段题面。
• 至少一个真实选择、两个以上动作之间的可见因果，以及一个可见收益或结果。
• 当前游戏首次上手高频但不明显的读局操作，例如查看公开信息、牌堆 / 弃牌堆、状态来源、分数 / 战力 / 资源来源、只读规则入口或视角切换。
• 核心结算概念：结算前玩家知道系统会比较什么，结算后知道结果为什么成功或失败。
• 如果规则卖点是组合、连锁、派系 / 角色协同或资源转换，基础教程要出现一次玩家可感知的组合闭环。

只跑到第一个动作、第一张图、空桌或最终数字，不得称为端到端教程。

4. 正式 UI 缺口不能靠教程粉饰

教程文案点名某个动作、入口、状态或结果时，正式 UI 必须有清楚承接：

• “点击 / 选择 / 确认 / 结算”必须指向屏幕上真实可见的对象或按钮。
• 目标是卡牌、骰子、token、棋子、地图格、单位或区域时，主流程优先直选对象本体；代理列表或数字按钮只能作备用 / 无障碍入口。
• 状态、资源、进度、结果和风险若影响决策，必须在正式 UI 中可读；不能只靠教程说明句。
• 高亮必须命中当前真实承接物；不得高亮上一阶段对象、空容器、提示横幅、摘要条或被浮层遮住的底层。
• 教程卡片不得遮挡本步骤要点击或阅读的目标主体。