Magic System
Most writers who work with structured magic or power systems end up with the same setup. A document somewhere — maybe a wiki page, maybe a Google Doc — that lists the rules of the system. The rules are clear when you write them. Then you start drafting. Chapter three introduces a new character with a twist on the rules. Chapter eight uses an ability you hadn’t fully specified. By chapter fifteen, you have three different unreconciled versions of the system in your manuscript, none of them match the original document, and you’re not entirely sure which version is canon. This is the default outcome, and it’s the default outcome because the rules live in a passive reference document instead of a system that knows your fiction.
The Magic System module is an active version of that reference document.
It holds your rules in a structured form — stats, formulas, abilities, resources, modifiers, templates. It attaches those rules to the entries in your Legendry so that characters, items, and locations can have actual stat blocks with computed values. It runs probability analysis on the dice portions of your system, if you have dice. And it ships with an agent called RulesLawyer that reads your prose and flags places where your writing contradicts your own rules. It is, in a real sense, the module that turns “my magic system” from a rhetorical document into a living contract your fiction has to honor.
Who this is for
Section titled “Who this is for”Three audiences, all valid.
Fantasy and speculative fiction authors with hard magic systems. If your system has specific costs, limits, and rules — Sanderson-style — the Magic System module is where those rules get enforced across your whole project. You define them once and they stay consistent across every chapter, every character, and every spell you write.
Fantasy and speculative fiction authors with soft magic systems. Softer systems don’t have explicit numeric constraints, but they still have rules — “no bringing back the dead,” “prophecy can be read but not caused,” “a spell costs the caster something personal.” You can represent those as narrative-flavored abilities, prerequisites, and modifiers. The RulesLawyer agent works on prose consistency, not just numbers, so a soft system can still catch contradictions.
TTRPG designers. Ishvana was built by a creator who also writes TTRPG setting books (Welcome to Tikor is the flagship), and the Magic System module doubles as a game design tool. Import a preset ruleset, customize it, test it with probability analysis, build stat blocks for every NPC in your campaign setting, and export the whole thing. The TTRPG usage guide walks through the specific workflow.
If you’re writing fiction without any structured rules at all — a literary novel, a contemporary drama, a romance with no speculative elements — you won’t use this module. That’s fine. Desktop doesn’t weight it heavily by default. Turn the Lore Coverage weight down and ignore it.
What’s in this section
Section titled “What’s in this section”How the pieces fit together
Section titled “How the pieces fit together”The Magic System module is several connected features, not one monolithic thing. Here’s how they stack.
At the bottom is the ruleset. Every ruleset is a named container — “My Fantasy System,” “TTRPG Core Rules,” “Side Project Mechanics.” A project can have many of them but only one is active at a time. The active ruleset is the one that gets applied to stat blocks, checked by RulesLawyer, and used by the probability analyzer.
Inside each ruleset are its stats (the numbers), formulas (how stats combine into derived values), resources (trackable pools like HP or mana), abilities (the things a character can do), and modifiers (passive bonuses that change stat values). Plus a few organizational pieces — categories for grouping, templates for deciding which stats apply to which entry types, dice outcome bands for categorical dice interpretation, and DC tiers for naming difficulty thresholds.
Above the ruleset are stat blocks. A stat block is what you get when you apply a ruleset template to a specific lore entry. A character gets a stat block that has the stats, formulas, and abilities defined by the ruleset, filled in with that character’s specific values. Stat blocks live on the lore entry — when you open a character in the Legendry, their stat block is there on the entry detail panel.
And above stat blocks are the analysis tools. Probability analysis reads the ruleset’s dice notation and computes distributions. RulesLawyer reads your prose and the ruleset together and flags contradictions. The Character Sheet Designer generates printable sheets from the stat block definitions.
Each piece works on its own, but the full power comes from using them together — a ruleset feeding stat blocks feeding a character sheet feeding the RulesLawyer that runs on your manuscript.
The “agnostic” part
Section titled “The “agnostic” part”A note on why this module is called Magic System and not Mechanics or Rules Engine or Stats.
“Magic System” is the word fiction writers actually use. When a fantasy author talks about their book at a convention, they say “my magic system” — not “my mechanics.” When a worldbuilder drafts a setting book, they write a “magic system” chapter — not a “rules engine” chapter. The word is borrowed from hard-magic discussions but has expanded to cover any rules-based structure in speculative fiction, the same way “plot” has expanded beyond its original meaning.
The module works for fiction that doesn’t even have magic in it. Superhero power systems, cultivation tiers, cyberware load, sanctioned abilities in a legal drama, stat tracking in a sports novel — all of these are structured systems of rules, and all of them fit the same shape as magic. The name “Magic System” is the clearest way to signal what the module is for to the audience most likely to use it, even if “magic” in the literal sense is only one of the use cases.
TTRPG authors who prefer “Mechanics” or “Rules” can keep using those words when they write about their system. The UI won’t change its vocabulary on them. The module is agnostic about which word the user picks for their own system — it just needs to hold the rules, whatever you call them.