{"owner":"BabylonJS","repo":"Babylon.js","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":[".github/copilot-instructions.md"],"files":{".github/copilot-instructions.md":"# Babylon.js Copilot Instructions\r\n\r\nExtensive documentation for Babylon.js can be found at <https://doc.babylonjs.com/>.\r\n\r\n## Product identity\r\n\r\nBabylon.js is not a single product but a platform containing an API published via NPM and several supporting tools. The tools include deployed web-based apps such as the Playground, Sandbox, and editors: Node Material Editor (NME), GUI Editor, Node Geometry Editor (NGE), Node Render Graph Editor (NRGE), Smart Filters Editor (SFE), Node Particle Editor (NPE), and the Viewer.\r\n\r\nWhen creating HTML mocks, match the look and feel of the tool's existing UI. Don't guess at what the tool looks like — read the UI code and create a close approximation.\r\n\r\n## Product and Architecture Reference\r\n\r\nFor a complete inventory of all public `@babylonjs` npm packages and their corresponding implementation packages, see [product-inventory.md](product-inventory.md).\r\n\r\nFor detailed architecture documentation of each product, see the files in [architecture/](architecture/)\r\n\r\n## Instruction Files\r\n\r\nFor a full index of all coding practice, review, and workflow instruction files, see [instructions/index.md](instructions/index.md).\r\n\r\n## Feature documentation\r\n\r\nFeature documentation lives in `/specs/`. Each feature has its own folder named `<feature-name>/` containing `goals.md`, `requirements.md`, and `architecture.md` as applicable. Within that folder, a `.temp/` directory holds files that don't need to be kept after development is complete (e.g., `mocks.html`, `mocks.context.md`, `implementation_plan/`).\r\n\r\n## Tree-Shaking Architecture\r\n\r\nThe `@babylonjs/core`, `@babylonjs/gui`, `@babylonjs/loaders`, and `@babylonjs/serializers` packages use a three-file split only for modules that need a side-effect-free implementation plus a backward-compatible side-effect wrapper:\r\n\r\n- **`foo.pure.ts`** — Pure implementation and idempotent registration function. Imports only from other pure-safe modules. No top-level side effects.\r\n- **`foo.ts`** — Thin wrapper that re-exports from `.pure.ts`, re-exports `.types.ts` when present, and calls the registration function.\r\n- **`foo.types.ts`** — `declare module` augmentations only when the module augments another class or namespace.\r\n\r\nDo not create `.pure.ts` plus an empty wrapper for side-effect-free modules. If a module has no runtime side effects or registration work, keep it as a single plain `.ts` file. Generated shader files under `Shaders/`, `ShadersWGSL/`, and `ShadersInclude/` are generated side-effect modules; never create `.pure.ts` variants for them. The committed side-effects manifest is sharded per package under `scripts/treeshaking/side-effects-manifest/{core,gui,loaders,serializers}/`; generated shader `shader-store-write` diagnostics intentionally use stable `line: 0` entries so regenerated shader text does not cause manifest drift. The tree-shaking tooling is parameterized by `--package <name>` (default `core`); CI validates every package via `--all-packages` in `check:treeshaking` and `check:side-effects-sync`. When modifying an existing split module, edit the `.pure.ts` file for logic. Side effects (RegisterClass, prototype augmentations, static API reattachment, scene-loader/glTF-extension registration, generated shader imports, etc.) are owned by the registration function in `.pure.ts` and invoked by the wrapper. See [instructions/tree-shaking.instructions.md](instructions/tree-shaking.instructions.md) for the full guide.\r\n\r\n## Public APIs\r\n\r\nAll public APIs exported from a package's root index file (except those prefixed with an underscore) are considered public APIs.\r\n\r\n## Quality commands\r\n\r\nRun these commands to verify code quality. All must pass before committing.\r\n\r\n- **Format**: `npm run format:check`\r\n- **Check (lint + typecheck + ratchets)**: `npm run lint:check`\r\n- **Unit tests**: `npm run test:unit`\r\n\r\n## Code review\r\n\r\nWhen reviewing a PR or reviewing changes on the current branch, use the `code-review` skill. It performs a detailed review against all repo coding practices, flags issues by severity, and fixes them.\r\n"}}