| name | architecture-paradigm-microkernel |
| description | Build a minimal, stable core system that loads plug-ins to provide feature variability and extensibility for platform development. Triggers: microkernel, plugin architecture, plugin system, extensibility, platform design, IDE architecture, marketplace, core system, plugin loader Use when: building platforms, IDEs, or marketplaces with third-party extensions, core stability is critical while features vary, plugin isolation is needed DO NOT use when: selecting from multiple paradigms - use architecture-paradigms first. DO NOT use when: no extensibility requirements exist. DO NOT use when: plugin isolation overhead isn't justified. Consult this skill when designing plugin architectures or building platforms. |
| version | 1.0.0 |
| category | architectural-pattern |
| tags | architecture, microkernel, plugin, extensibility, platform-design |
| dependencies | |
| tools | plugin-loader, sandbox-executor, sdk-generator |
| usage_patterns | paradigm-implementation, platform-development, extensibility-design |
| complexity | high |
| estimated_tokens | 900 |
The Microkernel (Plugin) Architecture Paradigm
When to Employ This Paradigm
- When building platforms, Integrated Development Environments (IDEs), data ingestion pipelines, or marketplaces where third parties need to extend core functionality.
- When the core system requires extreme stability, while extensions and features must evolve and change rapidly.
- When isolating optional dependencies and sandboxing untrusted code provided by plugins is critical.
Adoption Steps
- Define Core Services: Clearly delineate the minimal responsibilities of the microkernel, such as scheduling, component lifecycle management, core domain primitives, and messaging.
- Specify the Plugin Contract: Design and document the formal contract for all plugins, including registration procedures, capability descriptors, lifecycle hooks (e.g., start, stop), and the permission model.
- Build the Extension Loader and Sandbox: Implement the mechanisms for loading extensions, performing version compatibility checks, negotiating capabilities, and isolating plugins to prevent failures from cascading.
- Provide a Software Development Kit (SDK): To facilitate plugin development, provide an SDK with project templates, testing harnesses, and compatibility-checking tools.
- Govern the Release Process: Maintain a clear compatibility matrix between core and plugin versions. Implement an automated regression test suite that validates core functionality against a variety of plugins.
Key Deliverables
- An Architecture Decision Record (ADR) describing the division of responsibilities between the core and plugins, along with the governance model for plugin development and certification.
- Formal documentation for the security and permission model, detailing what capabilities are available to plugins.
- An automated plugin validation pipeline that performs linting, runs tests, and executes the plugin within a sandbox environment.
Risks & Mitigations
- Uncontrolled Plugin Proliferation:
- Mitigation: Without a curation process, the maintenance cost of supporting numerous plugins can become unsustainable. Enforce a formal certification process or a marketplace-style review for all third-party plugins.
- Version Skew Between Core and Plugins:
- Mitigation: Use semantic versioning (SemVer) rigorously for both the core and the plugins. Where necessary, provide abstraction layers or "shims" to maintain backward compatibility with older plugins.
- Core System Bloat:
- Mitigation: There is often pressure to add feature logic to the stable core. Aggressively resist this temptation. The core should remain minimal, with new features implemented as plugins whenever possible.