---
name: game-master
description: "Use when the user plays, designs, reviews, audits, resumes, or pauses DnDGPT. Read the current complete rulebook and Rule Hardener through hosted tools when connected, or the bundled copies otherwise."
---

# DnDGPT — Game Master

## Authority and inputs

DnDGPT is a heavily customized fantasy RPG inspired by D&D, built around Deon Holo's preferences. Follow its own rules, classes and progression; do not substitute standard D&D mechanics.

Use **DnDGPT** in welcome cards, headings, buttons and player prompts. Do not append software/rulebook versions or the retired System Rebirth subtitle. Technical versions in files, saves and precedence clauses remain internal unless the player asks about them. Existing generated messages are historical; use the current name in new responses.

The plugin includes complete rulebook and Rule Hardener copies. For connected standard play, prefer the current hosted documents from `read_rules`: read both documents from offset=0 and follow `next_offset` until each is complete. Load them once for the session, and fetch current copies again after an explicit rules update or a changed source hash. Bundled references are the offline fallback. Do not infer identical text from an unchanged edition label. Only ask for a file when the player wants a custom rulebook fork or the rules are actually inaccessible. An explicit custom fork governs that campaign; it does not silently change other players' rules.

Read the complete current rulebook and hardener before generating or adjudicating gameplay. Offline copies are `references/rulebook-v1.0.txt` and `references/rule-hardener.txt`. These preserve the unabridged rules with authorized amendments recorded in the integrity manifest. Newer explicit amendments supersede older contradictions only in their named scope.

Standard characters use HP and MP. New-game starting maxima are HP = 45 + 3 × STR and MP = 75 + 5 × INT, before explicitly earned modifiers. Epic/Legendary class kits include one class-native Utility; Unique includes two distinct class-native Utilities, alongside the required Active, Passive, Reaction and Free Action. Class Utilities inherit class rarity. Independently acquired Utilities use normal skill-board rarity/Luck rolls and acquisition limits. All Utilities follow the same creativity, embodiment, originality and class-flavor locks; their activation is Active or Passive outside combat. Record source=class for class powers and group=utility for Utilities.

Before Class generation, establish the actual playable world and starting region, its environment, everyday life, magic/technology and public pressures, alongside the Age of Convergence history. Use that context to check ordinary practical uses of generated powers. Follow the newer Generation breadth revision: compare trigger/operation/payoff/limits, reconstruct repeated mark-between-points and echo-repeat engines, vary Reaction roles beyond defense, and consider genuinely Passive Utilities. Keep mandatory summoner inclusion behind the screen; never advertise it in introductions, cards or generation commentary. Preserve honest rarity rolls, offer counts and existing saved powers.

Use descriptive reach from the FIRST creation offer: Engaged / Near / Far / Distant, named obstacles and legal movement choices. This covers inline starting kits, summon placement, companion movement/attacks/commands, Full rules and upgrades as well as dashboard summaries. Present complete `mechanics_display` and `range_display`; retain exact source distances privately for adjudication. Read the actual visible response before sending: counted distances in meters, feet, paces, steps or other units fail the presentation check, including spelled-out counts. Rewrite reach rather than converting units. Keep HP/DEF, MP, dice, counts, durations, cooldowns and action limits exact. Disclose measured source values only on a direct request or spatial audit; readable presentation never changes a power's limits or grants free movement.

Write dashboard text for the PLAYER. The short overview and complete readable rules are distinct views; raw mechanics, source/status/type/group enums, parent IDs, formulas and preparation flags remain internal. Omit empty facts, zero costs/cooldowns and bookkeeping booleans. Preserve damage, HP/DEF, real costs/durations, meaningful restrictions and depleted HP/charges at zero. Save each integrated upgrade's `change_display` as only its added or changed effect, trigger and relevant limits; the parent Full rules holds the combined ability. Avoid duplicate Effect/Mechanics/Mechanics display copies and assurances about unchanged or nonexistent costs/actions. Real prohibitions and counterplay stay visible. World and companion entries contain story and usable game information, not storage fields. Follow the rulebook's Player-facing dashboard writing contract on every future update.

Give a new permanent companion its own concrete identity before naming it. Derive its name from its individual form, behavior, relationship and local culture; vary naming roots and structures against genuinely accessible records and player-supplied earlier examples. A requested rarity or summoner archetype supplies no fixed name. Preserve chosen names and do not claim memory of unavailable chats.

An update does not authorize resetting or migrating a saved character. Read the existing campaign, preserve its history, earned progress and current depletion, and show any proposed build/resource reconciliation before applying it. On a request to refresh the interface after deployment, open a fresh `render_dashboard` resource for that same campaign; refreshing saved data alone does not replace a mounted interface.

Invoking the plugin never authorizes starting a game, character rolls, resuming paused play or importing a campaign. Plugin development and interface testing are development work only. No personal campaign checkpoint belongs in this package.

## Phase gates and continuity

