Accept Claude Skills Like Code

By Rogier Muller06.24.26

For Claude Code treat skills as shared team conventions, not personal snippets. Before a skill spreads, give it an owner, a CLAUDE.md boundary, permission notes for hooks and MCP, and a small review rubric.

A Claude Code skill is a reusable package of instructions and supporting files that teaches Claude how to do a specific kind of work. This is the practical answer for teams evaluating Claude Code skills during a Claude Code training or workshop rollout: make the skill boring, reviewable, and easy to remove.

Start with the convention, not the skill

Use the June 23, 2026 Claude Code 2.1.187 changelog as a reminder to tighten team habits whenever the product surface changes. The changelog is the source of truth for what shipped; your repo convention is the source of truth for how your team adopts it.

The useful team move is simple. When someone proposes a skill, ask what workflow it standardizes, what repo rules it depends on, and what it must never do.

For example, a backend team might want a skill for writing migration PRs. That skill should know the migration template, test command, rollback note, and reviewer expectation. It should not learn those rules from a one-off prompt pasted into chat.

Don't treat skills like a private productivity hack. That works for a day. Then two engineers use two different versions, reviews get noisy, and nobody knows whether the skill is safe to run on a hot path.

Put durable context in CLAUDE.md

Keep durable team context in CLAUDE.md, and keep the skill focused on the repeatable task. CLAUDE.md is Claude Code memory for repo rules, architecture notes, test commands, and team conventions that should apply across sessions.

A good pattern is root memory for global rules and nested memory for local constraints. In a monorepo, the root CLAUDE.md might say that all PRs need tests and a short risk note. A nested services/billing/CLAUDE.md might add payment-specific invariants and migration rules.

Here is a small fragment a team could actually use:

# CLAUDE.md

## Team review rules
- Prefer small PRs with one behavioral change.
- Before editing database code, inspect existing migrations and rollback patterns.
- Run the narrowest relevant test first, then the package test if behavior changed.
- Every PR summary must include: what changed, tests run, and rollout risk.

## Skill adoption
- Skills are proposed by the team that owns the workflow.
- A skill cannot override repository review rules.
- Any skill that calls external systems must document its MCP server and permission boundary.

Don't put task-specific prompting into CLAUDE.md. If the rule only matters for one workflow, put it in the skill. If it should guide every Claude Code session in the repo, put it in memory.

For a wider rollout pattern, pair this with Team conventions, especially if you are turning individual habits into Claude Code conventions for a team.

Gate integrations with hooks and MCP

Treat integrations as a boundary, not a convenience. Model Context Protocol, usually shortened to MCP is the integration layer that lets Claude connect to external systems such as GitHub, Slack, Jira, databases, documents, and internal tools.

That power needs a house rule. A skill that only formats a changelog is low risk. A skill that reads production logs, comments on GitHub issues, or queries customer data needs explicit permission notes and a reviewer who understands the system.

Hooks help here because they can enforce workflow checkpoints around tool use. A team might use a hook to require tests before a commit command, block edits in generated files, or remind Claude to include a risk note before opening a PR.

Watch for bundling MCP access into a skill with no adoption review. Discovery can feel like a Claude Code skills marketplace, but installation is not governance. Your team still needs to decide who owns the integration, what data it can touch, and how failures are handled.

Copy the skill acceptance convention

Use this as the one-page gate before a Claude skill becomes a team default. Paste it into your engineering handbook, a docs/team/claude-skills.md file, or the PR template for your internal skill repository.

# Claude Skill Acceptance Rubric

## Skill proposal
- Skill name:
- Owning team:
- Primary workflow:
- Replaces which repeated prompt, script, or checklist:
- First repo or package where it will be used:

## Activation quality
- The skill has a clear name that matches the job it performs.
- The description says when to use it and when not to use it.
- The first instruction tells Claude what outcome to produce.
- The skill references repo conventions instead of duplicating long CLAUDE.md rules.

## Safety boundary
- Required tools are listed.
- MCP servers are listed, with read/write scope.
- Hooks that may run before or after the workflow are listed.
- The skill does not request broad file, network, or external-system access unless the owner explains why.

## Review expectations
- The skill includes a sample prompt and expected output shape.
- The skill names the tests or checks Claude should run.
- The skill tells Claude what evidence to include in the PR summary.
- A human reviewer can tell whether the skill succeeded without reading the whole session.

## Adoption decision
- Pilot owner:
- Pilot duration or number of uses:
- Repos approved for use:
- Rollback plan if the skill causes noisy or unsafe work:
- Date accepted:
- Date to re-review:

The adoption path should be lightweight. The workflow owner proposes the skill, one engineer from the affected code area reviews it, and the team stores it beside the repo conventions it depends on.

The review rule is even simpler: no skill becomes a default until a reviewer can name the permission boundary and the evidence expected in a PR. If the skill delegates to agents, add a second review for agent scope; this subagent conventions guide is a good companion.

Keep the rollout small and reversible

Pilot a skill in one repo, one workflow, and one team before calling it standard. Claude Code for teams gets easier when the convention can survive normal review pressure, not just a demo.

A good first pilot is something repetitive but bounded. Try release note drafting, test failure triage, migration PR prep, or API client update checks. Each has a clear output and a reviewer who already knows what good looks like.

Watch for starting with a powerful cross-repo automation skill. Those can be useful later, especially in Claude Code enterprise environments, but they need stronger permissions, clearer ownership, and a rollback plan.

A practical starter checklist:

Pick one workflow with a known reviewer.
Write the skill description before the instructions.
Add the relevant CLAUDE.md rule instead of pasting repo lore into the skill.
Name every MCP server the skill may use.
Add one hook boundary if the workflow needs enforcement.
Require a PR summary with tests, risk, and files touched.
Re-review after five real uses or two weeks, whichever comes first.

Common questions

Can hooks enforce skill behavior?

Hooks can enforce parts of the workflow, but they should not hide unclear conventions. Use hooks for crisp boundaries such as blocking generated-file edits, reminding for tests, or shaping commit behavior. Keep the human-readable reason in CLAUDE.md or the skill so reviewers understand what the hook is protecting.

Try this next

Pick one workflow your team already repeats weekly and run it through the rubric before writing a new skill. If the boundary is unclear, fix the convention first; Claude can only follow the operating model you give it.