Skip to main content

Developing with AI

PlayCanvas Engine applications are regular JavaScript or TypeScript projects, so any coding assistant that can read files, edit code, and run commands can work with them. Give the assistant the same Engine references and verification steps that a human contributor would use.

tip

If your code is stored in a PlayCanvas Editor project, use the VS Code Extension instead.

Choose an AI Client and Interface​

ClientInterfaceRecommended for
CursorCode editorInline changes, visual diff review, and an editor-first agent workflow
Claude CodeCLI, IDE integrations, and the Code tab in Claude DesktopRepository-wide work from a terminal, editor, or desktop workspace with visual diffs and app previews
OpenAI CodexCLI, IDE extension, and Codex in the ChatGPT desktop appLocal implementation and review from a terminal, editor, or desktop workspace with parallel chats and worktrees

The clients have different plans and supported platforms. Use their official documentation for current installation and availability details.

Provide Project Context​

Start the assistant in the repository root and install the project dependencies first. This gives it access to the PlayCanvas package, TypeScript declarations, scripts, and existing code patterns.

Add the project's real development commands and conventions to the client's repository instructions, such as AGENTS.md, CLAUDE.md, or Cursor Rules. Keep the instructions short and include:

  • The development, lint, test, and build commands
  • The source and generated directories
  • Browser support and performance constraints
  • The observable result required before a task is complete

Keep shared guidance in AGENTS.md where possible. Claude Code can reuse it through a CLAUDE.md containing only:

@AGENTS.md

Keep separate client files only for instructions that are genuinely client-specific.

Point the assistant to these PlayCanvas sources instead of asking it to recall APIs from memory:

Reuse Engine Code Before Writing It​

Before writing camera controls, character controllers, tweens, water, sky, post effects, or XR code, check the production Engine scripts available through playcanvas/scripts/*.

For an unfamiliar Engine feature, find a matching Engine Example and adapt its Engine setup and update logic. Treat examples as recipes to read and port, not modules to import.

Describe the Outcome and Its Proof​

Ask for one observable result, the constraints to preserve, and the checks that prove the result. For example:

Inspect this PlayCanvas Engine project before editing. Reuse its existing patterns and
check the installed PlayCanvas types or official API reference instead of guessing APIs.

Implement [outcome] without changing [constraints]. Run [test/build command], launch
the app, exercise [interaction], check the browser console, and summarize the diff and
the evidence that the result works.

Start with only the integrations needed for the task. Before adding a browser MCP server, check whether the selected desktop client's built-in browser or app preview already covers verification. Otherwise, choose one browser tool and add another only when it provides a missing capability.

  • Context7 MCP: Retrieve its indexed PlayCanvas Engine documentation when the client benefits from MCP-based lookup. Prefer the official AI-readable documentation above for authoritative content.
  • Playwright MCP: Launch and operate the application in a browser, exercise user flows, and capture screenshots.
  • Chrome DevTools MCP: Use instead of Playwright when console, network, or performance diagnosis is the main task.
  • PlayCanvas VS Code Extension: Expose Editor-managed text assets as local files for Cursor and other coding assistants.

Verify Every Change​

Source inspection is not proof of interactive behavior. Before accepting the result:

  1. Review the complete diff and reject unrelated changes.
  2. Run the project's focused tests, lint, and production build where available.
  3. Launch the application and check the browser console for new errors or warnings.
  4. Exercise the changed interaction with real browser input. Use screenshots for appearance and runtime queries for state, counts, positions, and other behavior; do not mutate state to manufacture evidence.
  5. For complex state, consider a development-only window.snapshot() that returns JSON-serializable data without exposing mutation methods.
  6. Fix and re-verify failed checks, test affected browsers or devices, and report anything that was not verified.

Official AI Tool Documentation​

OpenAI​

Anthropic​

Cursor​