Customizing the Plugin

The skill is authored in one place. Edit it there, and both delivery channels — the installable plugin and the zero-install injection — pick up the change from the same source.

Where everything lives

Inside the bjsm monorepo, the plugin is its own repo:

packages/claude-plugin-arcade-ecs/
├── .claude-plugin/
│   ├── plugin.json                 # name: arcade-ecs
│   └── marketplace.json            # marketplace: babylonjsmarket → source "./"
├── skills/
│   └── babylonjsmarket/
│       ├── SKILL.md                # the canonical skill — edit HERE
│       └── scripts/detect-packages.sh
└── README.md

The arcade package ships a copy of that skill for the zero-install path:

packages/arcade/.claude-payload/skills/babylonjsmarket/   # injected into scaffolded / ejected projects

That copy is generated — never edited by hand.

Editing the skill

Edit packages/claude-plugin-arcade-ecs/skills/babylonjsmarket/SKILL.md. When the framework adds a hook or method, add it with its real signature and cite the source file. When something is deprecated or renamed, move the old form into the anti-pattern table with its replacement — that table is what stops Claude from writing the stale API.

Then sync the copy the arcade scaffold injects:

./scripts/sync-plugin-skill.sh

It's content-guarded (a no-op when already in sync) and copies the canonical skill into packages/arcade/.claude-payload/. release.sh runs it automatically before publishing arcade, so a forgotten sync can't ship stale.

Releasing

• The plugin (marketplace channel): commit and push the claude-plugin-arcade-ecs repo. The marketplace reads it straight from GitHub — users pick it up with /plugin marketplace update babylonjsmarket && /plugin install arcade-ecs@babylonjsmarket.
• The injected copy (zero-install channel): ships with the next @babylonjsmarket/arcade release (./scripts/release.sh packages/arcade), which runs the sync first. Scaffolded/ejected projects then get the new skill next time they scaffold or arcade eject.

Testing changes locally

claude --plugin-dir packages/claude-plugin-arcade-ecs

Edit SKILL.md, then inside Claude Code:

/reload-plugins

The change is live without restarting the session.

The rule that's load-bearing

There is exactly one source of truth — the skill in the plugin repo. Never edit the arcade payload copy directly; run the sync instead. The skill describes API conventions; the packages implement them. If the skill drifts from the source, it starts lying — telling Claude that world.getEventBus() exists when the runtime still has world.eventBus, or vice versa. Keeping a single authored copy, verified against the installed types, is what prevents that.