Cross-agent operations
Manage skills across Claude Code, Codex, and Cursor
Claude Code, Codex, and Cursor can all work with reusable skills, but “supported” does not mean “kept in sync.” A durable team setup separates the shared skill source from each agent’s installation and discovery rules.
- Publisher
- Skills Board
- Published
- Updated
Core principle
One canonical source. One visible recommendation. Explicit setup for every agent path.
Quick answer
To share skills across Claude Code, Codex, and Cursor, keep one canonical SKILL.md source and document how each agent installs, discovers, and invokes it. Test every agent path with the same fixture, then share the compatibility record. Do not maintain separate canonical copies or assume updates sync automatically.
The problem behind the query
Mixed-agent teams usually fail in one of two ways: they maintain three unrelated skill collections, or they assume one folder will behave identically everywhere. The safer model is one canonical artifact, one team recommendation record, and a thin, tested adapter for each agent surface.
01 / Decision
Standardize the layers, not every implementation detail
The common layer is the skill’s purpose, source, owner, and SKILL.md workflow. Agent-specific installation, discovery, invocation, and administrative controls remain explicit adapters that your team verifies against current vendor documentation.
| Layer | Team standard | Agent-specific adapter |
|---|---|---|
| Skill artifact | One canonical SKILL.md plus versioned scripts, templates, and references. | Confirm which bundled resources and extensions each agent supports before rollout. |
| Discovery | One shared recommendation record explains when the skill should be used. | Claude Code, Codex, and Cursor can expose skills differently by product, version, workspace, or project. |
| Installation | Keep the reviewed source and intended version stable. | Document the current supported install or access path for each agent instead of inventing a universal command. |
| Invocation | Use the same task fixture and expected output in compatibility tests. | Record whether the skill is selected automatically, invoked explicitly, or constrained by local settings. |
| Updates | Review changes at the canonical source and publish one new recommendation state. | Refresh or reinstall through each tested agent path; portability alone does not perform this step. |
02 / Workflow
A cross-agent rollout that stays understandable
Pilot one skill across the three agents before generalizing the process. The goal is to expose differences early and keep them in a small compatibility record.
- 01
Choose one representative workflow
Pick a skill with a clear input and reviewable output, such as release-note drafting or a code-review checklist. Avoid a first pilot that depends on many private tools or broad write permissions.
Output: One narrow workflow and one reusable test fixture.
- 02
Normalize the portable core
Keep purpose, trigger, inputs, procedure, output format, and final checks in SKILL.md. Put templates, examples, and scripts beside it so the source remains inspectable and versioned.
Output: A canonical skill directory with a stable source URL.
- 03
Create three small setup notes
For Claude Code, Codex, and Cursor, link the current official instructions and record only the settings or locations your team actually uses. Do not duplicate the full skill to create the notes.
Output: One concise adapter note per agent and environment.
- 04
Run the same fixture in every agent
Use the same input, expected sections, and pass/fail checks. Record meaningful differences in discovery, permissions, tool access, output, and invocation behavior.
Output: A compatibility matrix based on observed results.
- 05
Publish the team recommendation
Point teammates to the canonical source, explain the recommended use case, and expose only the agent paths that passed. A shared library makes this discoverable without pretending to be a universal installer.
Output: One searchable recommendation with tested use paths.
- 06
Update source first, adapters second
Review changes at the canonical source, repeat the fixture, then refresh each agent path. If one agent fails, mark that path needs-review rather than forking the skill silently.
Output: One version history and explicit per-agent lifecycle states.
Skills Board field protocol
Cross-agent skill discovery and instruction-transport fixture
Use this public fixture to test whether one documented agent path can discover a named SKILL.md and transport a nonce-bearing instruction into a fresh session. The protocol publishes the method and blank record only; Skills Board is not claiming a result for Claude Code, Codex, Cursor, or any other agent.
- Protocol version
- 1.0
- Published
- Evidence status
- Protocol only — no results claimed
What the fixture measures
- Pins the product version, environment, setup documentation, fixture hash, and test date for one path.
- Uses two fresh sessions and two private run nonces to check named-skill discovery and literal instruction transport.
- Publishes fixed pass, partial, fail, and not-run criteria plus a blank evidence record.
What it cannot establish
- It does not test automatic selection, scripts, tools, commands, file access, network access, or side effects.
- It does not evaluate permissions, sandboxing, secret handling, open-ended output quality, or bundled resources.
- If the product does not expose provenance, the nonce proves that the payload reached the session—not which internal discovery mechanism loaded it.
- A result applies only to the recorded product version, environment, and setup path—not every client or future release.
- A pass for this fixture cannot certify another skill as safe, correct, portable, or team-approved.
Reproducible method
01
Pin the path
Record the exact product version, interface, operating system, workspace scope, vendor setup URL, and access date.
02
Prepare the fixture
Copy the published SKILL.md, replace its placeholder with a new 128-bit-or-longer nonce, and hash the installed file.
03
Keep the nonce out of context
Expose the fixture only through the documented setup path. Do not paste the receipt or nonce into the conversation.
04
Run a fresh session
Send the protocol's exact invocation prompt and retain the full response plus any observable discovery or invocation signal.
05
Repeat independently
Start another fresh session with a different nonce, the same setup path, and a new fixture hash.
06
Apply fixed criteria
Mark pass only when both runs return their exact one-line receipts. Preserve partial, fail, and not-run outcomes.
Inspect, copy, and cite the complete protocol.
The public Markdown file includes the fixture SKILL.md, exact prompt, pass criteria, blank result record, and version history.
Make the recommendation findable
Skills Board keeps the source, install path, notes, and team recommendation in one searchable library.
It does not pin or control upstream files or silently synchronize every agent. Your team sees the source, chooses the path that fits each setup, and re-reviews upstream changes.
03 / Record
The compatibility record
Keep this beside the recommendation. It records evidence, not a timeless promise: agent behavior and supported setup paths can change.
- Canonical version
- Commit, tag, or reviewed source state used in the test.
- Agent and environment
- Claude Code, Codex, or Cursor plus the relevant workspace, CLI, editor, or project context.
- Setup path
- The official installation or access instructions the tester followed.
- Invocation
- Automatic selection, explicit invocation, or another observed trigger.
- Fixture result
- Pass, partial, or fail against the same expected output and checks.
- Reviewed at
- Date, owner, and reason to retest after a source or agent change.
04 / Pitfalls
Cross-agent shortcuts to avoid
Assuming format means synchronization
A shared SKILL.md reduces duplication, but it does not automatically install, update, or enable the skill in every agent environment.
Maintaining three canonical copies
Agent folders should consume or reference the reviewed source. If each copy evolves independently, the team no longer knows which behavior it approved.
Publishing untested compatibility badges
Support claims should name the tested environment and date. A vendor announcing skill support is not evidence that your specific scripts and permissions work there.
Hiding agent-specific differences
Different discovery and invocation rules are normal. Small adapter notes are cheaper and clearer than forcing a misleading universal setup.
05 / Checklist
Ready to share with the team?
- One canonical skill source is shared across all three agent paths.
- The portable workflow is separated from agent-specific setup notes.
- Every compatibility claim names an observed environment and review date.
- The same fixture and pass/fail checks were used for each agent.
- A failed agent path can be paused without forking the canonical skill.
- The team can discover the recommendation without knowing its install location in advance.
Primary sources
Editorial method: Skills Board synthesizes the first-party and standards sources cited below into a practical workflow. Product behavior can change, so verify the linked sources before rollout.
- OpenAI: Skills in ChatGPT
Explains the reusable and shareable skill model, the open standard, and support across OpenAI products including Codex.
- Anthropic: Extend Claude with skills
Documents Claude Code skill files, project and personal discovery, invocation controls, and sharing patterns.
- Cursor 2.4: Skills support
Announces Agent Skills in Cursor editor and CLI, using SKILL.md files with instructions, scripts, and commands.
- GitHub: About agent skills
Confirms Agent Skills as an open standard used across multiple AI systems and documents shared repository locations.
- Skills Board: Cross-agent skill compatibility fixture
Version 1.0 of the dated, reproducible discovery and instruction-transport protocol. It publishes fixed criteria and a blank record, with no agent results claimed.
More resources
Keep exploring
Give the next teammate one trusted place to start.
Save the reviewed skill, document the path that works, and keep the recommendation visible to the whole team.