NovelToGame: an Agent Skills pipeline that keeps novel adaptations traceable

The failure mode NovelToGame was written against

Ask a coding agent to turn a book into a game and you usually get one of two things: a reskin of a familiar genre with the novel's names pasted on, or a clickable plot summary where the player advances text and nothing else. The README names both outcomes directly, calling them a generic reskin or a clickable plot summary. NovelToGame exists to prevent that drift by making the adaptation staged and attributable rather than a single prompt. The stated goal is that the adaptation stays traceable and that each major decision has a clear owner. That phrase, a clear owner, is the design thesis: a human or a named skill step is responsible for concept, world and art direction, implementation and QA, so a later stage cannot quietly redefine what an earlier stage decided. The audience is therefore not novelists shopping for a game. It is engineers and technical designers who already drive an agent CLI and want a repeatable procedure for adaptation work, plus teams prototyping a playable version of licensed or public-domain material before committing to a real production.

What the seven skills actually enforce

The README describes the workflow as five named stages: source analysis, concept selection, world and art direction, implementation, and runtime QA. The install commands reference seven skills, so the five stages are packaged across more than five skill files, though the README does not enumerate which skill maps to which stage. What it does specify is the content of the first stage: extract rules, spaces, character agency, conflicts and visual anchors with citations. That citation requirement is the mechanism that separates this from prompt-and-pray adaptation. If the analysis step must attach source references to each extracted rule, then a later design step that invents a combat system has nothing to cite, and the gap becomes visible in the artifact rather than buried in the model's reasoning. The same logic applies to visual anchors: art direction is supposed to derive from described imagery in the text, not from a generic genre mood board. The documentation does not state how citations are formatted, whether they are line numbers, chapter references or quoted spans, and it does not describe a validator that rejects uncited claims. The repository does ship a Validate workflow, per the badge in the README, but the README does not say what that workflow checks.

Runtime targeting and the language promise

Two commitments in the README are worth separating from the marketing language around them. The first is target-runtime delivery: build for the approved platform or engine, and do not let implementation silently redesign the game. This matters because the cheapest path for an agent asked to produce a game is often a browser toy, and the README explicitly says the build and QA stay on the chosen platform instead of silently falling back to an easier substitute. The second is language handling. Bring a novel in any language, and the generated artifacts follow the requested language. These two together define the practical envelope: you pick the runtime and the output language up front, and the pipeline is supposed to hold both. The three published examples show the range of what has been built. Journey to the West and Jin Ping Mei are browser-playable adaptations with design estimates of 45 to 90 and 60 to 90 minutes respectively. Project Plateau is different in kind: a first-person 3D field-photography game adapted from The Lost World, running on desktop WebGL2 with a stated 1 to 3 minute run. That spread suggests the skills are not locked to a single genre or camera model, but the README does not list which engines or platforms are supported, so the boundary of target-runtime delivery is undocumented.

Installing the skills and starting an adaptation

Installation goes through the skills CLI. For Claude Code the command is npx skills add zenstory-ai/novel-to-game -g -y -a claude-code -s '*', invoked afterward as /novel-to-game. Codex uses the same package with -a codex and is invoked as $novel-to-game. Kimi Code uses -a kimi-code-cli and is invoked as /skill:novel-to-game. To install all three adapters at once, the README gives npx skills add zenstory-ai/novel-to-game -g -y -s '*' -a claude-code -a codex -a kimi-code-cli. Cloning the repository also enables project-local skill discovery in all three CLIs, which is the path to take if you want the skills pinned to a specific checkout rather than installed globally. Starting an adaptation means handing the agent a novel file, a directory or a link, then writing a prompt. The README's example asks for the quick path, requests a recommendation of target platform, genre and engine from the source, caps the first build at about 15 minutes, and specifies that the player enters as an original character with a new route through the conflict. A second example covers the interactive-story case, where saying interactive story locks the narrative-led experience profile. In that mode the README says concept, design and QA judge continuous scenes, character dialogue, testimony and key choices rather than rounds, cards and resource bars, and variables stay as hidden causal tags instead of a visible stat panel.

The quick path and what it chooses not to ask

