The Problem

Teams that build Claude‑Code extensions need a curated, version‑controlled catalog of ready‑to‑install plugins. Maintaining that catalog manually is error‑prone, and without a reproducible build pipeline new releases can break downstream CI pipelines.

What This Does

The ClaudeForge Marketplace repository is a data‑driven plugin catalog. Each plugin lives under plugins/* and contains a .claude-plugin/plugin.json manifest plus a Markdown description (e.g., plugins/agents/ai-architect/agents/ai-engineer.md). The three “super” plugins expose lightweight server stubs in plugins/super/*/servers/ (e.g., plugins/super/enterprise-workspace/servers/workspace‑server). These servers are the only executable code (JavaScript) in the repo; everything else is static metadata.

The Dockerfile in the repository builds a container that packages the manifest files and the three server entry points, enabling the external Claude‑Code CLI to discover and install plugins via commands such as:

/plugin marketplace add https://github.com/moses-y/marketplace.git
/plugin install ai-architect@claudeforge-marketplace

How It Is Wired

Entry point – The container’s CMD (defined in Dockerfile) launches node plugins/super/enterprise-workspace/servers/workspace-server/index.js (the exact file name is not listed but follows the pattern index.js in each server folder). This server registers the super‑plugin’s hooks with the Claude runtime.

Internal call graph – Static analysis found 3 internal modules with zero import edges and no circular dependencies:

  • plugins/super/ai-studio-orchestrator/servers/orchestrator-server
  • plugins/super/devops-platform/servers/devops-server
  • plugins/super/enterprise-workspace/servers/workspace-server

Each module is isolated; they expose a single exported handler (e.g., module.exports = startServer) and do not call one another. Consequently, the blast radius of a change is limited to the single server binary.

Data flow – The bulk of the repository (plugins/*/*.json and *.md) is consumed by the Claude‑Code CLI at runtime. The CLI reads each plugin.json to build a registration table, then serves the associated Markdown as help text. No runtime code traverses these files beyond simple JSON parsing, so the operational path is:

Docker entry → server binary → read plugin.json → expose endpoints → CLI consumes endpoints

Unmapped wiring – There is no internal orchestration beyond the three servers; the rest of the repo consists of static assets. No additional call graph could be derived for the Markdown or JSON files.

How To Use It

# Clone the catalog
git clone https://github.com/moses-y/marketplace.git
cd marketplace

# Build the Docker image (Dockerfile present at repo root)
docker build -t claudeforge/marketplace:1.2.0 .

# Run the container (exposes the plugin discovery service on 8080)
docker run -d -p 8080:8080 claudeforge/marketplace:1.2.0

The running container registers the three super‑plugin servers. The Claude‑Code CLI can now point at the container’s HTTP endpoint (environment variable CLAUDE_MARKETPLACE_URL is expected by the CLI; the variable is documented in README.md).

Configuration is minimal: the only required file is .claude-plugin/marketplace.json, which defines the marketplace’s identifier and version. No additional environment variables or secret files are needed.

Real‑World Use

A SaaS platform that automates AI‑agent provisioning can embed the marketplace container as a sidecar. When a new tenant is onboarded, the platform calls the workspace‑server endpoint to spin up an isolated enterprise workspace, then uses the CLI to install the ai-architect plugin into that workspace. All plugin metadata is guaranteed to be in sync because the container image is version‑pinned.

Code Health & Issues

  • Medium – Cognitive load – plugins/super/enterprise-workspace/scripts/validate-workspace.sh contains 38 branch points in 88 lines. Refactor into smaller functions or a strategy table to improve readability.
  • Low – Clarity – Same script holds 7 TODO/FIXME markers; convert them to tracked GitHub issues.
  • SDLC – No CI/CD pipeline detected (.github/ absent). Adding a GitHub Actions workflow that runs the existing 48 test files on each PR would enforce regression safety.
  • Tests – Test suite exists (48 files) but is not tied to any automated gate.
  • Dockerfile – Present and functional, enabling reproducible builds.
  • License – MIT file is included.
  • Lockfile – No package-lock.json or yarn.lock; dependency versions are not pinned, which could cause nondeterministic builds.

The Bottom Line

The repository delivers a comprehensive, static catalog of Claude‑Code plugins backed by a minimal Docker‑based runtime. Its strength lies in data‑centric organization and isolated server modules, but the lack of CI, unpinned dependencies, and a dense validation script limit maintainability. It is suitable for teams that need a ready‑made plugin index and can supply their own CI pipeline and dependency pinning.