Your senior engineer wrote a brilliant PR review workflow. It catches secrets before they hit production, enforces conventional commits, validates test coverage. It lives in their personal Claude Code skills folder.

Then they go on holiday. The team ships a PR with hardcoded credentials.

That workflow wasn't infrastructure. It was tribal knowledge stored in one person's home directory. And it vanished the moment they logged off.

Same problem, one level up: you've encoded ten security best practices in your .claude/CLAUDE.md (solid work from Post 2), but it only helps developers in that repo. Spin up a new microservice and the team restarts from zero. Every time.

Skills, agents, and private marketplaces are how you stop paying that tax. You package a team workflow once — a review process, a testing strategy, a security check, an integration — and it distributes automatically when anyone clones any repo. In Post 3 we covered hooks as deterministic guardrails. This is the layer above: where accumulated wisdom becomes inheritance.

This is Part 4 of 5 in The Claude Code Enterprise Stack series.

The Capability Stack

Posts 1–2 gave you static configuration: hierarchy, CLAUDE.md, settings. Post 3 added deterministic automation through hooks. This post adds the dynamic capability layer on top. The layers compose; they don't replace each other.

• CLAUDE.md (Posts 1–2): "Here's how we work" — read-only guidance
• Hooks (Post 3): "Here's what we enforce" — deterministic guardrails, zero context cost
• Skills (this post): "Here's how to execute this workflow" — packaged multi-step processes
• Agents (this post): "Here's a specialist for this domain" — isolated context, role-specific tools
• MCP Servers (this post): "Here's how to connect external systems" — Model Context Protocol plumbing
• Private Marketplace (this post): "Here's where all of this lives" — centralized discovery and distribution

Rendering diagram...

Skills: Encoded Team Workflows

A skill is a reusable prompt workflow you write once. Technically, it's a markdown file with YAML frontmatter at .claude/skills/<name>/SKILL.md. Claude Code scans the directory at startup and invokes the skill when you type /skill-name — or automatically, when it decides the skill fits the task.

The description field is the load-bearing part. Claude reads it and auto-invokes the skill when relevant — no slash command needed. Which means the description has to be honest and specific: too vague and Claude never finds it; too broad and it fires at the wrong time. Precision in the description is precision in execution. Get it right and a single skill becomes inheritance: new team members get the workflow without training, PR standards propagate, security reviews scale.

Skill vs Command vs Agent

Skills for multi-step workflows ("create a PR properly," "set up a database migration"). Commands for quick actions ("format this file"). Agents for specialized roles.

Agents: Specialized Team Members

An agent is a custom AI assistant with its own isolated execution context, role-specific tools, system prompt, and model choice. Like skills, it carries a description and can auto-invoke. Store them as markdown files in .claude/agents/:

---
name: backend-reviewer
description: Review TypeScript backend code for performance, security, and architecture patterns. Use when you need expert feedback on backend changes.
model: claude-opus  # Can assign specific models for cost control
compatibility: Requires Node.js and npm access
---

# Backend Code Reviewer

You are a backend code specialist. Review code for:

1. **Performance**: N+1 queries, unnecessary loops, inefficient algorithms
2. **Security**: Input validation, injection vulnerabilities, secrets management
3. **Architecture**: Does this follow our service layer pattern? Is this the right abstraction level?
4. **Tests**: Do tests cover the happy path and error cases?

Ask clarifying questions before reviewing. Don't assume you understand the context.

The power is isolation. A backend agent gets its own context window, sees only backend-relevant files, can be barred from the frontend directory, and can run a cheaper model like Haiku for routine reviews to save tokens. The payoff: a junior's database-layer PR gets an initial expert review in minutes instead of sitting in the queue until the senior reviewer is back online.

Now the honest part, because I've spent real time fighting this one. Auto-selection of custom agents is unreliable today. I orchestrate four or five agents across my own projects, and I lost count of the times I defined a perfectly good specialist agent only to watch Claude shrug and handle the task in the main session anyway. The description-matching that works so well for skills is much flakier for agents. My working rule: if it actually matters that a specific agent handles a task, invoke it explicitly with /agent name rather than trusting auto-selection. Treat the auto-routing as a nice-to-have, not load-bearing, until it gets more dependable.

MCP Servers: The Plumbing

Model Context Protocol is the standardized way Claude Code talks to external systems. You configure servers in .mcp.json or settings.json:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    },
    "memory": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-memory"]
    }
  }
}

Now Claude has GitHub (repo operations, issues, workflows) and team memory (shared knowledge) as tools it invokes like Bash or Edit. Popular enterprise servers: GitHub (PR/issue management), Sentry (error tracking), Datadog (observability), Composio (one gateway to 850+ integrations — Jira, Linear, Slack), Supabase (database and auth).

The catch is where teams get burned: tool definitions load at session startup, consuming tokens upfront. Connect ten servers and you're burning budget just loading capabilities. Tool Search (which kicks in automatically once MCP definitions exceed 10% of context) defers descriptions until needed — but the better move is to prefer CLI tools when both can do the job. Use git, not the Git MCP server. Use gh, not the GitHub MCP server. Reserve MCP for capabilities with no CLI equivalent.

Building a Private Plugin Marketplace

The distribution layer is where the per-project tax finally disappears. A plugin marketplace is a catalog for distributing plugins, and plugins with different domains can be distributed through a single marketplace while keeping repositories separate. Each plugin bundles skills, agents, hooks, and MCP config together.

Marketplace Directory Structure

