How Skills Drift

A team worked across several product repositories. The team had spent last quarter's refinement sessions shaping its review skill, adding checks for migration rollback strategies and other conventions agreed in the room. The updated skill lived in one repo. Older copies sat in the others, never refreshed since they had been copy-pasted months earlier. An engineer who had joined the team after those sessions was reviewing merge requests in one of the repos still holding the older skill. The skill looked like the team's current standard. It was last quarter's.

Nobody was wrong. The new joiner was running the version of the skill that lived in the assigned repo. The standards had been agreed in a room and committed to one repo. The others still held the older version. Current practice lived with the team members who had been in the room. The repos held last quarter's. The new joiner was working from yesterday.

This is not a new problem. Editor configs drift, lint rules drift, formatters drift. The reason it matters more for Claude Code is that the artifact is no longer cosmetic. A skill changes what code Claude writes. A subagent changes which tools it can call. A hook changes what runs around every tool call. When the team's setups diverge across repositories, the model's outputs diverge with them, and you find out the next time the team crosses repos.

Why Dotfile Sharing Fails Here

Four patterns recur in teams that run Claude Code across multiple repositories. They are not surprising in isolation. What is surprising is that they all have the same fix.

Drift between teammates. The same skill, two versions, no diff to compare. Recommendations contradict. The team lead becomes the human source of truth, which means knowledge is one resignation away from a rebuild.

Onboarding cost. A new engineer joins mid-engagement and reconstructs the team's setup by scrolling chat history and asking, "what skills are you all using?" There is no canonical bundle to install. The first day is artisanal.

Skills bound to a project repo. A useful skill written for project A becomes friction for project B. Reuse means copying files, fixing relative paths, and remembering which version is the good one. The team's AI infrastructure ends up shaped by the project where each piece happened to be written, not by the team's collective practice.

No governance. Someone adds a hook that runs a secret scanner before file writes. Useful. Also unreviewed. Two weeks later you discover the regex has a false negative, and another teammate has been quietly leaking values past it.

A plugin marketplace closes all four. The marketplace is a git repository. Every artifact lives in code, every change goes through review, every teammate runs /plugin marketplace update and gets the same versions. The pattern is not new: teams that hit these problems often build a hand-rolled version (a shared dotfiles repo, a setup script, a wiki of conventions). The marketplace is the formal mechanism.

Marketplace vs Repository

A clean separation of concerns falls out of this. Skills, subagents, and hooks encode "how the team works" and stay constant across the projects the team touches. They belong in the marketplace, project-agnostic, installed once and available everywhere. Rules encode "what this system is" (the tech stack, the file structure, the conventions of this codebase) and belong in the project repository, in its own .claude/ directory.

The convenient mistake is to put a useful skill in the project repo where you happened to write it. The skill stops being reusable, starts accumulating project-specific assumptions, and forces a copy-paste when you start the next project. By the time you have two projects, you have two copies. They drift against each other for the same reason every shared artifact drifts: there is no canonical source.

The marketplace prevents the mistake by giving "team artifacts" a different home from "project artifacts." A skill that lives in the marketplace can be used on every codebase the team works on without modification. A rule that lives in a project repo stays where it is needed, scoped to the system it describes.

What Stays Human

The marketplace gives the team a versioned, reviewable AI setup. What goes in stays with the team.

One reviewed bundle beats copies that drift. The team can see what's in it. That's what lets them think about it.

This argument is not Claude-specific. The same separation applies to any agentic CLI: team conventions in a versioned, project-agnostic bundle; project rules in the repository. Claude Code is one implementation, ergonomic and easy to ship. Tools like opencode let you go further by routing different parts of the workflow to different LLMs: a cheaper model for routine commits, a stronger reasoner for architecture review, a local model for sensitive code. The architecture stays the same. The implementation gets more granular and more hyper-optimized.

If your team has three or more people running AI coding assistants, you have a drift problem whether you have named it yet or not. Publish a marketplace. The payoff is more than consistency: it is a single source of truth for how the team works, accessible to anyone who can run a command. What used to be four different assistants on four different machines becomes one shared bundle. Versioned. Reviewable. Installed once.