The Rules, Documents & GM Layer

Not everything in this project is a JSON entry. A whole category of content lives as markdown prose — the rules, the referee's manuals, and the working documents that explain how the table actually runs and how a campaign is refereed. If the JSON types are the bones, this is the connective tissue and the living voice. It is easy to overlook, and it is as important as any monster or spell.

Three kinds of prose

The project distinguishes three markdown types, and the distinction is deliberate:

• Rules — the authoritative how-the-game-works text: ability scores, combat, saving throws, spellcasting, experience, movement, turning undead, and the rest. These are the rules the Player's Handbook teaches and the referee enforces. When you change a rule value (a saving throw table, a cost, a progression), it belongs here, in its own document, so there is one true copy of the truth.
• GM Instructions — the referee's private layer: adjudication, encounter building, NPC creation, running combat, treasure and rewards, dungeon and adventure design. This is the material players should not read — the craft of the man behind the curtain. Keep it separate from the public rules.
• Documents — working papers, guides, and setting text that sit outside the strict rules: creation guides, character generators, a campaign's pantheon and lore, implementation notes. The catch-all shelf for prose that is neither hard rule nor referee secret.

The split this project honors

The books you are reading follow the same logic as these files, and it is worth keeping the lines clean:

• A rule a player needs at the table lives in the Player's Handbook, and the detailed table behind it lives in the rules files.
• The secrets, rulings, and escalation a referee uses to run the game live in the GM Instructions files, which the GM agent loads during play. Never put a player-facing secret there... rather, never put a secretly-scaled secret in a player-facing handbook.
• The intent of a type and how to build entries lives in this Builder's Manual, not in the rules files.

How to write good prose entries

The same discipline that keeps JSON entries usable applies, turned to words:

• One subject per document, titled as the referee would look it up — "Saving Throws," "Encounter Building," not "Miscellaneous Rules v3." A referee reaching for a table mid-session should land on exactly what they need.
• Lookup rules want tables and lists; absorbed rules want prose. The saving throw tables are tables. The philosophy of the sphere system is prose. Most good documents mix both, but know which kind you are writing.
• Be the authority, not a reminder. A rules file is where the decision is settled. If two documents disagree, the referee is stuck inventing the answer they came to find. When you change a rule, find and update every place that leans on it — the value lives once, but the tables that quote it live in several.

Building for the referee's edge

When you scaffold a campaign, enrich the GM layer as deliberately as the public compendium. Stock the encounter, NPC, treasure, and adjudication files with your setting's actual decisions — what is found, what is threatened, how the world reacts. The referee carries your world at the table; every prepared answer you give them is one fewer invention they have to improvise live. A campaign with strong GM materials runs smoother, feels more lived-in, and gives the referee room to be creative in the ways that matter — over the unexpected, not over the basics.

Keeping the voice clean

Write rules prose in the same original, plain, referee-rulebook register as everything else in the project — no copyrighted text, no imported names, your own words throughout. The copyright rules that guard the JSON entries guard the markdown too; a rules document is just as much "content" as a monster stat block. If a sentence could be printed in a rulebook you paid for, because it is original prose doing its job, it belongs.