Nm Archetypes Architecture Paradigm Microkernel

Microkernel architecture with a minimal core and plugin-based extensibility for platforms

Security Scan

This is an instruction-only design guide for a microkernel/plugin architecture; its content, requirements, and scope align with the stated purpose and it does not request credentials, installs, or write code.

Purpose & Capability

The skill's name and description match the SKILL.md content (guidance on microkernel/plugin architectures). There are no required binaries, env vars, or config paths that would be unrelated to this purpose.

Instruction Scope

SKILL.md contains high-level architectural guidance, adoption steps, deliverables, risks/mitigations, and troubleshooting notes. It does not instruct the agent to read local files, access environment variables, or transmit data to external endpoints. Minor note: the header in SKILL.md lists version 1.8.2 while the registry metadata is 1.8.3, and it suggests installing a separate 'Claude Code' plugin for the 'full experience' (this only recommends another plugin; it does not itself execute anything).

Install Mechanism

No install spec and no code files are provided—this is instruction-only, so nothing will be downloaded or written to disk by the skill itself.

Credentials

The skill declares no required environment variables, credentials, or config paths; the guidance does not attempt to access secrets or external credentials.

Persistence & Privilege

Flags show always:false and user-invocable:true (normal). Model invocation is allowed (the platform default) but the skill does not request persistent system presence or elevated privileges.

Assessment

This skill is a read-only architecture guide and appears internally consistent. Before installing/using it: (1) understand it provides design guidance only—there's no code executed by the skill itself; (2) if you follow its suggestion to install the external 'Claude Code' plugin, review that plugin's provenance and permissions separately; (3) confirm the minor version mismatch (SKILL.md header vs registry) if you rely on exact versions. If you need automated tooling or runtime behavior (SDKs, loaders, sandboxes), expect to install additional software whose security you should evaluate independently.

Night Market Skill — ported from claude-night-market/archetypes. For the full experience with agents, hooks, and commands, install the Claude Code plugin.

The Microkernel (Plugin) Architecture Paradigm

When To Use

• Building extensible systems with plugin architectures
• Products requiring customer-specific customizations

When NOT To Use

• Monolithic applications without plugin extensibility needs
• Systems where all features are core and tightly coupled by design

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

1. Define Core Services: Clearly delineate the minimal responsibilities of the microkernel, such as scheduling, component lifecycle management, core domain primitives, and messaging.
2. 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.
3. 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.
4. Provide a Software Development Kit (SDK): To facilitate plugin development, provide an SDK with project templates, testing harnesses, and compatibility-checking tools.
5. 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.

Troubleshooting

Common Issues

Command not found Ensure all dependencies are installed and in PATH

Permission errors Check file permissions and run with appropriate privileges

Unexpected behavior Enable verbose logging with --verbose flag