Skills, Agents, and Private Marketplaces: Scaling Team Capabilities
Your senior engineer wrote a brilliant PR review workflow. It lives in their personal Claude Code skills folder. One week when they're on holiday, the team loses it.
Or worse: 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. When the team spins up a new microservice, they restart from zero. Each team reinvents the wheel.
This is the problem that skills, agents, and private marketplaces solve. They let you package team workflows once—review processes, testing strategies, security checks, integrations—and inherit them automatically when team members clone the repo.
In Post 3, we covered hooks as deterministic guardrails. Now we're moving up the stack to the capability distribution layer. This is where your team's accumulated wisdom becomes infrastructure.
This is Part 4 of 5 in The Claude Code Enterprise Stack series.
The Three Capability Layers: From Static Context to Distributed Workflows
Before we dive in, let's clarify the stack. Posts 1 and 2 gave you static configuration—hierarchy, CLAUDE.md, basic settings. Post 3 introduced deterministic automation through hooks. Now we're adding the dynamic capability layer.
Think of it this way:
- 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 with role-specific tools)
- MCP Servers (this post): "Here's how to connect to external systems" (Model Context Protocol plumbing)
- Private Marketplace (this post): "Here's where all of this lives" (centralized discovery and distribution)
Each layer builds on the previous one. They don't replace each other; they compose.
Skills: Encoded Team Workflows
A skill is a reusable prompt workflow. You write it once. It lives in your repo. Every developer inherits it.
More technically: a skill is a markdown file with YAML frontmatter, stored in .claude/skills/<name>/SKILL.md. Claude Code scans this directory at startup. When you type /skill-name, or when Claude determines that a skill is relevant to your current task, it invokes the skill automatically.
Here's a real skill example:
---
name: create-pr
description: Create a pull request with tests, documentation, and proper commit messages. Use this after implementing a feature to ensure PRs meet team standards.
compatibility: Requires Git and GitHub CLI
---
# PR Creation Workflow
## Before Creating a PR
1. Verify tests pass: `npm run test`
2. Ensure code is formatted: `npm run lint`
3. Document your changes in the feature branch commit message
## PR Checklist
- [ ] Tests added for new functionality
- [ ] Documentation updated
- [ ] Conventional commit message: `feat: ...` or `fix: ...`
- [ ] No breaking changes (or documented in PR)
- [ ] Performance impact minimal
## PR Title and Description
Use the format:
[Type] Brief description (under 60 chars)
Describes what the PR does, why it's needed, and any risks.
That frontmatter—especially the description field—is the magic. Claude reads it and auto-invokes the skill when relevant. No slash command needed. You describe your feature, and if Claude's description-matching algorithm thinks the skill is relevant, it suggests the skill or runs it automatically.
Why skills matter for teams: A single skill encoded once becomes inheritance. New team members get the workflow without training. Your PR standards propagate. Security reviews scale deterministically.
The tradeoff: You have to keep the skill description honest and specific. Vague descriptions mean Claude won't find them. Overly broad descriptions mean the skill triggers at the wrong time.
Skill vs Command vs Agent: When to Use Each
This distinction matters:
| Concept | Storage | Invocation | AI-Driven | Best For |
|---|---|---|---|---|
| Skills | .claude/skills/*/SKILL.md | /skill-name or auto | Yes | Multi-step workflows, team processes |
| Commands | .claude/commands/*.md | /command (explicit) | Yes | Single-action shortcuts |
| Agents | .claude/agents/ | Auto or /agent name | Yes | Domain experts with isolated context |
Use skills for workflows that span multiple steps: "create a PR properly," "review security," "set up a new database migration." Use commands for quick actions: "format this file," "count lines of code." Use agents for specialized roles.
Agents: Specialized Team Members
An agent is a custom AI assistant with:
- An isolated execution context (different files visible than the main session)
- Role-specific tools (backend agents see different tools than frontend agents)
- Automatic invocation based on agent description (like skills, agents have descriptions)
- Its own system prompt and model choice
Store agents 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: When you spin up a backend agent, it has its own context window. It only sees backend-relevant files. It has its own tool restrictions (maybe it can't access the frontend directory). It can use a cheaper model like Haiku for routine reviews, saving tokens.
Agents are the "team without the people" pattern. Backend team? Spin up a backend agent. Security experts? Encode security-reviewer agent. New developers get access to accumulated expertise without waiting for human code review.
MCP Servers: The Plumbing That Connects Everything
MCP stands for Model Context Protocol. Think of it as the standardized way Claude Code talks to external systems.
You configure MCP servers in .mcp.json or settings.json. Here's an example:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
}
},
"memory": {
"command": "npx",
"args": ["@modelcontextprotocol/server-memory"]
}
}
}
Now Claude Code has access to GitHub (repo operations, issue management, workflow automation) and team memory (shared knowledge across your org). These appear as tools—Claude can invoke them just like Bash or Edit.
Popular enterprise MCP servers include:
- GitHub: PR management, issue creation, workflow automation
- Sentry: Error tracking and diagnostics
- Datadog: Monitoring and observability
- Composio: Single gateway to 850+ integrations (GitHub, Jira, Linear, Slack)
- Supabase: Database operations and authentication
The catch: Tool definitions load at session startup, consuming tokens upfront. If you connect 10 MCP servers, you're consuming token budget just loading their capabilities. Solution: Tool Search (which activates automatically when MCP tool definitions exceed 10% of context) defers tool descriptions until needed, and prefer CLI tools over MCP servers when both can accomplish the same task. git instead of Git MCP server. gh for GitHub instead of GitHub MCP server. Reserve MCP for capabilities with no CLI equivalent.
Building a Private Plugin Marketplace
Now we get to the distribution layer. A plugin marketplace is a catalog that lets you distribute plugins to others. Plugins with different domains can be distributed through a single marketplace while keeping repositories separate. Each plugin can bundle skills, agents, hooks, and MCP configurations 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
The marketplace.json file tells Claude Code what plugins to expose:
{
"plugins": [
{
"name": "create-pr-skill",
"source": "./skills/create-pr"
},
{
"name": "backend-reviewer",
"source": "./agents/backend-reviewer.md"
}
]
}
Auto-Installing the Marketplace for New Team Members
When a new developer clones your repo, you want them to automatically get access to all the team's skills, agents, and hooks. You do this with extraKnownMarketplaces in .claude/settings.json:
{
"extraKnownMarketplaces": {
"team-plugins": {
"source": {
"source": "github",
"repo": "your-org/your-marketplace-name"
}
}
}
}
When they trust the repo folder, Claude Code automatically installs the marketplace. All skills are available. All agents are ready. It's inheritance by default.
Governance: Preventing Marketplace Chaos
The flip side: Marketplaces do not have to be on GitHub, and can be private as long as git clone works with your existing credentials. But they must be private or internal repos—public marketplaces aren't allowed for organization use.
For true governance, use managed settings:
{
"strictKnownMarketplaces": [
{
"source": "github",
"repo": "your-org/approved-marketplace"
}
],
"allowManagedMcpServersOnly": true
}
This says: "Only this marketplace is allowed. No developer can add a new one." If someone tries, they get a clear error message that this is blocked by policy.
The Compounding Flywheel: From Day One to Quarter Two
Here's how this scales in practice:
Week 1: Deploy pre-commit security hook (catches secrets before PR)
Week 2: Create create-pr skill (ensures tests, docs, conventional commits)
Week 3: Build security-scanner agent (reviews code for hardcoded secrets, injection vulnerabilities)
Week 4: Launch private marketplace; all teams inherit the week 1-3 automation
Month 2: Backend team adds db-migration skill (validates migration format, checks for data loss)
Month 2: Frontend team adds react-component agent (reviews component patterns, accessibility)
Month 3: Marketplace has 10+ shared skills; new hires inherit all automation
Quarter 2: Marketplace has 20+ capabilities; onboarding time drops from 3 days to hours
Each skill or agent added benefits everyone retroactively. New teams don't start from zero; they inherit team process. The compounding effect is significant.
A Real Example: The PR Review Skill
Let me ground this in concrete. Here's a create-pr skill that a real team might 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 Format
Use conventional commits. Examples:
- `feat: add user authentication`
- `fix: resolve race condition in cache invalidation`
- `refactor: extract validation logic`
- `docs: update API docs for POST /users`
Multi-line commits:
feat: add email verification
- Send verification email on signup
- Add 24-hour expiration to verification codes
- Block login until email verified
- Add tests for verification flow
## PR Description Template
Your GitHub PR description should include:
**What does this PR do?**
(One sentence: what is the user-facing change?)
**Why?**
(Why is this change needed? What problem does it solve?)
**How?**
(Technical approach: architecture, major changes, trade-offs)
**Testing**
(How did you verify this works? New tests added?)
**Risks**
(Any performance, security, or breaking changes?)
## Creating the PR
```bash
git push -u origin your-branch-name
gh pr create --fill # Uses commit message as template
Post-Creation
Once created, monitor the PR:
- Watch for CI/CD checks (all must pass)
- Respond to reviewer feedback within 24 hours
- Rebase if necessary (but don't force-push after review starts)
A developer reads the skill, follows the checklist, submits a proper PR. No training needed. The workflow is codified.
Better: If you make this skill auto-invocable (with good description), Claude can offer to run it proactively. "I see you've implemented a feature. Should I help you create a PR with tests and documentation?" The workflow becomes muscle memory at the CLI level.
## The Private Marketplace Model: Three Governance Levels
Here's how this works end-to-end:
**Level 1: Individual Developer**
- Personal skills in `~/.claude/skills/` (cross-project)
- Personal agents in `~/.claude/agents/` (cross-project)
- Used for personal utilities: personal coding style, personal debugging workflows
**Level 2: Team/Project**
- Team skills in `.claude/skills/` (committed to git)
- Team agents in `.claude/agents/` (committed to git)
- Team CLAUDE.md with coding standards
- Used by all developers in the repo; inherited on clone
**Level 3: Organization**
- Private marketplace repo with approved skills, agents, hooks, MCP config
- Auto-installed via `extraKnownMarketplaces` in managed settings
- Restricted by `strictKnownMarketplaces` (only approved sources allowed)
- Enforced by managed hooks (`allowManagedHooksOnly: true`)
- Used across all projects and teams
The hierarchy matches the precedence system from Post 1. Personal overrides team, team overrides org. But org policies can be enforced non-overridably (managed settings).
## Why This Matters: The Capability-to-Overhead Ratio
Let's be concrete about the distinctions at play. MCP (Model Context Protocol) provides tool provisioning—the plumbing that connects Claude to external systems. Skills encode how your organization actually works. The distinction is important.
When you encode a workflow as a skill instead of relying on Claude to remember it from CLAUDE.md, you're trading:
- **MCP servers**: Token cost (tool definitions at session startup), but external integration capability
- **Skills**: A few extra tokens for the skill text, but deterministic execution of team patterns
- **Hooks**: Zero context cost, deterministic execution, but limited to input/output transformation
The winning strategy: Use hooks for enforcement (no cost), CLAUDE.md for context, skills for workflows, agents for specialization, and MCP servers only for integrations that have no CLI equivalent.
## Closing: The Infrastructure Layer
Configuration (Posts 1-2) set the stage. Hooks (Post 3) enforced standards. Now skills, agents, and marketplaces turn your team's accumulated knowledge into distribution infrastructure.
When a new engineer joins and runs `claude` for the first time:
- They get your team's coding standards (CLAUDE.md)
- They get your security checks (hooks)
- They get your specialized workflows (skills)
- They get your domain experts (agents)
- They get your enterprise integrations (MCP servers)
All inherited automatically from version control. All non-overridable by managed settings if you need that level of control.
This is where the productivity multiplier isn't just "Claude is faster"—it's "your team is smarter because every member can access accumulated best practices." It's where onboarding becomes hours instead of days. It's where junior developers can tackle problems that previously required senior review.
In [Post 5](https://cutler.sg/blog/2026-03-measuring-claude-code-roi-sme-teams-scaling), we measure the impact. We show how to prove the ROI, navigate the productivity paradox, and scale from pilot to org-wide with real numbers driving decisions.
The infrastructure is in place. Now we measure what it's worth.
---
**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)
Hooks: Deterministic Policy Enforcement for Claude Code Teams
Stop relying on Claude to remember your rules. Hooks make policy enforcement deterministic—every time, no exceptions. Part 3 of the Claude Code Enterprise Stack series.
Building Your First CLAUDE.md: Team Standards as Code
CLAUDE.md is your team's shared playbook—the single file where coding standards, architecture decisions, and Claude Code behaviors live. Done right, it eliminates context-switching and makes Claude Code predictably effective across your entire team.
Why Your Claude Code Configuration Matters More Than Your Model Choice
Enterprise Claude Code isn't about picking the right model—it's about designing a configuration hierarchy that scales from individual workflows to organization-wide policy without friction.