Build a Team-Owned AI Skills Library for Claude and Codex

Direct Answer

The best way to share AI skills across a team is to treat them like maintained software, not prompt files. Put the canonical skills in a company-controlled Git repository, package them for the agent clients your team uses, require review and regression examples before release, and give each skill an owner, version, permission boundary, and retirement rule.

Remy Gaskell's setup captures the right organizational shift: a useful process should not live only in one employee's chat history or local folder. The Git repository creates one source of truth, while plugins make those processes installable in Claude Code and Codex. The missing layer is governance. Automatic distribution can spread a bad edit as efficiently as a good one.

Watch Greg Isenberg and AI with Remy

Episode credit: Greg Isenberg. Guest and workflow credit: Remy Gaskell, AI with Remy. Watch the original video on YouTube. The episode contains a Brex sponsorship segment.

A Skill Is an Executable SOP

Remy's definition is useful: a skill is an SOP for AI. Instead of re-explaining proposal structure, brand voice, Notion formatting, or email design in every conversation, the team captures the process in a SKILL.md file. The agent sees the skill name and description, loads the full procedure when relevant, and applies it to the current task.

A skill is more than saved prose when it includes:

• A precise trigger and intended outcome
• Required inputs and approved sources
• Step-by-step procedure and reusable scripts
• Tool and data permissions
• Output format and quality examples
• Failure behavior, escalation, and verification

The skill does not make the model remember everything. It supplies repeatable context when invoked. Its result still depends on the model, available tools, current data, and whether the procedure contains a testable definition of good.

From Single-Player Skills to a Team Supply Chain

This preserves Remy's one-source-of-truth idea without making the repository one undifferentiated folder that every employee installs.

A Repository That Supports Two Agent Clients

team-agent-capabilities/
  plugins/
    brand/
      skills/
        brand-voice/
          SKILL.md
          references/
          examples/
      plugin.json                 # Portable Agent Plugins manifest
      .claude-plugin/plugin.json  # Claude Code adapter
      .codex-plugin/plugin.json   # ChatGPT and Codex adapter
    newsletter/
      skills/
        weekly-research/
        write-draft/
        titles/
  .claude-plugin/
    marketplace.json             # Claude Code marketplace catalog
  tests/
    brand-voice/
    newsletter/
  docs/
    ownership.md
    release-policy.md
    security-review.md
  CHANGELOG.md
  README.md

The exact manifests will evolve, so generate and validate them from current product tooling rather than copying an old snippet. Claude Code currently uses .claude-plugin/plugin.json inside each plugin and a marketplace catalog for distribution. OpenAI currently documents .codex-plugin/plugin.json for ChatGPT and Codex packages. The vendor-neutral Agent Plugins specification defines a portable root plugin.json, skills/, and optional MCP configuration.

That means the honest portability claim is: one repository and one skill source can support multiple clients, with small adapters and separate validation. Hooks, admin deployment, permission models, update timing, and connected tools are not automatically identical.

The Minimum Skill Contract

Remy's "thin agents, thick skills" principle is valuable because workflow knowledge loads only when needed. Thick should mean complete and testable, not bloated. Move long references and examples into supporting files, keep the discovery description precise, and make each section earn its context cost.

What Deserves to Become a Skill?

Do not convert every chat into company infrastructure. Score candidate work on five factors:

1. Frequency: Does the task recur enough to recover maintenance cost?
2. Stability: Is the process understood, or are people still discovering the job?
3. Variance: Do different teammates produce inconsistent results?
4. Value and risk: Would better execution save time, protect quality, or reduce a meaningful mistake?
5. Verifiability: Can the output be checked with examples, rules, tests, or a human rubric?

Start with three to five workflows such as proposal drafting, brand-voice transformation, formatted research briefs, release notes, or a read-only weekly report. Avoid high-stakes skills with unclear ownership, unstable policy, regulated data, or irreversible actions until the review system is mature.

Split a workflow into a chain only when a subtask is useful independently, needs different permissions or models, or has its own acceptance test. Remy's YouTube example makes sense as separate research, titles, thumbnails, and descriptions because each component can run alone. Otherwise, a chain creates more handoffs than value.

Move Skills From Sandbox to Company Asset

1. Capture. A teammate turns a repeated successful workflow into a candidate skill in a personal or experimental repository.
2. Sanitize. Remove customer data, credentials, local paths, private examples, and copyrighted material the company cannot redistribute.
3. Specify. Add the owner, trigger, inputs, permissions, outputs, failure behavior, and acceptance examples.
4. Review. Open a pull request. A domain owner checks process quality; a technical reviewer checks scripts, hooks, MCP servers, and dependencies.
5. Test. Run representative happy paths, edge cases, wrong inputs, and a previous known failure on every supported client.
6. Pilot. Release to a small group with narrow permissions and a defined rollback point.
7. Promote. Tag a stable version, publish the changelog, and make the plugin available to the intended roles.
8. Observe. Measure accepted results and corrections, then review after a defined number of runs.
9. Retire. Archive skills that are unused, duplicative, broken, unowned, or superseded.

