Ship Standards, Not Wikis: Plugins and the Marketplace

February 13, 2026

This is Part 2 of a four-part series on onboarding engineering teams with Claude Code. Part 1: The Foundation · Part 3: Skills · Part 4: Hooks and Putting It All Together GitHub template →

Plugins and the Marketplace

A new developer's first day used to involve a checklist: install the right VS Code extensions, configure the linter, set up database credentials, connect to the project management tool, get access to the staging environment. Each step is another opportunity for something to go wrong, another place where the documentation might be stale.

Claude Code's plugin marketplace collapses this setup into a declarative configuration. The official Anthropic marketplace (claude-plugins-official) ships with integrations for the tools most teams already use:

  • Code intelligence plugins for TypeScript, Python, Rust, Go, and others—giving Claude jump-to-definition, find-references, and real-time type checking
  • External service integrations for GitHub, Jira, Linear, Slack, Notion, Sentry, Vercel, and more
  • Development workflow plugins for git operations, PR review automation, and deployment

Declaring Plugins at the Team Level

The real power is in how plugins are configured at the team level. In your project's .claude/settings.json, you declare which marketplaces and plugins your project requires:

What this means in practice: A new developer clones the repo. Claude Code reads the configuration file and says: "This project requires the TypeScript language server, the GitHub integration, and your company's design system docs plugin. Install them?" One confirmation, and the environment is set up. No checklist, no Slack thread, no stale wiki page.

{
  "extraKnownMarketplaces": [
    "your-org/internal-claude-plugins"
  ],
  "enabledPlugins": [
    "typescript-lsp@claude-plugins-official",
    "github-integration@claude-plugins-official",
    "linear-integration@claude-plugins-official",
    "your-org:design-system-docs@your-org/internal-claude-plugins"
  ]
}

When a new team member clones the repo and trusts the project folder, Claude Code prompts them to install the specified plugins automatically. No checklist. No Slack messages asking which extensions to install. The environment configures itself.

Building an Internal Marketplace

For organization-specific tooling, you can host your own marketplace. This is just a Git repository with a defined structure:

What this means in practice: Your company's internal tools—the deployment pipeline, the design system, the incident runbook—get distributed as installable plugins, the same way you'd install a VS Code extension. Engineers on a new project get them automatically when they join. You don't maintain a separate onboarding doc explaining what to install.

your-org/internal-claude-plugins/
├── marketplace.json
├── design-system-docs/
│   ├── plugin.json
│   └── skills/
│       └── component-guide/
│           └── SKILL.md
├── deployment-pipeline/
│   ├── plugin.json
│   └── hooks/
│       └── hooks.json
└── code-review-standards/
    ├── plugin.json
    └── skills/
        └── review/
            └── SKILL.md

Teams register it with /plugin marketplace add your-org/internal-claude-plugins, and the internal tools show up in the same discovery interface as the official marketplace. This is how you distribute company-specific integrations—your design system documentation, your deployment pipeline configuration, your internal API clients—without maintaining custom tooling.

What a Plugin Can Contain

A plugin is more than just an integration—it's a bundle. Alongside the connector code, a plugin can ship:

  • Skills that teach Claude your internal workflows (the deployment checklist, the PR review standard, the incident runbook)
  • Hooks that enforce your rules automatically (blocking secrets from being written, running your formatter after every edit)
  • Documentation that Claude can reference when answering questions about your systems

This means an internal marketplace plugin for, say, your deployment pipeline can include the connection to your CI system, the skill that walks through the deploy checklist, and the hooks that block a deploy if tests haven't passed—all in one installable unit.

The Practical Effect

The goal isn't to make onboarding faster for its own sake. It's to make the standards self-installing. When a developer joins and the environment configures itself, the implicit message is that these tools and integrations aren't optional—they're how this team works. The configuration file in version control is the source of truth, not a wiki page that someone updates when they remember to.

Continue reading: