Importing Your LitRPG Manuscript
By Rob Chipman
You already have a manuscript.
Maybe it's 40 chapters of LitRPG serial in Google Docs. Maybe it's a Scrivener project that's been accumulating cruft since 2023. Maybe it's a folder of markdown files in Obsidian Longform, or a single monolithic DOCX your editor keeps complaining about. Whatever the shape, you've been writing for a while, and the thought of migrating to a new tool makes you want to close the tab.
I get it. I've talked to many Royal Road authors about their setups, and the one thing that comes up more than "my spreadsheet is breaking down" is "I'm not rebuilding all of this in something new." The switching cost is the moat that keeps people on tools they've already outgrown.
So let's talk about what migration actually looks like for a LitRPG serial. Not the marketing version — the real one.
The cold start problem
A typical LitRPG author's setup is not one tool. It's four.
The prose lives in Google Docs or Scrivener. The stats live in a spreadsheet. The character notes live in a second Google Doc or a Notion page or a wiki someone set up once and never maintained. Maybe there's a third doc for world lore. Maybe there's a folder of Obsidian notes linking to all of the above.
Moving to a new tool means reconciling all of that. Not just importing the prose — which is the easy part — but figuring out how to express the spreadsheet, the notes, and the world state inside a new model. If the new tool can't hold what you already built, you're not migrating. You're abandoning.
That's the bar I kept in mind when I built AxiomWeaver's import flow. Not "does it open a DOCX." Every editor opens a DOCX. The real question is: can it take everything you already have and turn it into something more useful than the sum of those four tools?
Here's how I think about the pieces.
Step one: the prose
This is the easy part, and I want to be honest that it's the easy part before I talk about the hard parts.
AxiomWeaver imports from five formats out of the box: DOCX, Markdown, plain text, EPUB, and Scrivener project bundles. You can also paste from the clipboard if you want to bring in a single chapter without creating a file for it. Formatting comes through — headings stay headings, bold stays bold, italics stay italics. If you're an Obsidian user writing with the Longform plugin, there's direct support for importing a folder of chapter files.
This covers most of the LitRPG authors I've talked to. For those working in Google Docs, Docs exports cleanly to DOCX with two clicks.
Importing the words in is a solved problem. The interesting part is what happens next.
Step two: cutting the manuscript into chapters and scenes
A 200K-word Scrivener project knows where its chapters are. A 200K-word DOCX file probably doesn't — or it does, but only in the sense that you put "Chapter 14" in big bold text at the top of each section.
AxiomWeaver's structure detection handles this automatically. Four strategies are built in:
- Headings — use your H1s and H2s as chapter and scene boundaries
- Separators — split on scene breaks like
***or--- - Numbered — find "Chapter 1", "Chapter Two", "CHAPTER THREE" patterns and split there
- Auto — best-fit detection that picks the strategy most likely to work for your document
After detection, you get a tree view with word counts per chapter and scene. You can expand each chapter to inspect the scene splits, flip strategies to see how the same manuscript would be divided differently, and skip the whole thing if you just want everything as a flat pile to clean up manually later.
The principle is that you should never have to manually re-create chapter structure. If your manuscript encodes it anywhere — in headings, separators, or numbering — the tool finds it.
Step three: the part nobody else does
Here's where most "writing tools" stop. You've imported your prose, it's split into chapters, and now you have... a clean document. Congratulations. You still have a spreadsheet.
The thing I kept running into with every other tool I tried was that the manuscript and the world were separate concerns. Scrivener holds your prose. A wiki holds your characters. A spreadsheet holds your stats. None of them talk to each other. Migration to a new tool means re-entering everything by hand.
AxiomWeaver takes a different approach. Once your manuscript is imported, the entity scanner reads it in the background. It looks for proper nouns, dialogue patterns, action verbs, and stat block structures. It surfaces a list of candidates — characters, items, locations, abilities — each with the number of times they appear, the contexts they appear in, and a confidence score.
You don't manually enter 40 characters into a new database. You look at the scanner's output, check the ones you want to promote to real entities, assign their types, and click Create. The ones it missed, you add yourself. The ones it found that aren't actually characters — that one time "Sword" was capitalized mid-sentence for emphasis — you uncheck.
For a typical 100K-word LitRPG manuscript, the scanner surfaces all of the important entities on the first pass — and then some. You'll get candidates you don't care about alongside the ones you do. The job is curation, not excavation: uncheck the noise, confirm the signal, and anything it missed you can promote inline as you keep writing.
Step four: the stats
This is the part that matters most for LitRPG authors, and it's the part that takes the most work.
You have a spreadsheet with columns like HP, MP, STR, DEX, and rows for each character. You have levels, skills, equipment slots, buffs, and a mental model of fights that applied damage. You've been maintaining this manually for chapters, and you know the moment you stop updating it — even for a week — the whole system starts drifting out of sync with the prose.
The core of AxiomWeaver's stat import is built: the system scans your manuscript for key:value patterns — "HP: 450/500", "STR: 42", pipe-separated stat lines — clusters them into schemas, and generates templates from what it finds. It also diffs sequential stat blocks for the same character across chapters, surfaces the changes, and asks you to review them before anything goes into the ledger.
I want to be honest that this part is still being refined. The detection works. The review flow works. What I'm still tweaking is the quality of the proposals — making sure the diffs are clean, the schema clustering is sensible, and the review step doesn't feel like a second job. For a 40-chapter manuscript it's manageable. For a 300-chapter serial, it's more work, and I want to get that down before I call it done.
What you get at the end — once you've worked through the review — is a living lexicon: your characters are real entities, their stats are bounded properties with current values, and the event ledger knows what changed in which chapter. The spreadsheet becomes redundant. But I'd rather tell you this part takes some elbow grease than oversell it as one click.
The spreadsheet is obsolete. The Google Doc of character notes is obsolete. The scattered Obsidian wiki is obsolete. Your prose is still your prose, but now it has a world behind it that doesn't need a second tool to maintain.
How long does this actually take
For a 100K-word manuscript with a typical LitRPG setup — say, 20 named characters, 40 chapters, and a spreadsheet of stats — the full migration takes under an hour for someone doing it for the first time. Most of that time is you reviewing the scanner's output and deciding what's actually important versus what was a one-off mention.
The import itself is a few minutes. The structure detection is fast — a second or two even for a large manuscript. The entity scan runs in the background while you go get coffee. The stat block schema inference takes about as long as it takes you to review the results and confirm.
One thing to keep in mind: the scanner can only surface what's actually on the page. If your weapons, armor, and inventory items are tracked in a spreadsheet but rarely described with stats in your prose, they won't appear in the scan. Getting a fully fleshed-out world — equipment with modifiers, inventory with properties — means either going back to add that detail to the prose, or building it out manually in AW. For some authors that's a weekend project. For others it's the whole point of the migration.
You'll keep finding things the scanner missed for a week afterward. That's normal. The system is designed to let you promote entities inline as you write — highlight a name, right-click, tag it as a character. The initial migration is the bulk of the work, and the long tail is measured in seconds per new thing.
The real migration cost
The real cost isn't the mechanical one. It's deciding, after you've run the import and the scanner, which of your old tools to retire.
The spreadsheet is the easy kill. Once a tool is computing stat values from events, there's nothing left for the spreadsheet to do. The scattered wiki goes next. The hardest one to let go of is Scrivener, because Scrivener is a genuinely good prose editor and the muscle memory runs deep — but if you're the kind of author who needs a narrative engine behind your prose, a prose editor that doesn't know about your world is a tool you've outgrown.
You don't have to kill them all at once. Keep the spreadsheet archived for a month if you need the safety net. The goal isn't to delete everything on day one — it's to stop maintaining things that now maintain themselves.
The alpha is almost ready. If you want to be first in line when it ships, get on the waitlist. Free during the alpha, no strings.
And if you want to know more about how the underlying system works, the stat tracking post is the place to start.