version: "1.0.0" name: game-craft description: 互动游戏创作判断手册。作者要求设计游戏卖点与核心循环、世界与角色资料库、人物性格与人设、状态系统、规则与判定、游戏规划、开局与回合、选项与节奏，或诊断互动故事/跑团问题时使用；提供判断、模板与诊断，不负责执行流程、文件写入、配置提交与状态同步。 category: game agent: general,ide

互动游戏创作

把游戏设计判断落成作者能直接使用的交付物。原则用于取舍，不用于逐项打分；作者的题材、玩法、预期体验和已确认设定优先。

本技能是创作判断层，只补充判断、模板和诊断，不决定执行流程。游戏前期设计、资料库、状态/规则/规划模板和开局文本开始前加载；读取工作区、写入资料、提交配置、跑回合和状态同步仍按当前流程和本次授权执行。本技能第一版面向创作 Agent，不替代 Game Agent 的回合协议；游戏引擎或插件开发不属于本技能，使用 extension-development。

开工前先确认三件事

1. 玩家是谁、来做什么、为什么留下：玩家扮演谁？反复做什么？什么让他愿意再来一回合？
2. 哪些是已确认事实，哪些只是可能：canon、当前状态、未来计划分别是什么？哪些必须留给玩家决定？
3. 这一局要记住什么：哪些必须跨回合稳定？哪些只是即兴？如果只保留三个状态值，是哪三个？

六条核心判断

网文向游戏还要额外检查：成长是否可感、爽点是否有铺垫、金手指是否有代价、世界是否有阶梯、日常是否有钩子。经典网文的结构是参照，不是必须凑齐的清单；先确认玩家体验，再决定借用哪些。成长、爽点、资源、世界阶梯、题材 lens 见 web-novel-patterns.md。

三层账本 + 两个契约

两个契约：

• 规则契约：世界法则放 Lore，判定规则放 Rule System，叙述规则放 Narrative Style。不要用世界法则代替判定，也不要把判定写进设定。
• 信息契约：真相放 Lore，玩家已知放 State，揭示时机放 Planning。不要把玩家、角色和导演的知识边界混在一起；也不要把导演真相塞进状态账本。

场景路由

根据作者的任务选择对应参考，只读相关文档；跨场景时再补读。这些是同一技能的参考文档，无须调用其他技能或依次完成所有场景。

参考位置：skill://game-craft/references/world-and-cast.md、skill://game-craft/references/character-personality.md、skill://game-craft/references/state-and-rules.md、skill://game-craft/references/planning-and-scenes.md、skill://game-craft/references/opening-and-diagnosis.md、skill://game-craft/references/web-novel-patterns.md。

推进一个回合的最小结构

情境（谁想要什么 / 什么压力）
→ 玩家意图
→ 裁定（直接裁定 / 规则检定）
→ 后果（成功、失败、代价、新信息）
→ 状态与关系变化
→ 新的选择

• 每个回合至少改变一项：信息、位置、资源、关系、威胁、目标。
• 不要求每个动作都掷骰；只有“有不确定性 + 有意义的后果”才需要规则。
• 结尾停在有压力的选择，不停在总结或空问句。

交付前检查

• 可玩：玩家现在能做什么？每个选项有代价吗？
• 有压力：如果玩家不动，什么会恶化？
• 有变化：这回合结束后，局势/关系/信息/资源变了什么？
• 有依据：结果来自已建立的规则、状态、资料或前文吗？
• 有边界：玩家知道什么？角色知道什么？有没有把导演真相泄漏给玩家？
• 可记忆：新增事实放对账本了吗？状态字段有更新规则吗？
• 可继续：结尾留下的是选择，不是总结？
• 规模匹配：是否只交付了作者要的范围？是否过度构建？

不要

• 不要为每个想法新建资料条目；先问它是否可玩、是否稳定。
• 不要在没有“读取它的决定”时新增状态字段。
• 不要用掷骰决定故事是否继续；失败应改变局势，不是停住。
• 不要替玩家决定选择、台词或结果。
• 不要把规划写成固定剧本；准备情境、压力、议程和可能。
• 不要让 NPC 原地等待玩家；给每个重要角色一个议程。
• 不要把 NPC 的性格写成一串形容词；每个标签都要有可演出的台词、动作或反应。
• 不要让所有 NPC 用同一种态度和说话方式；玩家要能遮住名字认出是谁。
• 不要隐藏必要信息却不给线索；不要用“猜不到”制造悬念。
• 不要为了戏剧性改写已建立的 canon 或状态。
• 不要照搬其他系统的数值/字段；先问它是否服务这个游戏的取舍。
• 不要把经典网文的结构当清单逐项凑；先确认玩家体验，再选择真正需要的成长、爽点、资源、世界阶梯和题材场景。
• 不要另建与 Lore、Actor State、Planning 并行的记录系统。

与现有流程配合

• 本技能只提供判断与参考；执行顺序、文件写入、资料更新、配置提交、回合提交和状态同步仍按当前流程与本次授权。
• 设计前先读与本次范围相关的既有内容：故事简介（Origin）、Lore Index、已选状态/规则/规划资源、最近回合；如果项目使用 CREATOR.md，也读取其中与游戏相关的长期规则。资料正文用 query_lore_items 按名称或分组读取，需要全文时用 detail=full。
• 资料库用 write_lore_items 写入、query_lore_items 读取；不要直接编辑 setting/lore/items.json。稳定事实才进资料库，当前变化放状态或规划。
• 需要创建或修改可复用的状态系统、规则系统、规划模板或事件包时，按 configuration Skill 的对应参考和 config_read / config_apply 协议执行；本技能只决定“建什么、为什么”，不手写资源 JSON。
• 游戏故事线、主角快照、开局和模块选择属于游戏页与当前故事配置；不要用文件或资料条目模拟故事线、回合状态或版本历史。
• 改编或同人游戏先列原著不可变 canon、可改写空白、玩家可改变的分歧点；不要让玩家选择改写已确认事实，除非明确做平行世界。
• 叙事正文的文风判断可复用 novel-craft 的场景/表达参考；本技能不重复小说写作原则。
• 当前 Agent 没有写入工具时，不要假装已经写入；在对话中交付设计，并明确哪些内容需要作者在资料库、配置管理或游戏页应用。