af52c7baf9
The bmad-module skill staged community modules under _bmad/<code>/ but never pushed their skills out to the coding assistants the user selected at `bmad install` time, so a freshly installed module was invisible to Claude Code / Cursor / Copilot / etc. until a full reinstall; remove left skills orphaned in the IDE dirs. install/update/remove now distribute (or prune) skills to every IDE listed in _bmad/_config/manifest.yaml and clean the redundant skill dirs from _bmad/, matching how official modules end up. Single engine, three callers — no fork: - New tools/installer/core/ide-sync.js (syncIdes) wraps the real IdeManager.setupBatch + platform-codes engine. The full installer (_setupIdes/_cleanupSkillDirs), the new `bmad ide-sync` command, and the skill all route through it, so new IDEs and engine changes propagate everywhere automatically. Local, dependency-free delivery — no npx/network at runtime: - build-ide-sync.mjs esbuild-bundles the engine into vendor/ide-sync.mjs (+ platform-codes.yaml), aliasing ../prompts and ../project-root to small shims so @clack and the installer graph are dropped. The bundle ships inside the skill tree (like yaml.mjs); the skill execs it locally. It's generated-from-source and gated by vendor:check, refreshed on every install. update/remove pass --prune with the module's canonicalIds so skills dropped between versions (or on uninstall) are removed from IDE dirs + command pointers. Graceful degradation: if the bundle is unreachable, the verb still succeeds and points the user at `bmad ide-sync`. Tests: new test/test-ide-sync.js drift-guard (engine == bundle, incl. prune), integration.test.sh IDE-distribution section (offline), bundle self-check in the build. All gates green (vendor:check, lint, format, test:install 349/349). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| commands | ||
| core | ||
| ide | ||
| modules | ||
| README.md | ||
| bmad-cli.js | ||
| cli-utils.js | ||
| file-ops.js | ||
| fs-native.js | ||
| install-messages.yaml | ||
| list-options.js | ||
| message-loader.js | ||
| project-root.js | ||
| prompts.js | ||
| set-overrides.js | ||
| ui.js | ||
| yaml-format.js | ||
README.md
BMad CLI Tool
Installing external repo BMad official modules
For external official modules to be discoverable during install, ensure an entry for the external repo is added to external-official-modules.yaml.
For community modules - this will be handled in a different way. This file is only for registration of modules under the bmad-code-org.
Post-Install Notes
Modules can display setup guidance to users after configuration is collected during npx bmad-method install. Notes are defined in the module's own module.yaml — no changes to the installer are needed.
Simple Format
Always displayed after the module is configured:
post-install-notes: |
Thank you for choosing the XYZ Cool Module
For Support about this Module call 555-1212
Conditional Format
Display different messages based on a config question's answer:
post-install-notes:
config_key_name:
value1: |
Instructions for value1...
value2: |
Instructions for value2...
Values without an entry (e.g., none) display nothing. Multiple config keys can each have their own conditional notes.
Example: TEA Module
The TEA module uses the conditional format keyed on tea_browser_automation:
post-install-notes:
tea_browser_automation:
cli: |
Playwright CLI Setup:
npm install -g @playwright/cli@latest
playwright-cli install --skills
mcp: |
Playwright MCP Setup (two servers):
1. playwright — npx @playwright/mcp@latest
2. playwright-test — npx playwright run-test-mcp-server
auto: |
Playwright CLI Setup:
...
Playwright MCP Setup (two servers):
...
When a user selects auto, they see both CLI and MCP instructions. When they select none, nothing is shown.