feat(module-builder): default to root manifests, bundle as opt-in#81
feat(module-builder): default to root manifests, bundle as opt-in#81
Conversation
bmad-create-module now always writes module.yaml, module-help.csv, and .claude-plugin/marketplace.json at the module root. This is the canonical layout the BMad installer expects. The setup skill (multi- skill) and self-registering single-skill bundles become opt-in add- ons for direct-download distribution; they duplicate the same root manifests so users can register the module manually. bmad-validate-module now recognizes three layouts in installer priority order: root, setup-skill bundle, self-registering bundle. Root placement is treated as canonical; bundles are validated as additional infrastructure when present alongside root manifests. Adds four new test cases covering root layout and root+bundle combinations. Headless mode in create-module gains a --bundle flag (none/setup/ standalone/auto) so callers can opt into direct-download bundling explicitly. Default is none (root only).
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🤖 Augment PR SummarySummary: This PR updates the module builder to treat root-level manifests as canonical and makes direct-download “bundle” layouts opt-in. Changes:
Technical Notes: Validator now fails on any 🤖 Was this summary useful? React with 👍 or 👎 |
| return {"status": "fail", "findings": findings, "info": info} | ||
|
|
||
| # Partial root layout: one of the two manifests exists but not both | ||
| if has_root and not (root_yaml and root_csv): |
There was a problem hiding this comment.
skills/bmad-module-builder/scripts/validate-module.py:137 — The “partial root layout” check looks unreachable because has_root is defined as bool(root_yaml and root_csv), so has_root and not (root_yaml and root_csv) can never be true. This likely prevents emitting the intended specific error when only one of the two root manifests exists.
Severity: low
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| yaml_path = setup_dir / "assets" / "module.yaml" | ||
| csv_path = setup_dir / "assets" / "module-help.csv" | ||
| # Verify bundle files exist | ||
| for label, path in [ |
There was a problem hiding this comment.
skills/bmad-module-builder/scripts/validate-module.py:155 — For the setup-skill bundle path, the validator only checks SKILL.md and the two manifest files, but not the rest of the bundle infrastructure (e.g., merge scripts) that direct-download registration depends on. As-is, an incomplete/non-runnable setup bundle could still validate successfully if those three files exist.
Severity: medium
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| """Find the setup skill folder (*-setup).""" | ||
| """Find the setup skill folder (*-setup) used for multi-skill direct-download bundling.""" | ||
| for d in module_dir.iterdir(): | ||
| if d.is_dir() and d.name.endswith("-setup"): |
There was a problem hiding this comment.
skills/bmad-module-builder/scripts/validate-module.py:53 — find_setup_skill() treats any directory ending in -setup as a bundle, which can cause root-layout modules to fail validation if they contain a normal skill with that suffix (since the bundle checks will be enforced and the folder is excluded from skill_folders). If -setup isn’t guaranteed to be reserved for module bundling, this can introduce false negatives.
Severity: medium
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| Before running this script, the LLM must duplicate the root manifests into | ||
| `<skill>/assets/module.yaml` and `<skill>/assets/module-help.csv`. The script | ||
| then copies template files (module-setup.md, merge scripts) into the skill | ||
| directory and (re)generates a .claude-plugin/marketplace.json for distribution. |
There was a problem hiding this comment.
skills/bmad-module-builder/scripts/scaffold-standalone-module.py:16 — This script “(re)generates” marketplace.json, but the implementation overwrites the file rather than merging/preserving existing fields and other plugin entries. With the updated create-module flow emphasizing merging into an existing root .claude-plugin/marketplace.json, running this bundler can clobber previously populated metadata or other modules’ entries.
Severity: high
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
Summary
bmad-create-modulenow always writesmodule.yaml,module-help.csv, and.claude-plugin/marketplace.jsonat the module root. This is the canonical layout the BMad installer expects and matches the docs landed in docs(modules): lead with root placement for module manifests #80.npx bmad-method install.bmad-validate-modulenow recognizes three layouts in installer priority order: root, setup-skill bundle, self-registering bundle. Root placement is treated as canonical; bundles are validated as additional infrastructure when present alongside root manifests.--bundleflag (none/setup/standalone/auto). Default isnone(root only), so existing CI/automation gets the cleaner default behavior.Files changed
references/create-module.md(workflow restructure: step 7 always-root, step 7.5 optional bundling, headless mode rewrite)scripts/validate-module.py(recognize root layout; treat bundles as additive)scripts/tests/test-validate-module.py(4 new test cases for root layout; 2 existing tests updated for renamed info-dict keys)scripts/scaffold-setup-skill.py,scripts/scaffold-standalone-module.py(docstring updates clarifying their new role as additive bundlers)Test plan
test-validate-module.py: 18/18 pass (14 existing + 4 new for root layout)test-scaffold-setup-skill.py: 7/7 pass (no behavior change)test-scaffold-standalone-module.py: 8/9 (1 pre-existing failure on `main`, not caused by this PR)Known follow-ups (out of scope)
Related