Two plugins, each shipping inside its own npm package. The plugin namespace matches the plugin name; skills inside fire by description match.

ecs-framework — API reference and authoring

Ships in: @babylonjsmarket/ecs

ecs-framework:ecs-authoring

Triggers when: Claude is writing or reviewing code that imports from @babylonjsmarket/ecs. Also when you ask "how does X work" about a Component, System, World, EventBus, or SceneLoader method.

What it carries:

• The canonical public surface of every class — World, Entity, Component, System, EventBus, SceneLoader — derived from the source files at packages/ecs/src/. Not training data.
• An anti-pattern list of plausible-looking method names that don't exist but show up in unguided generation:
  • entity.getOrThrow(C) → use entity.get(C)!
  • entity.getComponent(C) / entity.hasComponent(C) → use entity.get(C) / entity.has(C)
  • world.eventBus → use world.getEventBus() (the field is protected)
  • onAttachOverride / onDetachOverride on a System → those are Component hooks; Systems use onInitialize / onShutdown
  • this.entities.find(...) → this.entities is a Set, not an Array; use world.getEntity(id) for O(1) lookup
• The renderer-adapter subpaths (@babylonjsmarket/ecs/babylon, /three, /testing) and when each is appropriate.
• The scene JSON format used by SceneLoader.

Effect on generated code: the anti-patterns above are exactly what Claude tends to invent without the skill. With it loaded, they get caught before the first save.

arcade-ecs — Arcade game scaffolding

Ships in: @babylonjsmarket/arcade

arcade-ecs:arcade-scaffold

Triggers when: you ask to scaffold a new arcade-style game, name a classic arcade title to clone (breakout, snake, frogger, …), or want to drop a known component into an existing arcade project.

What it does:

1. Routes "new project" intent to the package's own CLI:

   npx @babylonjsmarket/arcade init <project-name>
   

   …picking the right template (basic, first-person, top-down, side-scroller) based on the user's description.
2. Routes "add a component" intent to:

   npx @babylonjsmarket/arcade add <ComponentName>
   

   for any component shipped in @babylonjsmarket/arcade — MeshPrimitive, Movement, KeyboardMover, PlayerInput, ArcCamera, CameraFollow, DirectionalLight, HemisphericLight, Physics, Score, Scoreboard, Shadow, Skybox, Animation, Mesh.
3. Walks the user through the post-scaffold steps (npm install, npm run dev, open the printed URL).

Conventions baked in:

• Components stay pure data; renderer calls happen in the adapter or a System, never in a Component constructor.
• Systems use query: ISystemQuery plus onInitialize/onShutdown/onUpdate.
• Inter-system communication via EventBus, not direct references.
• Scene JSON is the source of truth for what entities exist at start-of-scene.

How they reinforce each other

ecs-framework:ecs-authoring keeps generated code honest against the API surface. arcade-ecs:arcade-scaffold produces new code through the package's own CLI, which uses the same conventions. So whether the code came from the scaffolder or was hand-written by Claude, the same authoring skill verifies it.

When neither fires

Both skills are scoped narrowly to keep auto-invocation noise low. If you're working on the website, on a CLI tool unrelated to the ECS, or on something that doesn't involve @babylonjsmarket/ecs or @babylonjsmarket/arcade, neither fires. That's intentional.

To force-invoke explicitly:

/ecs-framework:ecs-authoring how does query work?
/arcade-ecs:arcade-scaffold new breakout clone

But in practice, describing what you want plainly is enough.