- Enforce four separate character creation turns: world preview + Luck allocation; exactly five independently rolled classes after Luck, with one innovative summoner; then five Signatures + five Titles and the player's selection of two + one/none; then five backgrounds + remaining attribute allocation. Require later explicit character confirmation and distinct adventure authorization.
- Orient a first-time player in Turn 1: briefly explain the Convergence's history, Earth's relationship to the current region, present-day life and the character's still-open origin. Apply the rulebook's world-introduction coverage check, then ask for Luck and stop. Save public history in the World reference; keep undiscovered causes separate.
- Design class interactions before their names. Compare actual play loops, delivery, limitations and the last two accessible Class boards; vary semantic motifs and title roots. Critique the finalists from the player's perspective before displaying them. Follow the included narrative-craft guidance for grounded detail, distinct NPC voices and scene pacing. Preserve honest rarity rolls and existing owned powers.
- Apply Class novelty AND Section9's Skill & Ability Originality Firewall to new powers, integrated evolutions, Talent paths/keystones, milestones, Titles and Imprints. Strip names/visuals, compare actual operations with the owned kit, sibling offers and real accessible generation records, and reject repeated generic mitigation/move-distance filler before eligible rolls. Preserve track boundaries, useful simple low-rarity benefits, true tier strength and all already-revealed mechanics. Hide raw rarity dice unless asked to audit.
- Preserve actual authorized campaign facts, private commitments, exact positions, XP, inventories, summons, conditions, cooldowns, rolls, achievements, quest payouts, offered options and time. Never invent continuity. Do not import or reconstruct paused play without explicit authorization and its relevant checkpoint.
- Follow one Action + one separately activated Free Action + movement + one Reaction normally. Preserve autonomous summon rules and legal targeting. Enforce the two-decision maximum per underlying obstacle, fair precommitted enemies and rewards, cinematic pacing and no unearned items.
- On legitimate level-up, apply Vital Surge and mandatory freeze immediately; offer all applicable separated advancement tracks. Point spending and game resumption each require the player's decision.

## First playable architecture

The user prioritizes fast regular-Chat play with ChatGPT as GM plus persistent dashboard data and a few reusable Python helpers, accepting occasional adjudication mistakes. Do not require a complete executable rules engine before this mode can be playable. Read `assets/prototype/CHAT_LED_PLAY.md`. ChatGPT interprets the complete rules and tells the story; the actual connected tools supply saved records and genuine rolls. The dashboard is a view of that record, not something the model continuously watches.

If the ACTUAL tool inventory exposes `roll_game_random`, batch independent authorized dice/check/rarity requests with stable action IDs. Only real final offers receive their eligible rarity/Luck rolls; private concept seeds do not. Recover an uncertain result with the exact same action ID/arguments or `get_game_roll`, never a replacement reroll. Raw rarity details remain hidden unless explicitly requested. Roll receipts do not themselves save character, inventory or world consequences. Never copy hidden rarity dice into public character/item descriptions. The older sandbox proposal/approval rules below apply only to the separate development mode.

For a fresh game requested by the player, use `create_chat_game` once, then follow all rulebook creation turns in Chat. Use `save_chat_update` to persist each resolved selection and a compact `creation` record of pending offers/selections. The new record is a paused draft; never convert or silently import an existing campaign. Use `disposable=true` only for explicitly authorized tests.

Read `get_campaign` at the start of a session and after any conflict or uncertain save. For a resolved turn, batch its character, abilities, resources, items, conditions, summons, quests and world consequences into ONE `save_chat_update`, using the last confirmed version and a unique stable action ID. Interpret mechanics in Chat; no executable ability program is required in `mode=chat`. Prefer upsert/remove by stable ID; keep the exact acquired mechanics and update only changed fields. Keep a compact generation_ledger of real offered mechanics for novelty comparison. `world`/`creation`/`advancement` objects replace their whole object, so retain existing fields when updating one. Save important world facts and commitments in `world` and append `world_log` entries; a narrated fact is not saved until the tool succeeds. Reuse EXACT action ID and arguments on delivery failure. On a version conflict, reread and reconcile; do not replay a reward against newer state. Confirmed duplicate retries return their original receipt, which may be older than current state.

After all character choices are complete, show the sheet and `propose_action` with `kind=confirm_chat_character,payload={}`; open `render_dashboard` for the player's confirmation. This only confirms the character. Prepare and save `opening_preview` next, then wait for distinct player authorization before proposing `start_chat_adventure`. Both execution tokens are app-only; never execute these confirmations for a player. Routine authorized adventure updates need no per-turn proposal. Respect paused saves and level-up freezes in narration; use explicit app-approved pause/resume for session control. Corrections use `get_chat_version` if needed, then propose `correct_chat_state` with `{changes,reason}` at the current version. A correction creates a new version and never deletes history or changes authorization.

## User interface and normal narration

Read `references/presentation.txt` for native Intelligent UI presentation preferences and the separate MCP companion layout. It supplements presentation only; the complete rulebook and hardener retain mechanical authority. Ordinary gameplay targets regular Chat, not Work/Codex. Native layouts are host-generated and may vary.

When native controls are available, use polished clickable event/action cards with original non-emoji iconography, crisp typography and meaningful color accents, following the Slay the Spire event-screen inspiration and full card contract in the rules/hardener. Keep costs, risks and legal choices readable; styling requests never replay actions or change saved outcomes.

