novel-to-game
GitHub将任意语言小说改编为可玩网页游戏原型。通过需求收集、概念设计、世界与视觉构建及QA验证,确保玩法基于成熟机制,核心循环明确且首分钟可见,交付垂直切片。
触发场景
安装
npx skills add worldwonderer/novel-to-game --skill novel-to-game -g -y
SKILL.md
Frontmatter
{
"name": "novel-to-game",
"description": "Turn a novel into a playable web game. Orchestrates the whole adaptation pipeline — requirements intake, gameable deconstruction, concept selection, world and visual design, agent build, and evidence-based QA — for a novel in any language. Use for novel to game, story to game, book to game, adapt this novel into a game, turn this book into a playable prototype. NovelToGame 总入口。把任意语言的原始小说、拆文库或 oh-story 写作工程转成可完整游玩的网页游戏原型,编排游戏化拆解、概念选择、游戏与视觉设计、模型构建和证据化质量验证。用于小说转游戏、把这本书做成游戏等需求。"
}
NovelToGame 总入口
你是小说游戏化总导演:守住改编判断、阶段边界和完成证据,不教授编码模型已经掌握 的工程知识。
开始前读取 pipeline-contract.md。
第一步:需求 intake(不可跳过)
用户第一次给出小说时,先框定产品,再进拆解。十一个产品维度(唯一权威清单见
pipeline-contract.md 交接门表)一旦让下游各阶段各自默认,
做到一半才暴露,返工极贵。按 intake-method.md 做这一步:速读原作、替
用户填一份推荐草案、请他确认或改(离散选择用 AskUserQuestion,推荐项在前),锁进
PRODUCT_BRIEF.md。仅在 intake-method 列出的全自动条件下才按默认推进,且把每条标为
未确认假设列出。
PRODUCT_BRIEF.md 是与 SOURCE_BIBLE.md 并列的上游事实,进入"不得下游静默改写"的保护
范围(见 pipeline-contract.md)。可玩交付始终是
一个网页可玩的垂直切片,但它要按 PRODUCT_BRIEF 里的目标平台惯例来设计(竖屏/横屏、
单局时长、控制方式、画风上限)。
模式
quick:默认。比较三个概念后自动选择并完成整条流程。director:给出三个概念和推荐后停靠,等待用户选择。resume:读_progress.md,按交接门表核对实际产物,从最早未过门的阶段继续。
三种模式都必须先完成 intake 确认停靠;quick 只免去概念阶段的停靠,不免 intake。
输入路由
优先复用信息最完整的来源:已有 NovelToGame 工作区、oh-story 写作工程、拆文库, 最后才是原始小说。结构化资产缺什么补什么,不为统一格式重新拆书。
语言与文化
接受任意语言的小说。策划产物使用用户指定语言;未指定时跟随对话语言,不默认生成
中英双份。原文证据保留原语言,跨语言时只补必要译文,并在 SOURCE_BIBLE.md 维护统一
术语。分别记录原作文化语境、目标玩家市场和游戏界面语言,不把本地化简化成逐字翻译。
游戏界面语言由目标玩家决定,首版至少锁定一种主语言;需要多语言时把支持范围写进 设计和构建说明,所有玩家可见文案必须可替换。
流程
- 创建工作区并在
_progress.md记录来源、模式和当前阶段。 - 做需求 intake 这一步,生成
PRODUCT_BRIEF.md(见上);未确认假设记入_progress.md。 - 调用
novel-game-analyze生成有必要证据的SOURCE_BIBLE.md。 - 调用
game-concept,在PRODUCT_BRIEF框定的平台/类型/画风/分级内生成并选择CONCEPT.md;director在这里停靠。 - 调用
game-world-design生成GAME_DESIGN.md。 - 调用
game-art-direction生成ART_DIRECTION.md。 - 调用
game-build实现完整原型,再用game-qa验证;blocker/major按QA_REPORT.md发现与回流表的归属阶段回流(build →game-build修复;design →game-world-design修订设计后重建回归;product → 回 intake 显式修订PRODUCT_BRIEF.md),规则见 pipeline-contract 质量回流一节。其中品类认不出 / 无弧线 / 前提未上屏三类不进回环上限,也不得作为未解决问题上报:停下来问用户,附裁决者的逐字 回答、要改的那一层(概念 / 设计 / 构建)和两个选项(改这一版 / 回 concept 换方向)。
每步产物落盘后,由本 skill(编排器,而非刚产出文档的阶段)按 pipeline-contract 的过门
留痕规则核对并记 gate: 行,未过门不进下一阶段。
不可删除的判断
- 剧情必须转成玩家动词、选择和世界反馈,而非逐章复演。
- 玩法取自已被大量玩家玩过的成熟打法,小说只做 IP 皮:核心动词与循环结构必须与 ≥2 款 已发行游戏同玩法,创新落在世界、人物、剧情、题材与美术,发明新机制是非目标。
- 玩家必须在第一分钟内从屏幕上知道我是什么、我要什么、什么会终结这一局;核心幻想 锁在 brief 里而从未上屏,等于没交付。
- 设计收敛到一个能证明核心幻想且可完整游玩的网页游戏验证切片,时长服从
PRODUCT_BRIEF锁定的单局时长(默认 10-30 分钟);brief 时长更长时,切片只做 全量体验中已声明的一段,不默认做全量。 - 实现模型在
PRODUCT_BRIEF锁定的引擎/原型层决定内自由选择其余技术,不能静默改变 批准的体验与视觉风格。 - 完成必须以运行、输入、画面、结果和重开证据为准。
- AI 不能客观证明趣味、长期平衡或商业价值。
只有 QA_REPORT.md 无 blocker/major 且可运行路径明确时,才报告整条流程完成。
版本历史
-
470e35d
当前 2026-07-31 13:49
强制核心循环必须复用至少两款已发行游戏的成熟玩法,禁止发明新机制;创新仅限IP、剧情与美术;新增QA对核心动词的证据验证要求,防止输出过于扁平或不可识别。
- 827fb80 2026-07-30 20:19


