PowerUp Coaching — Living Knowledge Base

Insight: Plugins Are How You Share Skills — Version-Controlled Capabilities From a Marketplace Repo

4 min read

“It turns out plugins is kind of the way that Claude and Codex want you to inherit code from a common repository. The repo is version controlled, so if I update a skill and it breaks your packaging, you just specify the previous version.” — Lou

Session context: 2026-06-11_Mastermind — Lou reported the dead ends he hit trying to share a single canonical skills library across many projects, and the mechanism that finally worked.

Core Idea

The goal: keep every skill in one canonical place, and let each project pull in only the few it needs — without duplicating skills into every project, and without loading all 50–60 skills’ front matter into context on every query. Lou tried two approaches that failed:

  • A manifest (a JSON file listing needed skills, with CLAUDE.md instructed to read it and load their front matter) — works, but doesn’t integrate with Claude’s native /slash invocation. You have to name and invoke the skill as a file, which is less than ideal.
  • Symlinks — fail because Claude doesn’t reliably follow a symbolic link to its destination the way macOS does. Not 100% of the time, so not usable.

What worked: plugins from a marketplace. This is the path Claude (and Codex) actually intend for inheriting capabilities from a common repository. You set up a Git repo, define a marketplace manifest, and publish plugins — either one plugin per skill, or a bundle (e.g. a “writing team” plugin holding 5–6 related skills). A project then declares “install these plugins,” and only those capabilities show up — Lou’s read is that a plugin loads only the front matter of its skills, so a tightly-scoped plugin stays cheap on context.

Two structural wins fall out of this:

  • Version control. The repo is versioned, so if an upstream skill update breaks your packaging, you pin the previous version and keep working. Capabilities get a dependency-management discipline that manifests and symlinks never had.
  • Distribution. A marketplace repo isn’t just for organizing your own skills — it’s the clean way to share skills with clients. You hand them a link; they install the plugin.

There’s a tradeoff Lou flagged honestly: because the manifest/file approach doesn’t surface under /, you have to consciously invoke it — which is arguably better, since it means a project’s skills don’t silently interfere with everything else. The open question he’s still chasing is making plugin skills appear in the / menu like native ones.

Practical Application

If you’re maintaining skills across multiple projects, stop copying them around and stop reaching for symlinks. Instead:

  1. Put all shared skills in one version-controlled Git repo.
  2. Add a marketplace manifest and define plugins — one per skill, or bundle closely-related skills (a writing team, an onboarding pipeline) into a single named plugin.
  3. In each project, install only the plugins that project needs.
  4. When you ship to a client, give them the marketplace link instead of a folder of files — and tell them which plugin to install.

Bonus gotcha from the same session: the skill-creator tool tends to fill the 1024-character description limit, and 20 skills at ~1,000 chars each is ~20K of wasted context. When generating a skill, instruct it to keep the front-matter description tight — a couple of trigger keywords and a one-to-two-line description.

Evolution Across Sessions

Directly advances Insight - The Harness Architecture — Declare Only What You Need, Import the Rest (2026-06-04), which proposed a central library + per-project declaration to solve the token tax. This session reports the implementation reality: the homegrown manifest and symlink routes don’t integrate with native invocation, and the supported path is plugins published through a marketplace repo — bringing version-pinning and client distribution as bonuses.

Graph View

Backlinks