team-marketplace/
├── marketplace.json
├── skills/
│   ├── code-review/
│   │   └── SKILL.md
│   ├── create-pr/
│   │   └── SKILL.md
│   └── db-migration/
│       └── SKILL.md
├── agents/
│   ├── backend-reviewer.md
│   ├── security-scanner.md
│   └── frontend-auditor.md
├── hooks/
│   ├── pre-commit-security.sh
│   └── post-edit-format.sh
└── .mcp.json

marketplace.json tells Claude Code what to expose:

{
  "plugins": [
    {
      "name": "create-pr-skill",
      "source": "./skills/create-pr"
    },
    {
      "name": "backend-reviewer",
      "source": "./agents/backend-reviewer.md"
    }
  ]
}

Auto-Installing for New Team Members

To give a new developer every team skill, agent, and hook on clone, use extraKnownMarketplaces in .claude/settings.json:

{
  "extraKnownMarketplaces": {
    "team-plugins": {
      "source": {
        "source": "github",
        "repo": "your-org/your-marketplace-name"
      }
    }
  }
}

Trust the repo folder and Claude Code installs the marketplace automatically — every skill and agent available, inheritance by default.

Governance

Marketplaces don't have to be on GitHub, and can be private as long as git clone works with your existing credentials — but for org use they must be private or internal repos, never public. For real governance, lock it down with managed settings:

{
  "strictKnownMarketplaces": [
    {
      "source": "github",
      "repo": "your-org/approved-marketplace"
    }
  ],
  "allowManagedMcpServersOnly": true
}

Only this marketplace is allowed; no developer can add a new one. Anyone who tries gets a clear error saying policy blocks it.

How a Marketplace Actually Accumulates

I maintain a private skills marketplace for my own work, and the thing nobody tells you is that you don't sit down and design it. It accretes. Mine started as a single skill I was tired of re-pasting — a PR-creation checklist I'd typed into a dozen sessions before I finally packaged it. Then a security hook I'd written for one repo turned out to be useful in every repo, so it moved into the shared catalog. Then an agent I'd built for one project got pulled into the next. Each piece earned its place by being something I'd already written twice and refused to write a third time.

That's the real mechanism: not a roadmap, a ratchet. Most of my skills are mundane — none is individually transformative. The value is that the catalog only ever grows, and a new repo inherits the whole accumulated pile on clone instead of starting from a blank .claude/ directory.

Here's the kind of skill that ends up in it — a create-pr workflow a real team can use:

---
name: create-pr
description: Create a production-ready pull request. Use this after implementing a feature to ensure PRs have tests, documentation, and proper commit messages that meet team standards.
compatibility: Requires Git, GitHub CLI (gh), and npm
---

# Create a Production-Ready PR

## Pre-PR Checklist

Before creating this PR, verify:

1. **Tests pass**: `npm run test -- --run`
2. **Code formatted**: `npm run lint`
3. **No console logs**: Search for `console.log` in your changes
4. **No secrets**: Check for API keys, tokens, passwords in code
5. **Documentation**: Update README or relevant docs if behavior changed

## Commit Message

Conventional commits: `feat: add user authentication`, `fix: resolve cache race condition`. The PR body states what changed, why, how, how it was tested, and any risk.

## Create the PR

```bash
git push -u origin your-branch-name
gh pr create --fill  # Uses commit message as template

A developer follows the checklist and submits a proper PR — no training. Give it a good description and Claude offers it proactively: "I see you've implemented a feature. Should I help you create a PR with tests and documentation?"

## Three Governance Levels

The same hierarchy as Post 1's precedence system — personal overrides team, team overrides org, but org can enforce non-overridably:

- **Individual** — personal skills and agents in `~/.claude/` (cross-project utilities: coding style, debugging workflows).
- **Team** — skills, agents, and a CLAUDE.md committed to `.claude/`; inherited by everyone in the repo on clone.
- **Organization** — a private marketplace repo of approved skills, agents, hooks, and MCP config, auto-installed via `extraKnownMarketplaces`, locked by `strictKnownMarketplaces` and `allowManagedHooksOnly: true`.

Each layer is a different trade. Hooks: zero context cost, deterministic, but limited to input/output transformation. Skills: a few tokens of text for deterministic execution of team patterns. MCP: real token cost at startup, bought for external integration. So the order of preference is hooks for enforcement, CLAUDE.md for context, skills for workflows, agents for specialization, MCP only where there's no CLI equivalent.

The result: a new engineer runs `claude` for the first time and inherits the team's standards, security checks, workflows, domain experts, and integrations — all from version control, all enforceable by managed settings. The leverage stops being about raw speed. The multiplier is that every developer reaches the whole team's accumulated practice the moment they clone a repo, and a junior can pick up a problem that used to need a senior, because the senior's judgment is already packaged into a skill they inherited.

Which leaves the one question I genuinely can't answer by feel, and neither can you: does any of this actually move delivery, or does it just feel good? That's Post 5 — [measuring the ROI](https://cutler.sg/blog/2026-03-measuring-claude-code-roi-sme-teams-scaling) with numbers instead of vibes, because no CFO ever signed off on "it feels faster."

---

**Series Navigation**
- [Post 1: Why Configuration Matters More Than Models](https://cutler.sg/blog/2026-03-claude-code-configuration-hierarchy-smb-teams)
- [Post 2: Building Your First CLAUDE.md](https://cutler.sg/blog/2026-03-building-claude-md-team-standards-smb-playbook)
- [Post 3: Hooks: Deterministic Policy Enforcement for Claude Code Teams](https://cutler.sg/blog/2026-03-claude-code-hooks-deterministic-policy-enforcement)
- **Post 4: Skills, Agents, and Private Marketplaces (you are here)**
- [Post 5: Measuring Claude Code ROI and Scaling Beyond Day One](https://cutler.sg/blog/2026-03-measuring-claude-code-roi-sme-teams-scaling)