Where to place skills to be used in different LLM providers?

[Nikola-Milovic]

It seems that every single IDE/ CLI agent tool is using different place to store skills, is there a centralized place where I can place the skills so they're available to ANY AI system?

Claude uses .claude, codex uses .codex, gemini and cursor something else

[Somesh45das]

each provider tends to define its own convention for storing skills or configs, and at the moment there isn’t a single universal folder that all systems read from. A practical approach is to keep your skills in a neutral directory under version control and then use small sync or symlink scripts to copy/link them into the provider‑specific locations. That way you maintain one source of truth but still satisfy each tool’s expectations. If a standard ever emerges, it’ll likely build on this idea of a shared repo with adapters for each provider

[Omrigotlieb]

I don’t think there is one universal filesystem location that every agent product reads today.

Anthropic’s own skills repo points to Agent Skills as the open format, and the repo README explicitly says the same skills ecosystem can be used across Claude Code, Claude.ai, and the API. So the portable unit is the skill package/format, not a single shared folder path.

Practical pattern:

• keep skills in one source repo,
• author them against the Agent Skills format,
• then install/sync/symlink them into each tool’s discovery path.

So: portable format, yes; universal on-disk folder, not really.

[Nikola-Milovic]

I built a tool for this myself.

https://github.com/frmlabz/omnidev

Since I came to the same conclusion that it wasn't possible

[chasewhughes]

This is one of the most important unsolved problems in the agent tooling ecosystem right now. @Omrigotlieb's answer is correct — there is no universal folder, and the portable unit is the skill format, not the filesystem path. But let me add some context on where this is heading.

Why this hasn't been solved yet:

Each tool (Claude Code, Codex, Cursor, Gemini) has its own discovery mechanism because they each have different runtime assumptions:

• Claude Code reads from .claude/ and uses SKILL.md with YAML frontmatter
• Cursor reads from .cursor/rules/
• Codex reads from .codex/
• Windsurf reads from .windsurfrules

These aren't just different folder paths — they have different schema expectations, different trigger mechanisms, and different assumptions about what a "skill" can do (some are just prompt templates, others can execute code).

The practical solution today (what works right now):

Keep a single source of truth and generate/symlink per-tool:

.ai-skills/                    # your canonical skill source
├── code-review/
│   ├── skill.md               # the actual content
│   └── metadata.yaml          # tool-agnostic metadata
├── testing/
│   └── skill.md
└── sync.sh                    # generates tool-specific copies

The sync.sh script transforms your canonical skills into each tool's format:

#!/bin/bash
# Sync skills to each tool's expected location

# Claude Code
cp -r .ai-skills/*/skill.md .claude/skills/

# Cursor  
for skill in .ai-skills/*/skill.md; do
    name=$(basename $(dirname $skill))
    cp "$skill" ".cursor/rules/${name}.md"
done

