# AI Skill Portability The ability for an [[AI Agent Skills|AI skill]] to work across different AI platforms, tools, machines, teams, and organizations without modification. Today, skills written for [[Claude Code]] don't work in [[Cursor.com]], [[Cline]], or [[Windsurf]] without adaptation. This is the vendor lock-in problem for prompts. Portability is not just about tools. A skill should work on all your machines, for every developer on your team, for an entire organization, and ideally for anyone on earth. It should also survive switching AI models and providers. See [[AI Interoperability]] for the broader principle and [[AI Skill Resilience]] for the design practices that make portability possible. ## Why portability matters - **Investment protection**: time spent building a skill library shouldn't be lost when switching tools - **Cross-machine consistency**: your skills should work identically on every machine you own, not just where you wrote them - **Team flexibility**: team members using different tools, OSes, or setups should be able to share skills - **Org scalability**: skills deployed at [[Enterprise Context Management (ECM)|enterprise scale]] can't assume one specific environment - **Model/provider freedom**: skills shouldn't break when you switch from Claude to GPT to Gemini or to a local model via [[Ollama]] - **Market health**: lock-in discourages skill sharing and slows ecosystem growth ## What makes skills non-portable - **Tool-specific syntax**: Claude Code uses SKILL.md with specific frontmatter; Cursor uses [[Cursor Rules]] with different conventions; other tools have their own formats - **Tool call assumptions**: skills that reference specific tool names (Read, Bash, Glob) break in tools with different tool APIs - **Hardcoded paths and structures**: absolute paths, hardcoded folder names, or OS-specific conventions break on other machines (see [[AI Skill Resilience]]) - **Model-specific prompt tricks**: techniques that exploit one model's behavior but fail on others - **Context loading conventions**: how skills get loaded into context varies (auto-loaded, on-demand, plugin-based) - **Runtime capabilities**: some tools support subagents, MCP, or background tasks; others don't - **Environment assumptions**: expecting specific OS, shell, installed binaries, or API keys without checking ## The portability spectrum | Level | Description | |-------|-------------| | **Intent-portable** | The goal and approach transfer; rewrite the syntax per tool | | **Content-portable** | The core prompt text works anywhere; only metadata/wrappers change | | **Format-portable** | A standard format that multiple tools understand natively | | **Fully portable** | Drop a skill file into any tool and it works | Today most skills are at the intent-portable level. The ecosystem is slowly moving toward content-portable through Markdown-based conventions. ## Toward portability - Standardized skill metadata (name, description, triggers, dependencies) - Tool-agnostic prompt bodies with tool-specific wrappers - [[Context-as-Code]] conventions that multiple tools adopt - Open skill packaging formats (emerging, not standardized yet) ## References - ## Related - [[AI Skill Portability Checklist]] - [[AI Agent Skills]] - [[AI Agent Portability]] - [[AI Interoperability]] - [[AI Skill Resilience]] - [[AI Skill Distribution]] - [[AI Skill Composability]] - [[AI Skill Versioning]] - [[AI Skill Scoping]] - [[Claude Code Skills]] - [[Claude Code Plugins]] - [[Cursor Rules]] - [[Context-as-Code]] - [[AGENTS.md (File Convention)]] - [[Loose Coupling]] - [[Convention over Configuration]] - [[Pure Function]]