How the Project Is Organized

Welcome, builder. This manual is for the person who cloned this project and wants to add to it, extend it, or bend it into their own campaign. It assumes you can read the file types — this is about the intent behind them and the conventions that keep them coherent.

One engine, many shelves

The whole game is a reference table of JSON entries, each one a file of a known type, living in a folder that matches the type's plural name. A fighter.classes.json sits in the Classes folder; an entry's type tells the system what fields it may carry and how it renders. The folders are:

• Races — who a character is born as.
• Classes — what a character does.
• Spells — what magic can do.
• Monsters — what hides in the dark.
• Weapons, Equipment, Magic Items — what heroes carry.
• Proficiencies — what heroes are trained in.
• Characters — the sheets that tie all the above together.
• Abilities — discrete special powers (a backstab, a lay-on-hands, a turn undead) that classes and races pull in.
• Rules and documents — the prose that explains how it all reads at the table.

The books you are reading are the on-ramp for two audiences: the Player's Handbook teaches players, this one teaches builders. A rule the players need lives in the Player's Handbook; this book says how to extend it without breaking the boat.

The file-type config

Every type is defined at /file-types/<slug>.json. It names the type, whether it is JSON or markdown, how it is referenced, and — the part you will touch most — its schema (the fields an entry may carry) and its layout (how an entry renders when opened). You almost never edit every file of a type to change a field; you edit the type once, and every entry inherits it.

Two field kinds matter when you build:

• Editable fields hold the facts you type in — a name, a number, a description.
• Computed fields are derived by an expression from other fields (for example, a character's armour class figured from their armour, shield, and dexterity rather than typed by hand). You change their sources, never the computed value itself.

The through-line: everything points at something else

This system is a web of references, not a pile of loose entries. A character points at a race and classes; a class points at ability scores and proficiency groups; a spell states its class and school; a monster states its size, hit dice, and treasure. When you add content, the most important question is always what does this connect to, and does the connection hold? A fighter kit that says "use the fighter's hit dice and THAC0" only works if it says so in the way the system reads.

Conventions that keep it coherent

• Match the established register. The compendium already has a voice: plain, concrete, in the classic-referee style, no copyrighted text and no real-world marketing. Write entries that read like they belong in the same book as the ones beside them.
• Name files by their entry name. Orc.monsters.json, Long Sword.weapons.json. The slug is the entry's identity across the whole project.
• Fill what makes it usable. Every field that the table relies on at play — hit dice, armour class, cost, range, saving throw — should have a real value, not a placeholder. A spell with no casting time is a spell no one can cast.
• Keep the math honest. If an entry promises a bonus, express it in the number the system expects, so the computed fields and the referee both see it.

The golden rule

Every entry you add is a promise to the table that it can be used. A class that cannot be rolled into a character sheet, a monster with no hit dice, a spell that does not say what it does to whom — these are broken promises. Build each entry like the next session depends on it, because at some table it will.