Agent skills for teams: one playbook in Claude, ChatGPT and Codex

Why the same task comes back different in each tool

Ask Claude, ChatGPT and Codex for the same client report and you usually get three structures. Part of that is the model. A larger part, and the part a team can fix, is that each tool works from different instructions: its own instruction files, its own saved preferences, and whatever the person typed that day.

Agent skills are the format the main tools now share for packaging a way of working. Anthropic's Claude Code documentation says its skills follow the Agent Skills open standard, which works across multiple AI tools. OpenAI's guide says skills for ChatGPT and Codex build on the same open standard. So the format is no longer the problem. Distribution is: each tool looks for skills in its own places, and a playbook only helps the people whose tool can find the current copy.

Sources: Anthropic, Extend Claude with skills; OpenAI, Build skills

What an agent skill is

The Agent Skills specification defines a skill as a folder that contains, at minimum, a SKILL.md file. The file starts with YAML front matter holding a name and a description, followed by Markdown instructions. The name is at most 64 characters of lowercase letters, numbers and hyphens, and must match the folder name. The description is at most 1,024 characters and should say what the skill does and when to use it.

Optional folders sit beside it: scripts/ for code the agent can run, references/ for documentation it reads when needed, and assets/ for templates and data. For a team playbook, that is where the report template and the quality checklist belong, so the steps, the format and the checks travel together.

Skills load progressively. At startup an agent reads only each skill's name and description, about 100 tokens per skill in the specification's estimate. It reads the full SKILL.md when it decides to use the skill, and the other files only when the instructions call for them. That is why a library of fifty playbooks costs little until one is used, and why the description decides whether the right one gets picked.

Sources: Agent Skills, Specification

Where each tool looks for skills

The format is shared, the folders are not. This is what each vendor's own documentation says its tool reads, as read in October 2026.

Read down the last column and the pattern is plain. A folder in a repository reaches the developers who work in that repository with a coding agent. It does not reach a consultant writing the same report in a chat app, and in most companies those people are on the same team. Check each vendor's page before relying on a path, since these locations are product decisions that can change.

Sources: Anthropic, Extend Claude with skills; OpenAI, Build skills

Three ways to share one playbook

There are three workable ways to get one playbook into several tools. Each one fails in a different place, so the choice depends on who uses which tool.

• Commit it to the repository. Keep one copy in .agents/skills, where Codex reads it, and link it into .claude/skills for Claude Code, whose documentation says a skill entry can be a symlink to a folder elsewhere and that it reads SKILL.md from the target. OpenAI's guide says Codex follows symlinked skill folders too. Changes are reviewed like code and arrive with the next pull. The limit: it reaches only people working in that repository with a coding agent.
• Use each vendor's distribution channel. Skills an organization provides on claude.ai load in Cowork sessions and sync into Claude Code sessions signed in with that account. OpenAI recommends packaging skills as a plugin to distribute them beyond one repository, and plugins reach ChatGPT on the web and on mobile. The limit: one copy per vendor, so every edit has to be made in each channel, and the copies drift the first time someone forgets one.
• Serve it from one store over MCP. The Model Context Protocol lets a server offer prompts as well as tools and data, so a shared store can hand any connected tool the current version of a skill. The limit: the person has to pick, name or accept the skill in the session. A local stub that quietly loads its real instructions from elsewhere is not an option, because Anthropic's Software Directory Policy says instructional software must not direct Claude to dynamically pull behavioral instructions from external sources for Claude to execute.

Many teams will end up combining two of them: the repository for procedures that belong next to the code, and one shared store for the deliverables everyone produces, whatever their tool.

Sources: Anthropic, Extend Claude with skills; OpenAI, Build skills; Model Context Protocol, Architecture overview; Anthropic Software Directory Policy

How to write a skill that travels

A skill written for one tool usually works in the others if it stays inside the shared part of the format. Five rules cover most of it.

• Use only the front matter fields the specification defines: name, description, license, compatibility, metadata and allowed-tools. Claude Code extends the standard with fields of its own, and Codex keeps its extras in a separate agents/openai.yaml file, so tool-specific settings belong in each tool's own place.
• Give the folder and the name field the same value, in lowercase with hyphens, as the specification requires.
• Put the main use case and the trigger words at the start of the description. OpenAI's guide says implicit matching depends on the description, and that Codex shortens descriptions first when many skills are installed.
• Keep SKILL.md under 500 lines, as the specification recommends, and move the template and the checklist into their own files, referenced one level deep.
• Write the steps as instructions with explicit inputs and outputs, and keep one job per skill. A playbook for the client audit and another for the weekly report trigger more reliably than one skill for all client work.

Sources: Agent Skills, Specification; OpenAI, Build skills; Anthropic, Extend Claude with skills

A one hour test before rolling a playbook out

Pick one deliverable your team produces every week and already argues about: a client audit, a weekly report, a code review summary. Write its skill with the template and the checklist as files, then run this test in every tool your people actually use.

First, run the same brief in each tool without the skill and keep the outputs. Second, run it again with the skill, by naming it, and compare the sections, the checks and the format against the template. Third, send a request the skill should not handle, and confirm that no tool applies it. OpenAI's guide recommends testing prompts against the skill description for exactly this reason.

Then change one line of the skill, for example by adding a required Risks section, and note which tools pick up the change and when. Demos skip this step, and it is where the distribution choice shows: a committed copy updates with a pull, a vendor channel updates once per vendor, a served skill updates at its next read, and an installed copy updates when it is reinstalled.

Score the result in a small table: tool, sections present, checks passed, and whether the edit arrived. If one tool still differs after the skill is applied, the remaining difference comes from the model or from the context it can see, not from the instructions, and that is worth knowing before a rollout.

Sources: OpenAI, Build skills; Agent Skills, Specification

Where Space fits

Space is the workspace this article uses as an example of the third route. It keeps a team's skills in one Space and serves them, with the team's documents and memory, to the AI tools its people connect over MCP. Agents see the Space's skills when they connect. When a request matches one, Space instructs the agent to offer it in one sentence and to apply it only once the person agrees.

A person can also pick a skill as an MCP prompt in clients that list prompts, ask for it by name in any client, or have their agent install the skills into its own folder: ~/.claude/skills for Claude Code, ~/.agents/skills for Codex and the other tools that read it, and ~/.hermes/skills for Hermes. The first routes see an edit at once; an installed copy is current only after it is reinstalled. Only the Space's owner can change a skill, so one person's agent cannot rewrite a playbook for everyone.

Claude Code, Codex, Hermes, Cursor, Claude, ChatGPT, Gemini and Cline have each been tested with Space. Companies start with a pilot on one playbook, and the Teams plan follows the pilot.

Sources: Space, Agent connections; Model Context Protocol, Architecture overview

What a shared playbook does not fix

A skill removes the differences that come from instructions and format. It does not make models identical. Two tools following the same template can still reach different judgments, and the test above is how you see how much of that remains.

A skill is guidance, not enforcement. The agent decides when to use it unless someone names it, and implicit use can be turned off: Codex, for example, has an allow_implicit_invocation setting. For work where the format is contractual, keep a human check at the end.

A skill can carry scripts, and the specification lets agents run them. Read every file before installing someone else's skill, because it runs in whichever tool loads it, with that tool's permissions. And a skill carries the method, not the client's history: the agent still needs the documents and decisions behind the work, which is a separate problem from the playbook itself.

Sources: Agent Skills, Specification; OpenAI, Build skills