The quick option is the one most people will use first, and its behaviour is defined by restraint. The agent drafts sensible defaults, asks only about materially branching or safety-sensitive choices, compares meaningful alternatives, and continues through design, build and QA. There is an explicit anti-pattern in the description: directions already selected are validated, not reopened to fill a quota. That is a real design decision and it cuts both ways. It keeps a short session short, which is the point, but it also means the first pass may settle on a genre or engine you would have questioned. The mitigation is that the prompt itself is the control surface. If you care about the target platform, say so in the opening message rather than expecting the agent to interrogate you. The narrative-led profile is a good example of a mode switch that only activates if you name it. Ask for an interactive story and the QA criteria change to scene continuity, dialogue, testimony and key choices. Ask for a game without that phrase and you get the systems-oriented defaults, with the progression arc the README describes as fixed for the non-narrative track.

Voice synthesis, QA evidence and the limits of both

Two features are described as deliberately restrained. On voice, the README says the pipeline synthesizes only selected high-value lines at build time, keeps subtitles and mute fallbacks, and never sends the whole novel to a TTS provider by default. That last clause is the important one: it is a default, not a hard guarantee, and the documentation does not describe a mechanism that enforces the limit. On QA, the claimed coverage is startup, rendering, input, the core loop, an outcome, restart, and explicit limitations in the tested runtime. The phrase in the tested runtime is doing real work there, and it is also where the weakest link sits. Automated QA of a game is hard. The README does not explain how rendering or input are verified, whether a human confirms the outcome, or what counts as an explicit limitation. The three playable examples are labelled playable prototype, which is the honest description of the output class. This is not a pipeline that produces a shippable commercial title from a manuscript. It produces a playable, documented prototype with a case study attached, and the case study is where the provenance claim can actually be inspected: source provenance, concept trade-offs, game and art direction, runnable source, and evidence from the playable paths, per the README's description of what each example links to.

Where a general agent or a visual novel engine fits better

The obvious alternative is to skip the skills entirely and drive the agent yourself: paste the novel, ask for a game, iterate. That approach is cheaper to start and has no install step, but it gives up the citation requirement and the staged handoff, which are the two things NovelToGame adds. The more interesting comparison is with a dedicated visual novel engine such as Ren'Py. Ren'Py is a mature runtime with its own scripting language, save system, and packaging for desktop and mobile. It assumes you have already made the adaptation decisions and want a stable engine to express them in. NovelToGame inverts that: it assumes the hard part is the adaptation itself, and it treats the runtime as a target to be selected from the source material. For a dialogue-heavy, choice-driven adaptation with a fixed script, Ren'Py will be the more predictable tool, and its output will not depend on which model version you happen to be running. For a case where you do not yet know whether the novel wants to be a resource-management game, a field-photography expedition or an interactive story, the NovelToGame concept-selection stage is doing work that an engine cannot do for you. The two are not mutually exclusive, but the README does not describe an export path from NovelToGame artifacts into any specific engine, so treating it as a front end for Ren'Py would be an assumption rather than a documented workflow.

Versioning, licence and what to verify before you commit

The project is MIT licensed, which permits commercial use and modification provided the licence and copyright notice are retained. That is the whole of the licence implication here; whether your specific use of a source novel is permissible is a separate question the licence does not touch, and adapting a copyrighted novel into a game is not something an MIT licence grants you. On maintenance, the release history is short and dense: v0.2.0 in early August 2026 with Project Plateau and what the notes call evidence-first delivery, v0.3.0 in late August with replayable adaptation contracts and deeper playable examples, then v0.3.1 in early September with refreshed example visuals and a leaner skill package. Three releases in about five weeks, with the last push dated 2026-09-07. The pattern suggests active iteration, and the v0.3.1 note about a leaner skill package hints that the skill surface is still being reshaped, which is the main upgrade cost to plan for: a prompt that works against one version of the skill files may need adjusting after a package reorganization. Because the project is Markdown-first, upgrading is mostly a matter of reinstalling the skills rather than migrating code you own. The thing to verify first is the one the README leaves thinnest: run one short novel through the quick path, then open the generated QA evidence and check whether the startup, rendering, input and outcome claims describe your actual runtime or a plausible-sounding summary of it. That single check tells you whether the evidence-based QA promise holds for your target, and it costs one 15-minute build.

Editorial conclusion

Adopt NovelToGame if you already work inside Claude Code, Codex or Kimi Code and want the adaptation decisions, not just the output, to stay inspectable. Skip it if you need a deterministic build system that runs without an agent in the loop, or if your target is a platform the skills do not cover. Before committing, install with npx skills add zenstory-ai/novel-to-game -g -y -a claude-code -s '*' and run one short novel through the quick path to see whether the generated QA evidence actually reflects your runtime.

Official sources

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