# Codex
cp -r .ai-skills/*/skill.md .codex/

Where this should go (the real answer):

What the ecosystem needs is a skill manifest standard — a single skills.json or skills.yaml at the project root that every tool agrees to read:

# .ai-skills.yaml (hypothetical universal manifest)
version: 1
skills:
  - name: code-review
    path: .ai-skills/code-review/skill.md
    triggers: ["review", "code review", "PR review"]
  - name: testing
    path: .ai-skills/testing/skill.md
    triggers: ["test", "write tests"]

This is the same pattern that solved the equivalent problem in other ecosystems — .editorconfig for editor settings, tsconfig.json for TypeScript, .tool-versions for runtime versions. Someone needs to propose and champion it, and enough tools need to adopt it.

The Anthropic Agent Skills format is the most complete skill schema today (YAML frontmatter, trigger descriptions, structured content). If it gets adopted by even one other tool, it becomes the de facto standard. @Nikola-Milovic your omnidev tool is attacking the right problem — the translation layer between formats is the interim solution until convergence happens.

[Nikola-Milovic]

Yeah, and to add, omnidev does a lot more. It handles also the versioning and security aspects of skills. Since nothing currently prevents script injection nor hidden characters from being downloaded with things like skills.sh

[naimkatiman]

Great question — I've actually solved this in practice while building continuous-improve, a skill that installs across 5 different agents (Claude Code, Codex, Cursor, OpenClaw, and ChatGPT).

The short answer: There is no universal folder. But you can have a single installer that targets all of them.

What I did (working solution)

My skill has one npm package with an install script that auto-detects which agent you're using and writes to the correct location:

# Auto-detect and install
npx continuous-improve install

# Or target specific agents
npx continuous-improve install --claude    # → .claude/skills/ + CLAUDE.md
npx continuous-improve install --codex     # → codex.md
npx continuous-improve install --cursor    # → .cursor/rules/
npx continuous-improve install --chatgpt   # → copies to clipboard as custom instructions

The key insight: each agent has different expectations, not just different paths:

Agent	Path	Format
Claude Code	.claude/skills/<name>/SKILL.md	YAML frontmatter + markdown
Codex	codex.md in project root	Plain markdown rules
Cursor	.cursor/rules/<name>.md	Markdown instructions
ChatGPT	Custom Instructions field	Plain text

Architecture that works

my-skill/
├── skills/my-skill/SKILL.md    ← canonical source (Anthropic format)
├── prompts/                     ← agent-specific variants
│   ├── claude.md
│   ├── codex.md
│   ├── cursor.md
│   └── chatgpt.md
└── scripts/install.js           ← writes to correct location per agent

The Anthropic Agent Skills format (YAML frontmatter + markdown) is the most structured, so I use that as the canonical source and generate simpler variants for other agents.

@Nikola-Milovic your omnidev approach is solid for the symlink/sync pattern. The installer approach works better when you're distributing to other people (they just run npx and it works).

I agree with @chasewhughes that a universal skills.yaml manifest would solve this properly — similar to how .editorconfig unified editor settings. Until then, the "single source + multi-target installer" pattern is the most practical.

---

See it in action: before vs after

Before (agent without discipline):

After (agent with continuous-improve installed):

Install: npx continuous-improve-skill — works with Claude Code, Codex, Cursor, and ChatGPT.
Repo: naimkatiman/continuous-improve-skill

[jmaxzh]

[Nikola-Milovic]

I built and use this now https://github.com/frmlabz/omnidev

[Bl4c-kr]

Everyone in this thread has converged on the same answer — one canonical source,
then sync or symlink into each tool's discovery path — and I think that's right.
I want to add the failure mode that comes after you adopt it, because nothing here
covers it and it cost me real time.

cp -r is one-way and silent. Nothing verifies the copies still match.

The sync scripts in this thread copy on demand. They do not tell you when one copy
has since been edited and the others have not. Skills are markdown, so nothing
errors — the agent simply loads whichever root it reads, and a rule you believe you
installed is not in effect for that runtime.

I hit this last week. An isolation rule was added to
~/.agents/skills/<name>/SKILL.md and never propagated to
~/.claude/skills/<name>/SKILL.md. Zero errors. The Claude runtime had been running
without the rule for a day, and the only reason I found out was a separate registry
check I run at session start.

Two things make this checkable, and neither needs a model call:

1. Compare content, not names. A multi-runtime setup has a lot of same-name
   duplicates and almost all of them are fine. Hash each skill's body and split:
   same name + same digest is an intentional projection (dedupe it, say nothing);
   same name + different digest is the finding. In my setup that ratio is 16 harmless
   to 1 real. A name-only check buries the one that matters.

2. Say "unknown" when you mean unknown. If a root is unreadable or absent, that
   is not "no conflicts" — report it as unchecked. I have been burned twice by health
   output that printed a green "N/N OK" while silently dropping the checks whose
   probe had failed.

Concretely, what I run before each session:

skill registry — 29 effective / 45 projected
- conflicting duplicates: 1
- identical projections: 15 (deduped for routing)
  FAIL conflicting skill: <name>

Why a check rather than more written guidance: Gloaguen et al. (ETH Zurich /
LogicStar.ai, arXiv:2602.11988) evaluated repository-level context files and found no
statistically significant improvement in task success, with inference cost and step
count up more than 20% — largely because the files duplicate documentation the agent
already has. Adding a paragraph to a context file telling the agent to keep copies in
sync is exactly the kind of instruction that costs tokens and changes nothing. A
digest comparison is deterministic and runs in milliseconds.

If a universal manifest does eventually land (as suggested upthread), the same
argument applies to it: a manifest that lists paths still needs something that checks
the paths still agree.

[fabianmartinelli-fm]

The thread has converged on paths, and I agree with the canonical-source pattern. The part that bit me was not the path, it was the frontmatter.

Claude Code extends the Agent Skills standard with fields of its own (disable-model-invocation, context, disallowed-tools, allowed-tools). They work locally, but the other distribution paths for the same file do not accept them: packaging with package_skill.py, claude.ai uploads and the Skills API allow only name, description, license, compatibility, metadata and allowed-tools, and reject the rest with Unexpected key(s) in SKILL.md frontmatter. So a sync that copies one canonical SKILL.md everywhere fails on the header before it fails on the path. Whatever does the projection has to strip fields per target.

Second thing worth knowing if your sync concatenates skill content into an entry file: Codex caps project docs at project_doc_max_bytes, 32 KiB by default, and drops everything past it silently. No error, nothing in a log. I measured one repo where the agent was receiving about 10% of that file, and another at 19.1%, cut mid-sentence. A sync script crossing that line looks exactly like a sync script that worked.

And one target just went away: since Claude Code 2.1.277 it reads AGENTS.md directly when there is no CLAUDE.md in the working directory or above it. The docs have the full resolution table. Worth noting that a local CLAUDE.local.md counts for that check, so one developer keeping personal notes silently stops reading the team's AGENTS.md, and nothing reports it.

I ended up packaging the measurement side of this as a skill: https://github.com/fabianmartinelli-fm/harness-audit

[SebastiaanBoon]

Agreeing with the canonical repo plus sync pattern. One gap in it: every variant in this thread assumes the tool has a project folder to copy into. The chat apps (claude.ai, the mobile apps) have no .claude/skills on your disk, so a symlink never reaches them, and that is usually where people end up re-typing the same instructions.

What worked for me is a second delivery path next to the sync one: keep the canonical rules and step-by-step routines as plain markdown in a private repo or cloud folder, and serve that same folder through a remote MCP server. Coding agents get it through the files on disk, chat apps get it through the connector, and there is still only one place to edit. Two details that matter:

1. Keep the routines as plain markdown without tool-specific frontmatter. Then the same file can be copied into a skills folder or read through a connector without a conversion step.
2. Let the connector expose a small set of read and write calls (list files, read a file, append to a log), so an assistant can update the notes itself instead of you copying them back.

Disclosure, I built a hosted version of this: Cloud Alter Ego stores rules, profile, project journals and playbooks as plain files in your own OneDrive, Google Drive, Dropbox, GitHub or Azure DevOps and adds a connector in Claude (https://cloudalterego.cafeboon.com/docs.html). The open source template, which uses the same plain-file layout with hooks for coding agents, is at https://github.com/SebastiaanBoon/cloud-alter-ego. You can also build the connector part yourself, the idea does not depend on my service.