Open RPG System Designer

Design original tabletop or digital RPG systems using optional SRD 5.1 or 5.2.1 mechanics as documented design references, not as a replacement rulebook.

Design original RPG systems, classes, and subsystems. Use an SRD to inspect documented mechanical patterns when that helps; do not recreate an SRD, adjudicate live D&D rules, or invent rights to excluded D&D material.

Choose the source route

1. Record one route in the project brief before drafting:
   • Invent original: no SRD mechanics are copied.
   • Adapt SRD 5.1: choose either OGL 1.0a or CC BY 4.0 and follow only that route's release requirements.
   • Adapt SRD 5.2.1: use CC BY 4.0. Do not describe it as available under OGL.
2. Use the official PDFs named in the SRD design map. Consult a PDF only when a design decision needs a source locator; do not paste spell lists, monster blocks, or rulebook chapters into project output.
3. Create a row in the provenance ledger for each SRD-derived element. Mark it copied, adapted, or inspired.

Design the system

1. Confirm platform, player count, genre, intended experience, complexity, campaign or session length, and personal or commercial use. State three to five design pillars and the core player loop.
2. Select the smallest engine that serves those pillars: resolution, character capabilities, consequences, opposition, recovery, advancement, and an adjudication rule.
3. Treat familiar SRD patterns as choices, not defaults: d20 plus modifier, roll-twice advantage, discrete action economy, hit points and rests, limited spell slots, and challenge-rating bands. State whether each pattern is reused, modified, combined, or rejected and why.
4. Add only needed subsystems: combat, exploration, social interaction, magic/powers, equipment, crafting, downtime, factions, or vehicles. For each, define player choice, inputs, procedure, outputs, failure state, edge cases, and tuning variables.
5. Write original rules text and examples. Show a normal result, a cost or complication where relevant, and a failure. Make terms, timing, and exceptions unambiguous.
6. Use the output templates for a one-pager, a full system document, or a ledger. Deliver the format requested by the user.

Content boundary

Before release, perform the checklist in the SRD design map. Do not treat trademarks, setting names, characters, logos, artwork, unique monsters, or source-excluded content as available merely because a similar game rule exists. Create original equivalents and names when content is excluded or uncertain.

Attribution and release

1. For CC BY material, use this attribution starter, then verify it against the applicable SRD preamble and add change information: This work includes material taken from the System Reference Document [VERSION] ("SRD [VERSION]") by Wizards of the Coast LLC and available at [OFFICIAL SRD URL]. The SRD [VERSION] is licensed under the Creative Commons Attribution 4.0 International License available at https://creativecommons.org/licenses/by/4.0/legalcode.
2. For OGL 1.0a material, use the document's required Section 15 notice and other license terms. Do not substitute the CC attribution block.
3. Keep the ledger separate from release-facing attribution. Flag public or commercial use with uncertain boundaries for qualified IP review; do not give legal advice.

Hand off specialist review

• Use game-design-core-loop-extractor when the repeatable player loop is unclear.
• Use game-design-fairness-frustration-audit for perceived fairness, difficulty, flow, and variance.
• Use game-design-failure-loop-audit for loss, recovery, retry, and post-failure motivation.
• Use game-design-attribution-audit when outcomes may feel arbitrary or players may blame hidden rules, luck, or the system.

Scope

Use this skill for original system design and revision. Use a dedicated research skill for source comparison, a legal professional for release decisions, and a dedicated rules-referee skill for live rules adjudication.