How the SRD Is Organized
Everything in the project is either a rule (prose, read once and internalised) or a compendium entry (structured data, looked up on demand). The folder tree mirrors the SRD's chapter order, and each folder is either mostly rules, mostly entries, or a mix with an overview rule at the top explaining the entries below it.
The folder map
| Folder | Holds | Pattern |
|---|---|---|
/Introduction/ | Front matter — licensing, dice, orientation | Rules only |
/Characters/ | Character sheets, plus a couple of character-adjacent rules | Mostly character entries |
/Skills/ | How skills work, situational rules, then two subfolders | Rules + entries |
/Skills/Standard Skills/ | The skills every character has | skill entries only |
/Skills/Professional Skills/ | Trained skills, plus an overview rule | skill entries + 1 overview rule |
/Game System/ | Core mechanics: healing, falling, fatigue, luck, hit locations, and more | Rules only |
/Combat/ | The combat chapter, split into one rule file per topic | Rules only |
/Magic and Powers/ | How magic and superpowers work, plus two subfolders | Rules + entries |
/Magic and Powers/Spells/ | Individual folk-magic spells | spell entries only |
/Magic and Powers/Superpowers/ | Individual superhero powers | power entries only |
/Vehicles/ | Vehicle rules, plus a sample folder | Rules + entries |
/Vehicles/Sample Vehicles/ | Worked vehicle examples | vehicle entries only |
/Creatures/ | Creature abilities, an overview, and the bestiary | Rules + entries |
/Equipment/ | Weapons, armor, gear, consumables | equipment entries only |
/Locations/ | Places a Games Master can drop into a session | location entries |
/Game Starts/ | Ready-made session openings | game-start entries |
/GM Instructions/ | How the GM agent should run this project | gm-instructions entries |
The pattern to copy: when a folder's entries need a shared introduction (what a Creature Ability is, what Professional Skills are for, how vehicles are abstracted), that introduction is a rule file sitting in the same folder as the entries it introduces, not a chapter in the handbook and not folded into every entry's description field. Add a new kind of entry (a new folder of spells, a new folder of vehicles) the same way: one overview rule, then the entries.
Two mental models, not one
Resist the urge to make everything a schema. Ask which model the content actually needs:
- If a table will look this up mid-session and expects consistent fields — a weapon's damage, a skill's base value, a spell's traits — it is a compendium entry. Structure pays for itself because it's compared and rendered the same way every time.
- If the content is explained once and referred to by name afterward — how Fumbles work, what a Combat Style Trait is, what ORC licensing requires — it is a rule. Forcing prose into fields fights the reader for no benefit.
A few types sit deliberately in between: creature and vehicle use one schema field (statBlock) that holds a large, loosely formatted block of stats and abilities rather than dozens of numbered properties, because creatures and vehicles vary too much in shape to force into a rigid grid. That is covered in full in Creatures and Vehicles.
What links to what
The dependency chain a new entry usually plugs into:
Characteristics (fixed, on Character)
│
▼
Skills (skill.json) ──── referenced by ────▶ Character.skills
│
▼
Spells / Powers (spell.json / power.json) ─ referenced by ─▶ Character.powers
│
Equipment (equipment.json) ──── referenced by ────▶ Character.inventory
A character file's skills, powers, and inventory arrays are reference fields, not free text — see Characters for what that means when you populate them. Creatures and vehicles do not plug into this chain the same way: they carry their full stat block as text rather than referencing skill or equipment files, because a creature's "Bite" attack or a vehicle's weapon rarely maps cleanly onto a player-facing skill.
Read the chapter matching whatever you are about to add next.