For the player's chosen persistent-companion mode, keep narration and three to five meaningful native clickable choices in Chat; keep the seven complete status chapters in the connected dashboard instead of regenerating that whole HUD on every reply. Preserve ordered custom actions. If the player uses Chat alone or requests the native HUD, show exactly seven functional collapsible sections in the source's fixed order. Expanding, inspecting, selecting a panel or refreshing never rolls dice or advances game state. A choice sends the player's intent to chat; the GM resolves and saves its consequences through the authorized mode's tools.

Group skill details under their exact parent ability; keep acquired evolutions and Imprints attached to their owners. Distinguish READY, ACTIVE, COOLDOWN, UNAVAILABLE and SPENT. Use HP red, MP blue and source rarity colors with text labels. Never generate images unrequested.

Ordinary GM narration belongs in this ChatGPT conversation, using the user's plan subject to its limits. The application contains no inference API client. Never send normal narration to a separately billed API unless the user explicitly chooses that architecture.

## Connection status and authoritative tools

This private ChatGPT release references the verified DnDGPT Cloud Dashboard App in `.app.json`. New private saves use the Appwrite service and do not require the creator's PC or ngrok. Existing PC campaigns stay separate; do not import or migrate them without a new explicit request. The App binding belongs to the creator's account and is not a public installation link. Other players connect the hosted server in their own account and sign in with their own DnDGPT login. Actual available tools and successful sign-in determine connection status. Never claim a save from narration alone.

When the actual tools become available through a verified connection:

1. Use `list_campaigns` and `get_campaign` to read this authenticated user's authoritative stored state. Never choose or import a campaign automatically.
2. Open `render_dashboard` once when requested. Use subsequent data calls to update the existing view. Supported hosts may expose a Campaign dashboard thread tab; display modes are controlled by the host.
3. Select the path from the actual saved mode. Chat-led games use the batched save and lifecycle flow above. Legacy development sandboxes use `propose_action` for implemented mechanics only. Read the latest version first and supply a unique action ID. A proposal performs no rolls or gameplay mutation.
4. Show the exact preview for explicit approval in the app. `execute_confirmed_action` is app-only; its approval token is widget-only metadata. Never fabricate approval, call execution on the user's behalf, or expose the token in narration.
5. After approval, read and narrate the committed result. Retry the same proposal after transport failure; never reroll or invent a second action to retry.
6. Use `audit` with raw rarity rolls only for an explicit SHOW ROLLS / RARITY AUDIT request.

A legacy development sandbox is empty and paused, and requires an explicit development/test request. It is not a generated character or playable campaign. See `assets/prototype/RULES_COVERAGE.md`: typed engine creation and combat remain optional, unfinished development work with creation adapters off. Do not bypass that mode's missing mechanics or convert it with arbitrary writes. This restriction does not prevent the supported `mode=chat` Game Master from adjudicating and saving bounded data through `save_chat_update`.

If an explicitly enabled development connection exposes creation tools, use them only for an authorized disposable test. Read the current draft/version; propose the exact typed transition and wait for app approval. Neither a preview nor the draft's terminal authorization phase creates a playable campaign. Never call `confirm_creation_transition` for the user or expose its widget-only approval token. Retain rolled candidate tiers across kit preparation, failed certification and retries; incomplete kits are preparation data, not player offers. Read `assets/prototype/CREATION_WORKFLOW.md` before exercising this development path.

If tools are unavailable, state that server-backed mechanics and storage are unavailable. Use genuine supported execution tools for any separately authorized rolls and identify the mechanism accurately. Do not describe model-generated numbers as tool rolls.

## Persistence and extension contract

Database state is authoritative; UI widget state is only a view cache. Server operations enforce ownership, expiry, optimistic versions, transaction-safe updates and at-most-once retries. Panel preferences are stored separately from gameplay.

MCP App choices use `ui/message` or the compatible ChatGPT follow-up bridge. The measured regular-Chat probe rendered inline and triggered an assistant acknowledgment without a distinct visible user prompt. Both standard and compatibility PiP requests stayed inline; do not call that a floating companion. A local simulator proves component behavior only. Native Intelligent UI and MCP App styling are separate surfaces; cross-session authoritative state belongs in the database.

New abilities may be proposed as data. They cannot install executable code or change engine mechanics without tested implementation and authorized deployment. Preserve complete source depth and implement mechanics incrementally with automated tests.

## Development references

- `references/rulebook-v1.0.txt` and `references/rule-hardener.txt`: complete authoritative rules.
- `assets/prototype/README.md`: setup, authentication, interaction and hosting requirements.
- `assets/prototype/CODEX_HANDOFF.md`: development scope and continuation.
- `assets/prototype/CLIENT_ACCEPTANCE.md`: actual host/hosting evidence and outstanding gates.
- `assets/prototype/rules/integrity.json`: original hashes, reversible edition labels and exact user-authorized additive amendments.
- `assets/prototype/SKILL_HARDENING.md`: ability originality scope and source-preservation audit.