An OpenClaw-native AI Game Master workspace designed to run module-based fifth-edition (5E) compatible play over a Discord channel. The repository ships the prompt stack, memory model, skill system, shipping modules, deploy script, and validation tooling.
There is no standalone Discord bot in this repo. OpenClaw remains the runtime for Discord message handling and model inference.
The unit of play is a module — a bounded, pre-authored scenario with a beginning, scene-by-scene structure, and one or more resolution paths. Each module declares whether it accepts existing PCs, requires fresh characters, or supports both. PCs persist across modules in a table-level character pool, so the same heroes can run module after module if the group wants.
This is a deliberate shift from the long-running open campaign model. Inspired by how published modules (and Call of Cthulhu scenarios) are actually run at the table: closed stories, predictable length, the GM running the book rather than building a sandbox.
The agent uses a four-layer context model with two memory layers (persistent and module-scoped):
| Layer | Purpose | Files |
|---|---|---|
| L0 | Always-loaded identity and routing | workspace/AGENTS.md, workspace/SOUL.md, workspace/ROUTING.md |
| L1 | Table-level state (persistent across modules) | workspace/memory/table.md, workspace/memory/characters/*.md, workspace/memory/archive/*.md |
| L1 | Active module state (current play) | workspace/memory/active-module.md, workspace/memory/modules/[id]/ |
| L2 | Specialist behaviors | workspace/skills/*/SKILL.md |
| L3 | Rolling conversation window | Managed by OpenClaw runtime |
Memory files are the source of truth. If the GM needs continuity, it must read or write the relevant file.
game-master/
├── README.md
├── deploy.sh
├── docs/
│ └── testing/
│ ├── 2026-03-17-phase1-acceptance-transcripts.md
│ └── 2026-03-17-phase1-mvp-checklist.md
├── scripts/
│ └── skills/
│ ├── validate-skills.sh
│ ├── validate_skills.py
│ └── smoke_test_loader.py
└── workspace/
├── AGENTS.md
├── SOUL.md
├── ROUTING.md
├── BOOTSTRAP.md # Table & module init state machine
├── TOOLS.md
├── RULEBOOK.md
├── memory/
│ ├── table.md # Table-level prefs, PC pool index, lifetime stats
│ ├── active-module.md # Pointer to current module + resume anchor
│ ├── analytics.md
│ ├── user-tier.md
│ ├── scene-cache.md
│ ├── characters/_template.md # PC pool (persistent across modules)
│ ├── npcs/_template.md # Reserved (legacy template)
│ ├── locations/_template.md # Reserved (legacy template)
│ ├── archive/_template.md # Completed-module records
│ └── modules/_template/ # Per-module instance state templates
│ ├── flags.md
│ ├── npc-state.md
│ └── session-log/_template.md
├── modules/ # Shipping modules (read-only at runtime)
│ ├── _template/
│ ├── tutorial/
│ └── shadows-of-thornwall/
└── skills/
├── SKILLS_INDEX.md
├── LOADING_RULES.md
├── module-runner/ # Drives scene progression and gentle railroad
├── memory-keeper/
├── safety-boundaries/
├── dnd-rules/
├── combat-tracker/
├── dice-roller/
├── session-manager/
├── world-builder/
├── discord-ux/
├── character-creator/
├── scene-artist/
├── subscription-gate/
└── analytics/
Two modules ship today:
workspace/modules/tutorial/MODULE.md— single-scene smoke test, level 1, ~30 minutes. Use this to verify wiring on first deploy.workspace/modules/shadows-of-thornwall/MODULE.md— gothic mystery in a frontier town. Levels 1-3, 3-5 sessions. Three resolution paths (combat, diplomacy/liberation, rebinding).
Authoring a new module: copy workspace/modules/_template/, fill in
MODULE.md frontmatter (id, level_range, accepts, entry_scene,
exit_scenes), author scene files under scenes/, write rails.md for
gentle-railroad guidance, optionally add NPCs/locations/encounters.
Run bash scripts/skills/validate-skills.sh to verify the schema.
13 skills, loaded on-demand:
safety-boundaries(priority 1)module-runner(priority 2 — drives scene progression in active modules)session-managercombat-trackerdnd-rulesdice-rollerworld-buildermemory-keeperdiscord-uxanalyticscharacter-creatorscene-artistsubscription-gate
See workspace/skills/SKILLS_INDEX.md for trigger intent and
workspace/skills/LOADING_RULES.md for the loading matrix (11
intents, hard cap of 5 skills per turn).
- OpenClaw installed and running
- A
trpg-gmagent configured in your OpenClaw setup - A Discord channel already bound to that OpenClaw agent
git clone https://github.com/yichenhuang2000/game-master.git
cd game-master
./deploy.sh ~/.openclaw/trpg-workspacedeploy.sh copies:
- deployable workspace files from
workspace/ - modules from
workspace/modules/ - skill directories and top-level skill docs
- reference templates for characters, archive, module instance state, tier, analytics, and scene cache
The script does not overwrite existing live memory files such as
memory/table.md, memory/active-module.md, memory/characters/*.md,
memory/archive/*.md, or anything under memory/modules/[id]/.
Existing installs that pre-date the module architecture will see their
.campaign-initialized sentinel migrated to .table-initialized on
the first redeploy. Their legacy memory/campaign.md,
memory/quests.md, and memory/session-log/ files are preserved
untouched.
On a fresh workspace:
- OpenClaw sees
BOOTSTRAP.md(no.table-initializedsentinel) - Cold start — the GM walks through table naming, preferences,
and writes
memory/table.md - Module selection — the GM lists modules from
workspace/modules/and the players pick - Module init —
memory/active-module.mdis created, instance state is seeded undermemory/modules/[id]/ - Session 1 —
module-runnertakes over and drives scene progression
On subsequent runs, session-manager reads memory/active-module.md
to determine resume vs. module selection.
Run the checks with:
bash scripts/skills/validate-skills.shThis validates:
- required skills, their structure, references, and loading rules
- module schema (MODULE.md frontmatter + required body sections, module id matches directory name)
- required memory and template files
- BOOTSTRAP.md and deploy.sh sanity strings
- loader matrix coverage and hard-cap consistency
- 5E SRD (System Reference Document 5.1) content only — other systems are out of scope for now, though the architecture does not preclude later support
- Solo-first assumptions are baked into the subscription and resume stubs
- Scene art and analytics are contract-first with file-backed fallbacks
- There is no production billing provider in this repo
- There is no standalone bot runtime in this repo
- Keep shipping content inside
workspace/so deploy behavior stays obvious - Use
workspace/memory/*.mdas the source of truth for gameplay state; modules underworkspace/modules/are read-only at runtime - New shipping content goes under
workspace/modules/
This repository contains two kinds of material under two licenses:
- Original work — the prompts, skills, modules, memory templates, deploy
script, and tooling authored for this project — is licensed under the
MIT License (see
LICENSE). - SRD-derived rules content — the 5E rules references under
workspace/skills/dnd-rules/references/and the SRD game mechanics used throughout — is taken from the System Reference Document 5.1 and used under the Creative Commons Attribution 4.0 International License (CC BY 4.0). SeeNOTICE.mdfor the required attribution.
This project is an unofficial, fan-made tool. It is not affiliated with, endorsed, sponsored, or approved by Wizards of the Coast LLC. Dungeons & Dragons and D&D are trademarks of Wizards of the Coast. This project uses only SRD 5.1 content and is compatible with the fifth edition of the world's most popular roleplaying game.