Help us improve
Share bugs, ideas, or general feedback.
From bee
Generates .claude/BOUNDARIES.md from a discovery document's Module Structure section to enforce module boundaries in greenfield projects.
npx claudepluginhub incubyte/ai-plugins --plugin beeHow this skill is triggered — by the user, by Claude, or both
Slash command
/bee:boundary-generationThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
After discovery completes on a greenfield project, check whether the discovery document contains a **Module Structure** section. If absent, skip this entirely.
Generates or updates CLAUDE.md from project context and blueprint artifacts. Supports @import syntax, CLAUDE.local.md, and team vs auto memory delineation.
Decomposes projects or tracks into modules with dependency mapping, updating architecture and generating HLD/LLD artifacts. Integrates with graph-based analysis for module discovery and cycle detection.
Maintains architecture.yml with module metadata (path, role, stability) for AI-first repos. Drafts structured answers from directory walk + AGENTS.md; user confirms role/stability.
Share bugs, ideas, or general feedback.
After discovery completes on a greenfield project, check whether the discovery document contains a Module Structure section. If absent, skip this entirely.
Parse the Module Structure section from the discovery document — extract each module name, its owned concepts, and its allowed dependencies.
Ask the developer for consent using AskUserQuestion:
"Discovery produced module boundaries for this project. Want me to save these so Claude respects them in all code it writes? I'll create .claude/BOUNDARIES.md."
Options: "Yes, save boundaries (Recommended)" / "No, skip for now"
If the developer consents, generate .claude/BOUNDARIES.md in the target project (not the bee plugin directory) with this format:
# Module Boundaries
> Generated by /bee:discover from the project's milestone map.
> Edit this file to adjust boundaries as the project evolves.
## Modules
- `modulename/` — owns: Concept1, Concept2. Depends on: (none)
- `modulename/` — owns: Concept3. Depends on: modulename
## Rules
- Modules may only import from declared dependencies
- Domain concepts live in their owning module — do not scatter across modules
- No circular dependencies
- When in doubt, duplicate code rather than create a coupling that violates boundaries
Populate the Modules section from the discovery document's Module Structure entries.
If .claude/BOUNDARIES.md already exists (from a previous discovery run), ask:
"Existing boundaries found. Update with new module structure or keep current?"
Options: "Update with new boundaries (Recommended)" / "Keep existing"
If CLAUDE.md exists in the target project and doesn't already reference BOUNDARIES.md, ask:
"Want me to add a reference to BOUNDARIES.md in your CLAUDE.md so Claude always has boundary context?"
Options: "Yes, add reference (Recommended)" / "No, skip"
If yes, append a line to CLAUDE.md: Read .claude/BOUNDARIES.md for module boundary rules.
Report to the developer which modules and boundaries were saved.
→ Update state: "${CLAUDE_PLUGIN_ROOT}/scripts/update-bee-state.sh" set --boundaries ".claude/BOUNDARIES.md"
Proceed normally without boundaries. They are valuable but not blocking.