Manage, inspect, install, and implement work in an internal RPGJS v5 game project. Use when Codex needs to work on a codebase that should be an RPGJS v5 project, especially for gameplay features, maps, events, server/client code, `@rpgjs/*` dependencies, Tiled-based content, or `.ce` UI files. Also use when Codex must first verify whether the current project is actually an RPGJS project and, if not, read the RPGJS v5 quick start, install the project scaffold, and continue from that baseline.
Use this skill to work inside an RPGJS v5 project with the live documentation as source of truth. Start by proving that the current codebase is an RPGJS project, then load the relevant RPGJS and CanvasEngine docs with curl or an equivalent CLI fetcher before making changes.
Verify that the current workspace is an actual RPGJS project before doing anything else.
Inspect one or more package.json files and look for @rpgjs packages.
Useful commands:
rg -n '"@rpgjs|@rpgjs/' . --glob 'package.json'
rg --files . | rg 'package.json$'
If no project-local package.json uses @rpgjs/*, do not hand-build the project structure from memory.
Read the RPGJS v5 quick start first, then install the project from the documented flow.
Treat the quick start as mandatory before bootstrapping a missing project.
A fresh install already includes Tiled map editor integration and example maps, so use that scaffold as the baseline instead of assembling the project manually.
Use this URL:
https://v5.rpgjs.dev/guide/quick-start.md
Do not rely on memory for RPGJS v5 usage details. Fetch the documentation with curl or a similar CLI tool and read the relevant pages before installing or changing code.
Fetch the RPGJS documentation index:
curl -fsSL https://v5.rpgjs.dev/llms.txt
Use the llms.txt file as the table of contents. Extract the relevant Markdown links from it, then fetch the pages you need.
Example workflow:
curl -fsSL https://v5.rpgjs.dev/llms.txt -o /tmp/rpgjs-v5-llms.txt
rg -o 'https://[^ )]+\\.md' /tmp/rpgjs-v5-llms.txt
curl -fsSL https://v5.rpgjs.dev/guide/quick-start.md
If the llms.txt uses relative links, resolve them against https://v5.rpgjs.dev/.
Prefer reading only the pages needed for the task. Keep the fetched docs small and targeted.
.ce FilesTreat every .ce file as CanvasEngine code.
Before editing, creating, or explaining a .ce file, fetch the CanvasEngine documentation index:
curl -fsSL https://canvasengine.net/llms.txt
Then fetch the relevant Markdown pages referenced there. Do not invent CanvasEngine syntax from memory when the docs can be read directly.
If the task touches menus, HUDs, overlays, dialogs, title screens, or any file ending in .ce, load CanvasEngine docs first and then inspect nearby project components for local conventions.
For GUI styling, rely on the RPGJS UI CSS library instead of inventing an unrelated CSS system.
Fetch and read this documentation before changing GUI styles, classes, or layout rules:
curl -fsSL https://raw.githubusercontent.com/RSamaium/RPG-JS/refs/heads/v5/packages/ui-css/README.md
When the task affects GUI appearance, menus, HUDs, dialog boxes, notifications, shops, or title screens:
RPGJS relies on its dedicated RPG-oriented physics engine for collisions and related behavior.
Fetch and read this documentation before changing collisions, movement constraints, hitboxes, map blocking, or other physics-adjacent gameplay behavior:
curl -fsSL https://raw.githubusercontent.com/RSamaium/RPG-JS/refs/heads/v5/packages/physic/README.md
Do not guess collision behavior from generic game-engine habits. Verify it against the physics library docs first.
Client-server synchronization must go through synchronized player properties when the data represents state.
Fetch and read this guide before changing synchronized state, replicated player data, snapshot behavior, or cross-map persistence:
curl -fsSL https://v5.rpgjs.dev/guide/synchronization.md
Use player props for persistent state that must survive synchronization, snapshots, server restarts, or map transfers.
Do not use ad hoc side channels for durable gameplay state when props is the correct model.
Use map.broadcast(type, data) for ephemeral messages that should be broadcast on the current map without becoming saved state.
Use player.on(key, cb) to listen to client-sent socket data when that communication pattern is actually needed.
Follow this order:
package.json for @rpgjs/*.https://v5.rpgjs.dev/guide/quick-start.md.@rpgjs/* packages.https://v5.rpgjs.dev/llms.txt with curl or equivalent..ce files are involved, fetch https://canvasengine.net/llms.txt and the relevant CanvasEngine Markdown pages too.props as the default state model.When no RPGJS project exists yet:
curl or equivalent.If installation requires network access or package-manager writes outside the sandbox, request approval and then proceed with the install instead of stopping at advice.
In an RPGJS v5 project, expect some mix of these signals:
@rpgjs/* dependencies in package.jsonclient.ts, server.ts, and sometimes standalone.ts entrypointsconfig.client.* and config.server.* configuration files.ce filesTreat the existing project structure as the primary convention source after the docs.
Read the closest existing files before creating new gameplay objects, map logic, or UI components.
When working on gameplay or engine integration:
provideTiledMap or a custom provideLoadMapWhen working on .ce components:
.ce files for established patternsWhen working on GUI styles:
When working on collisions or movement rules:
When working on synchronized state:
props for state that must persist across maps, snapshots, or restartsmap.broadcast(...) for ephemeral, non-persistent map-wide messagesplayer.on(...) only for explicit client-to-server socket communicationRead source-map.md when you need the canonical doc URLs, the minimal fetch workflow, and the bootstrap rule for a missing project. Read architecture-notes.md when you need the core RPGJS v5 project model used by this repository.