Jonathon's AI Wiki

Distributing Team Skills as a Plugin Marketplace

9 min read

Source: raw/How_I_Use_Skills_+_AI_Agents_to_Run_My_Life.md — Greg Isenberg’s Startup Ideas podcast with Remy (“AI with Remy”), ~35 min (https://www.youtube.com/watch?v=xHsftiyT9pQ)

A working answer to a problem the wiki has documented the shape of but not the fix for: skills are individually valuable and organisationally stranded. Remy’s diagnosis is that “AI is very much single player” — every teammate has their own Claude or Codex setup, and a good skill built on one machine stays there. His fix is to put the skills in a GitHub repository, register the repository as a plugin marketplace, and let auto-update do distribution. The mechanics are already documented in Plugins and Marketplaces; what is new here is using them as a team knowledge-distribution system rather than a way to install someone else’s tools.

Key Takeaways

  • “We’re in the Microsoft Word era of skills.” The analogy is exact: valuable documents living on individual machines, mailed around as copies, with no central source of truth. Google Docs solved it for documents; a repo-as-marketplace solves it for skills.
  • The two obvious approaches both fail. Zipping a skill into Slack creates duplicates that never receive upstream fixes and never send improvements back. Google Drive / Dropbox / Obsidian sync fails harder — Claude reads only its own skills directory, so a synced folder needs symlinks, and symlinks break the moment a non-technical teammate is involved.
  • One repo, department sub-plugins. The marketplace is the app store; each plugin is an app. Splitting skills by department (brand, content, newsletter, marketing, finance, general) means a copywriter installs the copywriting plugin and never sees the finance skills.
  • Auto-update is load-bearing, and it is a per-installer setting. If a teammate does not enable it, they are back to a frozen copy. This is the single most likely silent failure in the whole system.
  • Portable across harnesses. Remy runs the same repo as a plugin in both Claude Code and Codex, with the same skills appearing in both. Other harnesses untested.
  • Two repos, not one: a company team-skills repo inside the GitHub organisation, and a personal repo for sandbox and personal skills (inbox triage, morning brief) that would not make sense to roll out. The org-ownership point is deliberate — skills an employee builds stay with the company when they leave.
  • The backup argument is a real incident, not a hypothetical. “Claude deleted my Claude folder with 150 skills, with probably 500+ hours of work in it, and I had no backups.” A remote repo is the defence — and it is also what lets cloud agents (his example: Hermes on a VPS) reach the same skills.
  • Every SKILL.md ends with a self-improvement loop. A short block appended to the bottom of each skill that asks, at the end of every run, whether any step failed or needed a workaround, whether the user corrected or rejected anything meaningful, and whether anything was discovered a future run would need — proposing a change only if it clears a bar. The human accepts or rejects; accepted changes rewrite the skill.
  • “Thin agents, thick skills.” Keep agent instruction files lean; put the detail in the skills. Then any harness can run the skill and get the same result. (Credited on the episode to another creator whose name the auto-caption garbles — attribution unverified.)

Setup

  1. Create a GitHub repository and push your skills into it, grouped into folders by department.
  2. Add the JSON manifest files that make the repo a marketplace and each folder a plugin. Remy’s own position on this is the useful part: “I don’t have a clue at all how it works. I don’t need to. I just got Claude to set it up for me.” Point Claude at your existing skills folder and ask it to produce the repo-and-plugin structure.
  3. Register it: in Claude Code, /plugin → Marketplaces → Add marketplace → paste the GitHub repo URL.
  4. Install the department plugins each person needs, and enable auto-update on every install.
  5. Repeat in Codex if your team uses both.
  6. On Claude Enterprise, use organisation plugins instead — the CTO or technical founder publishes once and it is baked into everyone’s account, so non-technical staff never open a terminal or run a slash command.

Why this beats a shared folder

ApproachCentral truthPropagates editsVersion historyWorks for non-technical staff
Zip via Slack/emailNoNoNoPartly
Drive / Dropbox / Obsidian syncYesYes, butNoNo — needs symlinks into the skills dir
GitHub repo as marketplaceYesYes, with auto-updateYesYes, especially via org plugins

The version-history column is not decoration. Remy’s stated reason for wanting it is that a teammate can degrade a shared skill, and reverting is then a git operation rather than an archaeology project.

The improvement loop is bidirectional

The example he gives is the whole argument for the system. A team member, Harold, was building an email in Resend using the shared email-formatting skill, hit an image-upload error, worked out the fix with Claude, and updated the skill. Remy received that update automatically on his next run. One person’s debugging became everyone’s default.

Combined with the per-skill self-improvement footer, the result is a skills library that ratchets: agents propose refinements at the end of each run, humans accept or reject, and accepted changes distribute.

Skill chains, and when to split

Remy’s rule for one-skill-versus-a-chain: split when you would ever want to run a sub-process on its own. His YouTube publish workflow is an orchestrator skill that calls titles, thumbnails, and descriptions in sequence — split that way because there are days he wants only thumbnails.

His threshold for creating a skill at all is low and mechanical: “anytime I’ve done a task with Claude and I know I’m going to need to do it again, I’ll just tell Claude ‘turn this into a skill’.” The claim behind it is that any non-physical business process can be automated with a good skill or a chain of them.

The dashboard layer (optional, and the interesting part)

Remy built a web app on top of the repo — the repo is the backend, the app is the view. Three features worth stealing:

  • A skill graph. Which skills call which. Orchestrator skills and their children are visible, which is how a new hire discovers what exists.
  • An ask box that searches the private skills library in natural language — “what are the best skills for decision-making,” or “I’ve done the weekly research, what should I run next,” which returns the correct next link in the chain.
  • A usage bar driven by a plugin hook. Every skill invocation fires a hook that tallies the run, per skill and per team member. The stated purpose is not gamification (though he jokes about a year-end wrapped) but culling: show me every skill nobody has touched in six months so the stack does not bloat. Greg’s addition — “also show me the skills I’m not using that I should be using.”

The usage-tracking hook is the piece the wiki has not seen before: it makes skill libraries measurable, which is the prerequisite for pruning one.

Named third-party skill sources

The episode names several public skill libraries as starting points rather than building from zero: Corey Haynes’s marketing skills, “the boring marketer“‘s marketing skills, an LLM council skill, and Matt Pocock’s “grill me” interview skill (the auto-caption renders it “Matt PCO” — see his repo, already documented here). Remy’s discipline is to install third-party skills into his personal repo first, and only promote them to the team repo once he trusts them.

Try It

  1. Pick your three highest-frequency formatting tasks — the ones where you repeat the same preferences every time. Remy’s own three were Notion doc formatting, brand voice, and transactional email formatting. Those are the first three skills.
  2. Ask Claude to convert your skills folder into a repo-plus-marketplace. Do not hand-author the manifests; this is the step the source explicitly says you do not need to understand.
  3. Split by department from the start. Retrofitting the split after everyone has installed one monolithic plugin means re-onboarding the whole team.
  4. Verify auto-update is on for every single teammate. Make it part of the install instructions, and re-check it — a stale install is invisible until someone’s output silently diverges.
  5. Append the self-improvement footer to every skill you already have. Four questions: did any step fail or need a workaround, did the user correct or reject anything meaningful, did you discover something a future run needs, is the change worth proposing.
  6. Build the repo inside your GitHub organisation, not a personal account — the ownership argument only works if the org owns it.
  7. Add the usage hook before the library gets big. Counting from skill five is easy; reconstructing six months of usage at skill 150 is not.

Open Questions

  • The manifest contents are never shown. The episode says a “couple of little JSON files” turn the repo into a marketplace and defers to a prompt in the show notes. Plugins and Marketplaces carries the actual schema; the two should be read together.
  • Codex plugin parity is asserted, not demonstrated in detail. He shows the skills listed in Codex and runs one; whether every Claude Code plugin feature (hooks especially) carries over is untested. Other harnesses are explicitly untested.
  • The usage-tracking hook is one day old at recording. No data yet on whether the per-member tallies survive auto-updates or how they are aggregated across machines.
  • “Thin agents, thick skills” attribution. Credited to another creator whose name the auto-caption garbles. The principle is recorded; the attribution is not.
  • No cost figures. The claim that “a good skill can save you literally two hours a week” is an estimate offered without measurement.

Graph View

Backlinks