This is a safe independent starting brief, not Remy's exact downloadable prompt. His supplied setup is linked in the sources.

What Is Portable Across Claude Code and Codex?

The Agent Plugins 1.0 standard deliberately standardizes packaging and discovery for skills and MCP servers, not marketplaces, permissions, runtimes, or every client extension. That is why the repository should preserve a portable core while documenting the adapters.

Auto-Update Needs Release Discipline

Remy correctly emphasizes auto-update because duplicate local copies create drift. The practical behavior is more measured than an instant push. Claude Code can refresh third-party marketplaces and installed plugins at startup when auto-update is enabled; a reload may be needed before the current session uses the new version. Third-party marketplace auto-update is not enabled by default. In managed Codex and ChatGPT workspaces, plugin availability and app permissions depend on admin policy, role, surface, and propagation.

Use three channels:

• Pilot: latest approved commit for two or three experienced users.
• Stable: pinned release that passed the cross-client test matrix.
• Archived: previous known-good version retained for rollback and audit.

Every release should state what changed, why, affected skills, required permissions, migration needs, test evidence, and rollback version. Git history allows restoration, but rollback is only fast when the team knows which deployed version each client is running.

Let Skills Propose Improvements, Not Rewrite Themselves

Remy adds a reflection section to each skill: after a run, identify failures, workarounds, user corrections, and information a future run may need. That is a strong learning loop if the output is a proposal.

1. Capture the exact failure or correction with a redacted input and expected output.
2. Classify it as one-off preference, missing example, process defect, tool change, or permission problem.
3. Draft the smallest patch and add a regression fixture that fails before the change.
4. Run the skill against existing examples to detect regressions.
5. Have the skill owner approve and release the change through the normal pipeline.

Do not let a production skill silently edit its own instructions after every user correction. A local workaround can conflict with another team's use case, weaken a safety boundary, or encode sensitive data into the shared repository.

Measure Skills Without Turning the Team Into a Leaderboard

Remy's usage hook can reveal which skills are active, idle, or missing from expected workflows. Useful telemetry includes:

• Skill name and version
• Invocation count and completion status
• Accepted result, correction, or escalation
• Latency and approximate model or tool cost
• Client used and failure category

Do not log prompts, customer content, generated documents, credentials, or full tool payloads by default. Tell employees what is collected and why, minimize individual attribution, define retention, restrict access, and provide a correction path. The goal is to improve the library, not rank people by how often they invoke AI.

GitHub Custody Is Not the Whole Ownership Story

A company-organization repository provides continuity when a teammate leaves, an audit trail for changes, and a recoverable backup. It does not independently establish intellectual-property ownership. Employment and contractor agreements, third-party licenses, attribution, confidentiality rules, and contribution policy still matter.

Treat plugins as software supply-chain artifacts. A plugin may contain instructions, scripts, hooks, MCP server definitions, and connections to external systems. Before adopting an Internet skill or plugin:

• Review every file and dependency, not only the README.
• Scan for secrets, data exfiltration, destructive commands, and untrusted download steps.
• Pin the reviewed version or commit for stable deployment.
• Keep first use read-only and limit apps to approved accounts and sources.
• Require confirmation before sending, publishing, purchasing, deleting, or modifying sensitive records.
• Revoke access and rotate credentials during offboarding.

OpenAI's current plugin controls preserve the permissions of underlying apps and source systems. Claude Code provides marketplace allowlists, blocks, managed settings, and private repositories. Use those controls; a private repository alone does not prevent an over-permissioned skill from causing damage.

A 14-Day Team Rollout

Video Chapters

Final Verdict

Remy's system solves a real problem: valuable AI workflows should not disappear with a laptop, a long chat, or an employee departure. A company repository, plugin packaging, and version history turn private tricks into reusable organizational capability.

The durable advantage is not the number of Markdown files. It is the feedback loop: a teammate discovers a better way to work, the improvement becomes a reviewed skill patch, tests prove it still works, a staged release reaches the right roles, and the whole team receives a better process without surrendering control.

Build the library slowly enough to trust it. Three owned, tested, portable skills will create more leverage than 150 local files nobody can review, update, or safely invoke.

Sources and Credits

• Greg Isenberg and Remy Gaskell: How I Use Skills + AI Agents to Run My Life
• Remy's prompt and skill setup supplied with the episode
• Remy Gaskell on X
• AI with Remy
• Anthropic: Create Claude Code plugins
• Anthropic: Create and distribute a plugin marketplace
• Anthropic: Plugin versioning and distribution reference
• OpenAI: Package a plugin for ChatGPT and Codex
• OpenAI: Plugins, workspace roles, apps, and permissions
• Agent Plugins 1.0: portable skills and MCP packaging
• Agent Plugins: compatible clients and supported components
• Late Checkout Agency
• The Vibe Marketer