How I Stopped Duplicating AI Skills Across Claude Code, Cursor, Codex, Gemini CLI, and Other Tools

Has anyone else ended up maintaining the same AI skill in multiple places?
I use Claude Code, Codex, Cursor, Gemini CLI, Kimi, and several other AI tools.
Over time, I accumulated a huge collection of skills and workflows.
The annoying part wasn't creating them.
It was keeping them synchronized.
A skill would exist in one format for Claude Code, another for Cursor, another for Gemini, and so on.
Eventually, I got tired of duplicating everything and built an open-source project called AI Omni Skills.
The idea is to keep a single source of truth and generate the formats required by different AI tools.
Now I update a skill once and regenerate whatever structure a specific tool expects.
I'm curious:
How are you managing skills today?
Are you duplicating them across tools?
What integrations would you want to see?
Repo: https://github.com/moatazhamada/ai-omni-skills

Comments

[Alex Shev]

Shared skills across tools are going to matter more than tool loyalty. The real asset is the operating procedure: constraints, checks, examples, and stop conditions. Rewriting that for every IDE or CLI is pure drag.

[Moataz Mohamed]

Spot on. The AI tool is just the execution layer; the operating procedure and constraints are the actual IP.

I built and just open-sourced Omni Skills to solve this exact "drag." It lets you treat skills like infrastructure: you write your core logic, checks, and stop conditions once, and the toolkit automatically compiles them into the native formats each specific IDE or CLI expects (Claude, Cursor, Codex, etc.).

Since you're curating over at Terminal Skills, I'd love to hear your thoughts on the architecture!

[Alex Shev]

That compile-to-native layer is exactly the right direction. The hard part is keeping one source of truth for the skill while preserving each tool's safety model: stop conditions, allowed tools, review points, and what counts as done.

[Moataz Mohamed]

You're highlighting the exact friction point the community is focused on right now. Another developer on Reddit just brought up this same challenge regarding the execution boundary.
Right now, Omni Skills pushes those safety models and allowed tools into the per-tool integration config. But based on this feedback, the next major architectural step is adding a formal capability-mapping layer to the canonical wrapper itself.
The goal is to let you explicitly declare the "intent" alongside the "hard safety constraints" in the source of truth, and let the compiler handle enforcing those boundaries natively for each tool.

[Alex Shev]

Capability mapping in the canonical wrapper sounds like the right direction. The useful boundary is not only which tool is allowed, but why it is being invoked and under what constraints. If that intent survives compilation into each runtime, the safety model becomes much easier to audit.

[Moataz Mohamed]

Exactly. Making the safety model auditable is the whole endgame here.

I actually just shipped this capability mapping layer into the core compiler based on this exact discussion! The canonical SKILL.md now uses YAML frontmatter to explicitly define the executionBoundary (disabled capabilities, required human confirmations, stop conditions). The compiler ensures that intent survives translation into the native formats.

To take the auditability a step further, I also wired in an optional pre-sync hook for NVIDIA SkillSpector, so developers can automatically scan these boundaries for injection vulnerabilities before they ever reach the IDE.

Really appreciate you helping shape the architecture on this!

[Alex Shev]

That is a great direction. The frontmatter boundary makes the safety model inspectable before the skill is translated, which is where a lot of drift usually enters. I especially like the pre-sync hook idea because it turns security from a review ritual into a compilation step. The open challenge is keeping those boundaries small enough that humans still read them.