HomeDeveloper docsHow to use AI to create an RPG system
How to use AI 3 min read

How to use AI to create an RPG system

Build sheets, item templates and automation as one installable package for the host version you actually use.

Replace bracketed values before sending the prompt. Give the assistant the relevant public files from the exact target release; use synthetic examples and keep credentials, private campaigns and proprietary material out of its context.

What you will build

Create a small original system with a character sheet, an NPC sheet and an empty gear template. Begin with a vertical slice: create a character, edit one numeric field, save it and reopen it.

Context to give the assistant

  • docs/en/modules.md: manifest, system descriptors, sheet lifecycle, combat providers and package installation.

  • docs/en/api.md and gravewright/modules/contracts/schemas/manifest.json: supported interfaces and accepted manifest fields.

  • The target release of the VTT and an explicit list of original or licensed material you may distribute.

Step by step

  1. Specify actor/item types, editable fields, validation and the target host release before asking for code.

  2. Ask the assistant to inspect the existing public contracts and produce the smallest working package.

  3. Review sheet loading, asynchronous saving, cancellation and conflict handling before adding rules.

  4. Add combat automation and translation catalogs inside that same system package only when the first sheet works.

  5. Build a ZIP with its manifest at the archive root; follow the documented signing/install process on a disposable host.

Copy and adapt this prompt

text
Repository: [local checkout or public repository]
Target host release: [installed/requested version; preserve it]
Task scope and authorization: [what may be changed/published]

Implement an original system named Example Expedition.
Deliver one installable system package containing character and NPC sheets, an empty gear item template, assets, translations and any automation. Do not create a separately installed Server Rules companion.
Start with name, a numeric stamina field and an inventory list. Define server-accepted data shapes using the target release contracts, rather than guessing manifest keys.
Use the supplied scoped module API, the documented sheet-save lifecycle and native modals. Handle cancellation, permission denial and version conflicts by refreshing state.
Keep game rules inside the package. Do not add system-name conditionals to the host, depend on a newer host version or bundle rulebook text/catalogs.
Show the exact package tree, manifest, code, license and installation steps; identify any requirement that the target public API cannot support.

Inspect the actual files and supported APIs before proposing code. Do not invent commands, fields, endpoints or package capabilities.
Use disposable test data and installation-local tools/caches. Explain any unsupported requirement and validate the result with the project’s real tools.
Deliver concrete files or editor steps, the checks performed and any unresolved limits.

How to validate

  • Create a character, change stamina, close while saving and reopen; confirm the saved value.

  • Open with GM, authorized player and read-only access; verify that denied writes are rejected by the server.

  • Make conflicting edits in two sessions; refresh and resolve the conflict without silently replacing the expected revision.

  • Install and remove the package in a disposable host; check cleanup and English fallback.

Ready when

A character can complete the create → edit → save → reopen flow on the requested host, and everything the system needs ships in one package.

Continue with the module reference, public API and testing guide.