fakoli-plugins: Claude Code Plugin Marketplace

The Problem

When I started building Claude Code plugins, I ran into the same friction every plugin author hits. There’s no standard way to structure a plugin. No validation to tell you if your manifest is malformed before you ship it. No central place for people to find what’s already been built. And no way for teams to maintain their own curated set of plugins without building all the infrastructure from scratch.

I watched developers (including myself) reinvent the same patterns over and over. Every new plugin needed the same boilerplate. Every team that wanted a private plugin collection had to figure out their own quality gates. Good plugins sat in random repos with no discoverability.

So I built the infrastructure layer that was missing: a curated, CI-validated marketplace with a self-managing architecture that teams can fork and make their own.

The Approach

The Extension Point Taxonomy

The first design decision was defining what a plugin actually is. I settled on four extension points that cover the full spectrum of how you’d want to extend an AI assistant:

• Skills provide knowledge and context. They’re documents that Claude loads when relevant, giving it domain expertise it wouldn’t otherwise have.
• Commands are user-invokable actions. Slash commands that trigger specific workflows.
• Agents are autonomous sub-agents with their own system prompts, tool access, and behavioral constraints. They handle complex multi-step work.
• Hooks are event-driven automations. They fire on specific events (pre-tool-use, post-tool-use, stop) and can validate, transform, or block operations.

Every plugin in the marketplace declares which of these four it contributes through a plugin.json manifest. This manifest-driven approach means discovery and installation never need to execute arbitrary code. You can browse the marketplace, read what a plugin does, and install it without running anything untrusted.

The Plugins Themselves

Here’s what’s actually in the marketplace today:

GWS (Google Workspace) is the largest plugin. It integrates Gmail, Calendar, Drive, Docs, Sheets, Slides, Chat, Tasks, Keep, Classroom, Meet, and Forms into Claude Code. Full CRUD operations, workflow recipes, and persona-based skill bundles for different roles (exec assistant, project manager, team lead).

fakoli-crew provides 8 specialized agent archetypes designed to work as coordinated teams. Instead of one general-purpose AI, you get focused agents for specific roles that can be composed into crews for complex projects. The crew-ops skill orchestrates them.

fakoli-speak turns Claude’s responses into speech. Multiple TTS providers, voice selection, cost tracking, and an autospeak mode that reads every response aloud.

Excalidraw generates and modifies diagrams from natural language descriptions or code analysis. Describe what you want, get a real Excalidraw diagram you can open and edit.

nano-banana-pro handles image generation, editing, optimization, and URL-based style remixing through Google Gemini.

systems-thinking brings structured analysis frameworks into Claude: complexity mapping, architecture risk reviews, decision briefs, pattern remixing, and context sharding for large document sets.

safe-fetch provides controlled HTTP access with safety constraints.

marketplace-manager is the meta-plugin. It manages the marketplace itself: adding new plugins from templates, removing plugins, scanning all plugins for path resolution issues and hook safety problems, installing GitHub Actions workflows, and regenerating registry indices.

Self-Managing Architecture

The marketplace-manager plugin is the design choice I’m most satisfied with. Instead of maintaining the marketplace through external scripts or manual processes, the marketplace manages itself through Claude Code.

Want to add a new plugin? Run /add-plugin and it scaffolds from a template, sets up the manifest, and registers it in the index. Want to validate everything? Run /scan-plugins and it deep-scans for path resolution issues and hook safety problems. Need CI workflows? Run /install-workflows and it drops in the GitHub Actions configuration.

This self-referential design means the marketplace eats its own dogfood. The tooling that manages plugins is itself a plugin, following the same manifest schema and validation rules as everything else.

CI Validation Pipeline

Every pull request to the marketplace triggers GitHub Actions that validate plugin structure. The pipeline checks:

• Manifest schema compliance (required fields, valid types, properly formed JSON)
• File structure (expected directories, required files present)
• Documentation completeness (README exists, commands are documented)
• Hook safety (no dangerous patterns in event-driven automations)

This shifts quality assurance left. Plugin authors get immediate feedback on structural issues before a human reviewer ever looks at the PR. For forks running private marketplaces, the same CI configuration comes along for free.

Fork-Friendly Design

I designed the marketplace explicitly for forking. A team can fork the repo, remove plugins they don’t need, add their own internal plugins, and get the full validation pipeline and management tooling without upstream changes.

The registry auto-generates indices on each merge, so forks stay self-contained. Documentation covers the forking workflow step by step: how to customize the registry, how to add private plugins, how to configure CI for your fork.

What I Learned

Self-referential systems are worth the bootstrapping complexity. Having the marketplace-manager be a plugin inside the marketplace it manages created a chicken-and-egg problem during initial setup. But once bootstrapped, the payoff is enormous. Every improvement to the management tooling benefits from the same validation and quality gates as every other plugin. The system improves itself.

A clear extension point taxonomy prevents scope creep. The four-part model (skills, commands, agents, hooks) gives plugin authors a clear framework for what goes where. Without it, everything becomes a command or everything becomes a skill. The taxonomy forces intentional design: “Is this reactive automation? That’s a hook. Is this domain knowledge? That’s a skill.”

CI validation is the trust layer. In any marketplace, the hardest problem is trust. Users need confidence that what they install won’t break their setup. Automated validation on every PR doesn’t catch everything, but it catches the structural issues that cause the most frustration: malformed manifests, missing files, undocumented commands. It turns “hope this works” into “this passed the checks.”

Plugins compose better than monoliths. Early on I considered building one mega-plugin with everything. The marketplace model is more work upfront, but it pays off in composability. A team that needs Google Workspace and TTS but not image generation installs exactly what they need. Plugin boundaries force clean interfaces. And different plugins can evolve at different speeds without blocking each other.

Agent archetypes are more useful than general agents. The fakoli-crew plugin taught me that 8 focused agents with clear roles outperform one general-purpose agent on complex work. Specialization lets each agent carry domain-specific system prompts, tool restrictions, and behavioral constraints that would conflict if merged into a single agent. The orchestration layer (crew-ops) handles coordination.