novel-to-game

GitHub

将任意语言小说改编为可玩网页游戏原型。通过需求收集、概念设计、世界与视觉构建及QA验证,确保玩法基于成熟机制,核心循环明确且首分钟可见,交付垂直切片。

skills/novel-to-game/SKILL.md worldwonderer/novel-to-game

触发场景

小说转游戏 把这本书做成游戏 故事转游戏 book to game adapt this novel into a game

安装

npx skills add worldwonderer/novel-to-game --skill novel-to-game -g -y
更多选项

不安装直接使用

npx skills use worldwonderer/novel-to-game@novel-to-game

指定 Agent (Claude Code)

npx skills add worldwonderer/novel-to-game --skill novel-to-game -a claude-code -g -y

安装 repo 全部 skill

npx skills add worldwonderer/novel-to-game --all -g -y

预览 repo 内 skill

npx skills add worldwonderer/novel-to-game --list

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 维护统一 术语。分别记录原作文化语境、目标玩家市场和游戏界面语言,不把本地化简化成逐字翻译。

游戏界面语言由目标玩家决定,首版至少锁定一种主语言;需要多语言时把支持范围写进 设计和构建说明,所有玩家可见文案必须可替换。

流程

  1. 创建工作区并在 _progress.md 记录来源、模式和当前阶段。
  2. 做需求 intake 这一步,生成 PRODUCT_BRIEF.md(见上);未确认假设记入 _progress.md
  3. 调用 novel-game-analyze 生成有必要证据的 SOURCE_BIBLE.md
  4. 调用 game-concept,在 PRODUCT_BRIEF 框定的平台/类型/画风/分级内生成并选择 CONCEPT.mddirector 在这里停靠。
  5. 调用 game-world-design 生成 GAME_DESIGN.md
  6. 调用 game-art-direction 生成 ART_DIRECTION.md
  7. 调用 game-build 实现完整原型,再用 game-qa 验证;blocker/majorQA_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.mdblocker/major 且可运行路径明确时,才报告整条流程完成。

版本历史

  • 470e35d 当前 2026-07-31 13:49

    强制核心循环必须复用至少两款已发行游戏的成熟玩法,禁止发明新机制;创新仅限IP、剧情与美术;新增QA对核心动词的证据验证要求,防止输出过于扁平或不可识别。

  • 827fb80 2026-07-30 20:19

同 Skill 集合

skills/game-concept/SKILL.md
skills/game-world-design/SKILL.md
skills/novel-game-analyze/SKILL.md
skills/game-art-direction/SKILL.md
skills/game-build/SKILL.md
skills/game-qa/SKILL.md

元信息

文件数
0
版本
470e35d
Hash
a879d26e
收录时间
2026-07-30 20:19

首页 - Wiki
Copyright © 2011-2026 iteam. Current version is 2.155.2. UTC+08:00, 2026-08-01 00:35
浙ICP备14020137号-1 $访客地图$