Skip to main content

Architecture Overview

AI Primitives Hub is a pnpm monorepo for discovering, packaging, installing, and managing AI primitives. This page describes the implementation in this repository today. Architecture Decision Records (ADRs) explain decisions and migration direction; they are not evidence that every migration step is complete.

Current Shape​

The repository has two delivery layers over shared packages:

  • The Clipanion CLI under packages/cli/
  • The VS Code extension under apps/vscode-extension/

The CLI delegates most use cases to the shared packages. The extension also uses the shared packages, but still owns VS Code-specific commands, UI, storage wiring, events, notifications, and several compatibility facades. The extension is therefore not yet only a thin shell.

flowchart TD
USER["CLI user"] --> CLI["packages/cli"]
IDE["VS Code user"] --> EXT["Extension commands and UI"]
EXT --> ESVC["Extension services and facades"]
CLI --> APP["packages/app"]
ESVC --> APP
ESVC --> INFRA["packages/infra"]
ESVC --> CORE["packages/core"]
APP --> INFRA
APP --> CORE
INFRA --> CORE

Package Responsibilities​

AreaCurrent responsibility
packages/coreDomain types, validation rules, errors, schemas, and ports for external capabilities
packages/infraImplementations of core ports: source adapters, HTTP/GitHub access, stores, search, archives, scaffolding, layout loading, and target writers
packages/appUse-case orchestration for installation, registry/Hub/profile operations, discovery, search, updates, and transforms
packages/cliClipanion commands, argument parsing, terminal output, and delivery-specific wiring
apps/vscode-extensionVS Code commands, views, webviews, progress, notifications, host detection, extension storage wiring, and compatibility facades over shared use cases
libLegacy collection build, validation, publishing, and release-analysis scripts

The package dependency declarations enforce this shared direction:

flowchart LR
CLI["CLI"] --> APP["app"]
EXT["Extension"] --> APP
APP --> INFRA["infra"]
APP --> CORE["core"]
INFRA --> CORE

core has no dependency on another @ai-primitives-hub/* package. infra depends on core; app depends on both. The CLI also declares direct dependencies on all three because its delivery wiring constructs concrete adapters as well as calling application services.

VS Code Extension​

The extension currently has its own layered delivery architecture:

flowchart TD
VIEW["Tree views and webviews"] --> CMD["Command handlers"]
CMD --> REG["RegistryManager and focused services"]
REG --> SHARED["Shared app use cases"]
REG --> VSC["VS Code-specific storage and events"]
SHARED --> ADAPTERS["infra source adapters and writers"]

Important current boundaries:

  • RegistryManager remains the central extension facade. Search, installation, uninstallation, update detection, and profile operations already delegate substantial behavior to packages/app.
  • BundleInstaller owns extension-specific installation wiring and invokes the shared InstallPipeline for the generic download, extraction, validation, cache, and write sequence.
  • UserScopeService and RepositoryScopeService handle host- and scope-specific synchronization.
  • McpServerManager and McpConfigService manage MCP configuration as a merge/tracking lifecycle rather than as a normal copied file.
  • HubManager is an extension facade over shared Hub resolution, storage, validation, and application operations.
  • Source adapter construction has moved to packages/app and packages/infra; the extension adapter directory contains compatibility wiring for remaining call sites.

See Core Flows for the current entry points and Installation Flow for scope-specific details.

CLI​

packages/cli is an active delivery layer, not scaffolding. It contains commands for collections, primitives, bundles, sources, Hubs, profiles, targets, discovery/indexing, installation, configuration, completion, and diagnostics.

Commands parse input and format output. Shared business behavior belongs in packages/app, with ports and domain rules in core and concrete adapters in infra.

Main Runtime Flows​

Discovery​

flowchart TD
SOURCE["Configured source"] --> FACTORY["app source-adapter factory"]
FACTORY --> ADAPTER["infra adapter"]
ADAPTER --> REMOTE["GitHub, local, APM, skills, or other source"]
ADAPTER --> BUNDLES["Normalized bundle metadata"]
BUNDLES --> STORE["Registry/index storage"]
STORE --> UI["Extension marketplace or CLI search"]

Installation​

flowchart TD
ACTION["CLI command or extension action"] --> RESOLVE["Resolve bundle and target"]
RESOLVE --> DOWNLOAD["Download through source adapter"]
DOWNLOAD --> PIPE["Shared InstallPipeline"]
PIPE --> EXTRACT["Extract and validate"]
EXTRACT --> CACHE["Install/cache content"]
CACHE --> WRITE["Write target and scope layout"]
WRITE --> MCP["Merge MCP configuration when present"]
MCP --> STATE["Record lock and installation state"]

The delivery layers do not yet use identical wiring around every step. The shared pipeline is the common generic sequence; the extension adds VS Code progress, events, scope services, MCP handling, and its existing storage model.

Hub synchronization​

flowchart TD
REF["GitHub, URL, or local Hub reference"] --> RESOLVER["HubResolver"]
RESOLVER --> VALIDATE["Parse and validate Hub configuration"]
VALIDATE --> STORE["HubStore"]
STORE --> ACTIVE["Select active Hub"]
ACTIVE --> SYNC["Synchronize enabled sources"]
SYNC --> PROFILES["Expose shared profiles and collections"]

A Hub is configuration that distributes sources and profiles. It does not contain the primitive files itself. See Creating a Hub for the author workflow and Hub Schema for field definitions.

Persistence and External Boundaries​

BoundaryCurrent implementation
Source contentGitHub, Azure DevOps, URLs, local files, APM, skills, and Awesome Copilot adapters where supported by the relevant source model
Shared application stateAppStorage port with the XDG-based infrastructure implementation
Extension stateVS Code extension storage facades plus repository lockfiles
Repository installation stateprompt-registry.lock.json and local-only lock/exclusion behavior
Target filesHost- and scope-aware writers/layout resolution
MCP stateHost configuration files plus managed-server tracking

The existing prompt-registry identifiers are retained where changing them would break compatibility. See ADR-0004 in the ADR index.

Documentation Boundaries​

Use this page for the current system map. Keep detailed behavior in the existing focused pages rather than repeating it here:

When these pages disagree with executable code, tests, or schemas, treat the executable behavior as authoritative and correct the documentation.