When the framework evolves, the plugins evolve in the same commit. Because each plugin rides inside its npm package, there is no separate plugin repo to bump — you edit the skill, bump the package, publish, done.

Where everything lives

Inside the bjsm monorepo:

packages/ecs/
├── .claude-plugin/
│   └── plugin.json                 # name: ecs-framework, version mirrors npm
├── skills/
│   └── ecs-authoring/
│       └── SKILL.md                # API surface + anti-pattern table
└── package.json                    # files[] includes .claude-plugin + skills

packages/arcade/
├── .claude-plugin/
│   └── plugin.json                 # name: arcade-ecs, version mirrors npm
├── skills/
│   └── arcade-scaffold/
│       └── SKILL.md                # CLI scaffolding workflow
└── package.json                    # files[] includes .claude-plugin + skills

The catalog is published separately at BabylonJSMarket/claude-plugins:

claude-plugins/
├── .claude-plugin/
│   └── marketplace.json            # lists both plugins, each with npm source
└── README.md

When the framework adds a hook or method

Edit packages/ecs/skills/ecs-authoring/SKILL.md. Find the relevant class section and add the new method with its real signature, citing the source file. If the new method makes an old approach obsolete, move the old approach into the anti-pattern list with the replacement.

Bump the version in:

• packages/ecs/package.json (version)
• packages/ecs/.claude-plugin/plugin.json (version — keep aligned with the npm version)

Publish via the monorepo's release script:

./scripts/release.sh packages/ecs

Users pick up the new version with /plugin marketplace update babylonjsmarket && /plugin install ecs-framework@babylonjsmarket.

When the arcade CLI grows a new command

Edit packages/arcade/skills/arcade-scaffold/SKILL.md to document the new flag or template. Bump packages/arcade/package.json and packages/arcade/.claude-plugin/plugin.json together, then run the release script targeting the arcade package.

When you want a new plugin

1. Pick an npm package to host it (or create a new one).
2. Add .claude-plugin/plugin.json and a skills/ directory inside the package.
3. Update the package's files array to include .claude-plugin and skills.
4. Add an entry to the catalog's marketplace.json:

   {
     "name": "my-plugin",
     "description": "...",
     "source": { "source": "npm", "package": "@babylonjsmarket/my-package" }
   }
   

5. Publish the package; push the catalog change.

Testing changes locally

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

Edit SKILL.md. Inside Claude Code:

/reload-plugins

The change is live without restarting the session.

The rule that's load-bearing

The plugin and its package version must stay in lockstep. The plugin describes API conventions; the package implements them. If they drift, the skill starts lying — telling Claude that world.getEventBus() exists when the runtime still has world.eventBus, or vice versa. Co-locating prevents drift by construction: one publish, both updated.

If a convention genuinely needs to differ between consumers, that's a sign the plugin should expose a configuration knob — not a sign that consumers should hand-roll their own conventions.