Opinionated by design
Helix is designed to reduce framework drift across services. Instead of requiring every team to reassemble the same conventions, it provides a structured starting point for project generation, dependency composition, build logic, and platform-aligned defaults.
The value is not only in individual modules. It comes from how those modules work together to create repeatability, maintainability, and a better developer experience across teams and repositories.
Ecosystem building blocks
Templates
Templates establish the initial project structure and provide a consistent foundation for new applications.
Starters and libraries
Starters package common dependency and configuration patterns, while libraries provide reusable implementation building blocks.
Plugins and build logic
Plugins help encode build conventions, quality checks, and shared automation so teams do not rebuild the same Gradle logic in each repository.
CLI
The CLI acts as the front door to the ecosystem, helping developers discover templates, generate projects, and begin from an approved path instead of a blank repository.
MCP ecosystem
Helix is designed to work cleanly with modern coding agents through a first-class Model Context Protocol integration. Instead of forcing agents to infer Helix conventions from scattered files, the framework can expose structured discovery, example, template, semantic, and Spring wiring data over MCP.
That makes Helix agent compliant in a practical sense: an agent can ask Helix what modules exist, which plugins apply to a stack, which examples demonstrate a pattern, how Spring beans are wired, and which configuration properties matter before it starts changing code.
In practice, that helps agents:
- discover Helix-native modules, plugins, templates, and examples without guessing
- choose framework-aligned patterns instead of falling back to generic Spring rewrites
- explain autoconfiguration, bean wiring, and web behavior with Helix-specific context
- extend existing services in a way that stays closer to documented platform conventions
Helix also includes prebuilt agent skills that help tools such as Codex work more effectively inside Helix application repositories. Those skills guide agents toward Helix-native structure, conventions, testing patterns, and capability selection instead of defaulting to generic Spring or Java rewrites.
For teams setting up agent workflows locally, the CLI provides the simplest installation path for the MCP server:
helix mcp setup claude
The install flow keeps a stable local MCP path under the Helix config directory so client configuration does not need to change when the MCP server is updated. Together, the MCP server, the prebuilt skills, and the CLI setup flow form a single ecosystem for AI-assisted Helix development rather than a collection of unrelated add-ons.
This matters most for teams using coding agents as part of day-to-day development. Helix does not treat AI support as an afterthought layered on top of the framework. It publishes agent-facing context as part of the ecosystem so the same platform conventions available to humans through the docs and CLI are also available to agents through MCP.
How teams usually adopt Helix
- Platform or architecture teams validate one or two reference service patterns.
- Application teams bootstrap new services from approved templates.
- Shared build logic and plugins establish quality and delivery consistency.
- Documentation and examples become the source of truth for rollout and ongoing maintenance.