NovelToGame: Agent Skills that turn a novel into a playable game

The problem NovelToGame is aimed at

Ask a coding agent to turn a book into a game and you usually get one of two things: a reskin with the novel's names pasted onto generic mechanics, or a clickable plot summary where the player advances text and nothing else. Neither is an adaptation. The README frames the failure directly, saying a one-line prompt "often produces a generic reskin or a clickable plot summary."

NovelToGame is an Agent Skills toolkit, not a runtime or a game engine. It installs into an agent CLI and supplies a staged process: source analysis, concept selection, world and art direction, implementation, and runtime QA. The audience is narrow and specific. You need an agent CLI that supports skills, a novel you have the right to adapt, and a willingness to sit through design decisions instead of accepting the first output. If you only want to read a generated story in a browser tab, this is more machinery than the task needs.

How the staged workflow keeps adaptation traceable

The mechanism is a pipeline with named owners for each decision. During source analysis the skills extract rules, spaces, character agency, conflicts and visual anchors, and they carry citations. Those citations are the point: a later design choice can be traced back to a passage instead of being asserted. Concept selection then compares meaningful alternatives rather than generating a single idea, and world and art direction fixes the look before code exists.

Implementation is bound to a target runtime chosen earlier. The README is explicit that build and QA "stay on the chosen platform instead of silently falling back to an easier substitute," which is the most interesting design constraint in the project. It means an approved 3D WebGL2 build is not quietly downgraded to a 2D canvas because that was easier to finish. QA then verifies startup, rendering, input, the core loop, an outcome, restart, and explicit limitations in the tested runtime. That list is unusually concrete for an agent workflow, and it treats "it runs on my machine" as a claim to be demonstrated, not assumed.

One optional piece deserves attention: voice synthesis. The README says the toolkit synthesizes "only selected high-value lines at build time," keeps subtitles and mute fallbacks, and does not send the whole novel to a TTS provider by default. That restraint is a deliberate cost and privacy trade-off, and it is rarer than it should be.

Installing the seven skills and starting a first adaptation

Installation goes through the `skills` CLI rather than a package manager for the project itself. For Claude Code, the README gives this command, which registers all skills globally:

npx skills add zenstory-ai/novel-to-game -g -y -a claude-code -s '*'

After it completes, the skill is invoked with `/novel-to-game`. Codex uses `$novel-to-game` and Kimi Code uses `/skill:novel-to-game`. You can install adapters for all three CLIs at once:

npx skills add zenstory-ai/novel-to-game -g -y -s '*' \
  -a claude-code -a codex -a kimi-code-cli

The README also notes that cloning the repository enables project-local skill discovery in all three CLIs, which is the route to take if you want the skills scoped to one project rather than your machine.

With the skills in place, you hand the agent a novel as a file, a directory or a link. This prompt is the one the README shows for a systems game:

Use novel-to-game quick to adapt this novel into a fully playable game.
Recommend the target platform, genre, and engine from the source, and keep the first build to about 15 minutes.
Let the player enter the world as an original character with a new playable route through its conflict.

The `quick` mode is the low-friction path: the agent drafts defaults, asks only about materially branching or safety-sensitive choices, and continues through design, build and QA. Expect it to ask about the target runtime and the concept before it writes code. If you want an interactive story instead of a systems game, say so explicitly, because that locks the `narrative-led` experience profile and changes what concept, design and QA judge.

The narrative-led profile, and when it is the wrong choice

NovelToGame has two shapes. The default systems track turns source evidence into player verbs, systems, levels, feedback, failure and outcomes. The narrative track keeps continuous scenes, character dialogue, testimony and key choices, and treats variables as hidden causal tags rather than a visible stat panel.

The README's example for that track is precise about the requirement: key choices must change later scenes, character attitudes and the ending, and be named back in later text. That is a real constraint, and it is where a weak adaptation shows. A choice that alters a number but never returns in the prose fails the stated bar.

The limitation is the flip side. This toolkit is wrong for you if you want a game that ships without runtime verification, because the workflow will push you toward testing startup, rendering, input, the core loop, restart and limitations in the chosen runtime. It is also wrong if your source is too thin to support extraction: rules, spaces, character agency, conflicts and visual anchors have to be in the text. And it is wrong if you need an engine the agent cannot actually build and run on your machine, since the target-runtime rule forbids substituting an easier platform. That rule is a strength until it meets a runtime your environment cannot execute, at which point it becomes a blocker rather than a safeguard.

Three worked examples show the range

The repository ships three playable adaptations, each with a case study covering source provenance, concept trade-offs, game and art direction, runnable source, and evidence from the playable paths. They are the fastest way to judge whether the output style suits you.

Journey to the West · Three Borrowings of the Banana Fan is a systems adaptation, estimated at 45 to 90 minutes, all ages. Jin Ping Mei · Ledger of Desire is a household-management adaptation with five resources (silver, influence, reputation, exposure and household strain) across twenty days and five courtyards, estimated at 60 to 90 minutes and marked 18+. Project Plateau is the outlier: a first-person 3D field-photography game adapted from Arthur Conan Doyle's The Lost World, targeting desktop WebGL2 with a 1 to 3 minute run, where the player exposes four glass plates under aerial pressure.

Project Plateau matters because it demonstrates the target-runtime claim rather than describing it. A 3D WebGL2 build is not something a workflow can fake with a text interface, so its existence is evidence that the pipeline can carry a real engine target through to something playable. The README does not state how long any of these took to build, and it does not publish a comparison against other adaptation approaches, so treat the examples as demonstrations of style and scope, not as benchmarks.

How it differs from a visual novel engine

The obvious alternative is a visual novel engine such as Ren'Py paired with a writer. The difference is where the work sits. A visual novel engine gives you a scripting format, a runtime and a player; you supply the script, the branching and the assets, and you decide what the source material contributes. NovelToGame gives you no runtime of its own. It orchestrates an agent that extracts from the source, picks a concept, chooses a runtime, builds, and then verifies the build in that runtime.

That means the two are not substitutes. If your goal is a dialogue-driven romance visual novel with hand-authored routes, a visual novel engine is the direct tool and NovelToGame adds a layer you may not want. If your goal is to explore what a novel's rules and conflicts become when they are turned into player verbs, and you want the derivation written down with citations, NovelToGame is aimed at exactly that. The README's own framing supports this: it targets adaptation decisions, not asset production. Note also that the shipped examples are prototypes, not finished commercial titles, and the README labels them as such.

Licence, maintenance and upgrade cost

The project is MIT licensed, which permits commercial use and modification, and the licence file sits at the repository root. Because the deliverables are generated games and their source, the licence of what you build is a separate question from the licence of the toolkit; the README does not address the licensing of generated output, so settle that with your own counsel rather than assuming MIT covers the artifact.

The last push to the default branch was on 2026-09-07, and the repository is not archived. The release history is recent and dense: v0.2.0 on 2026-08-05 introduced Project Plateau and evidence-first delivery, v0.3.0 on 2026-08-23 added replayable adaptation contracts and deeper playable examples, and v0.3.1 on 2026-09-05 refreshed example visuals and described a leaner skill package. That cadence means upgrade cost is real. The v0.3.1 note about a leaner skill package implies the skill surface is still moving, and the CHANGELOG.md at the root is where that movement is recorded. Read it before you pin a version, because a workflow that changes its contracts between minor releases can invalidate a build you already completed.

The project is Markdown-first, so there is no compiled dependency tree to audit. The upgrade cost is mostly re-reading skill instructions and re-running builds against changed contracts, not dependency resolution.

Editorial conclusion

Adopt NovelToGame if you already work inside Claude Code, Codex or Kimi Code and want the adaptation to stay traceable to the source, with a target runtime chosen before implementation starts. Do not adopt it if you want a one-prompt generator that skips design review, or if you cannot run the built game in the runtime you approved. Before you commit, verify two things yourself: that `npx skills add zenstory-ai/novel-to-game -g -y -a claude-code -s '*'` registers the skills in your CLI, and that the generated build actually starts, renders and accepts input on your machine, because that runtime evidence is the deliverable the project is organised around.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. zenstory-ai/novel-to-game on GitHub