OpenSkills vs Universal Skills: The Battle for an Open AI Skills Ecosystem

The Problem: Skills Locked to One Platform

Claude Code introduced skills—reusable knowledge modules that teach AI agents specialized workflows. Want PDF manipulation? Install the PDF skill. Need spreadsheet editing? There's a skill for that. Skills bundle instructions, scripts, templates, and references into progressively-loaded packages that keep your agent's context clean.

The problem? Skills only worked in Claude Code. If you used Cursor, Windsurf, Continue, or any other AI coding tool, you were locked out. The format was proprietary, the marketplace was closed, and the ecosystem was fragmented.

This is where the open skills movement began. Two projects emerged with the same mission: make Claude skills work everywhere. But they chose different paths.

OpenSkills: The CLI Approach

OpenSkills takes a straightforward approach: replicate Claude Code's skill system exactly, but make it work via command-line interface instead of a built-in tool. It's the closest implementation matching Claude Code's skills system—same prompt format, same folder structure, same SKILL.md format, same progressive disclosure.

npm install -g openskills
openskills install anthropics/skills

# In Claude Code: Skill("pdf") tool
# In OpenSkills: openskills read pdf CLI

.claude/skills/
  pdf/
    SKILL.md
    references/
    scripts/
    assets/

The SKILL.md Format

OpenSkills uses the exact same SKILL.md format as Claude Code. It's a YAML frontmatter header followed by markdown instructions:

---
name: pdf
description: Comprehensive PDF manipulation toolkit for extracting text and tables, creating new PDFs, merging/splitting documents, and handling forms.
---

# PDF Skill Instructions

When the user asks you to work with PDFs, follow these steps:

1. Install dependencies: `pip install pypdf2`
2. Extract text using the extract_text.py script in scripts/
3. For bundled resources, use the base directory provided in the skill output
4. ...

[Detailed instructions that Claude/agent follows]

Key Features of OpenSkills

Why CLI Instead of MCP?

This is the key philosophical difference. OpenSkills deliberately chose CLI over MCP (Model Context Protocol). Here's why:

The argument is that MCP and skills solve different problems. MCP is for dynamic, real-time integrations. Skills are for static, reusable knowledge modules. OpenSkills implements Anthropic's skills spec the way it was designed—as progressively-loaded markdown instructions.

Universal Skills: The MCP Approach

Universal Skills takes a different path. Instead of replicating Claude Code's system, it extends Claude's Skills feature to any AI coding agent that supports MCP (Model Context Protocol). It treats skills as a standardized protocol that can be shared across platforms.

The MCP Advantage

Universal Skills' approach has several advantages:

The MCP Tradeoff

The MCP approach comes with tradeoffs:

Comparing the Approaches

Both projects aim for the same goal—making Claude skills work everywhere—but their approaches reveal different philosophies about how to achieve interoperability.

When to Use OpenSkills

When to Use Universal Skills

The Philosophical Divide

The difference between OpenSkills and Universal Skills isn't just technical—it's philosophical. They represent two visions for how AI tool interoperability should work.

Both approaches are valid. Both solve real problems. The question isn't which is "better"—it's which fits your needs and aligns with your vision for the ecosystem.

Why an Open Ecosystem Matters

This isn't just about two tools competing. It's about something bigger: the future of AI-assisted development. An open skills ecosystem matters for reasons that go beyond technical convenience.

1. Preventing Vendor Lock-In

Without an open ecosystem, you're locked into whatever platform you choose. Your skills, workflows, and knowledge investments are tied to a single vendor. If that vendor changes direction, raises prices, or shuts down, you lose everything.

Open skills mean your investments are portable. Switch from Claude Code to Cursor? Your skills come with you. Try a new tool? Same skills. This freedom is critical for long-term planning.

2. Accelerating Innovation

When skills are open, the community can build on each other's work. Someone creates a PDF manipulation skill. Someone else extends it with OCR capabilities. A third person adds batch processing. Innovation compounds.

Closed ecosystems slow this down. Every improvement has to go through the vendor. Every feature request waits in a queue. Open ecosystems let the community move at its own pace.

3. Reducing Redundancy

How many times have developers recreated the same PDF manipulation workflow? The same spreadsheet editing patterns? The same debugging techniques? Without an open ecosystem, everyone reinvents the wheel.

Open skills create a shared knowledge base. One person solves a problem, everyone benefits. This is how ecosystems should work.

4. Enabling Specialization

Not everyone needs to be an expert in everything. A frontend developer shouldn't need to master PDF manipulation to extract data from a document. A backend developer shouldn't need deep spreadsheet knowledge to process CSV files.

Open skills let specialists create tools for non-specialists. The PDF expert builds the PDF skill. The spreadsheet expert builds the spreadsheet skill. Everyone uses them without needing to understand the internals.

5. Building Trust Through Transparency

Closed ecosystems are black boxes. You don't know what the skill does, how it works, or whether it's safe. Open skills are transparent. You can read the instructions, audit the scripts, verify the behavior.

This transparency builds trust. Developers can use skills with confidence, knowing they understand what's happening. This is especially important for security-sensitive workflows.

6. Creating a Level Playing Field

In a closed ecosystem, the vendor controls what skills exist, which ones are promoted, and how they're distributed. This creates power imbalances. Vendors can favor their own tools, suppress competitors, or charge premium prices.

Open ecosystems democratize access. Anyone can create skills. Anyone can distribute them. The best skills win based on merit, not vendor relationships.

The Path Forward: Can They Coexist?

The good news? OpenSkills and Universal Skills don't have to be competitors. They can coexist and even complement each other.

The real win would be if both projects continue to evolve, each serving their niche, while maintaining compatibility with the core SKILL.md format. This would give developers choice without fragmentation.

What This Means for Developers

As a developer, you now have options. You're not locked into a single platform's skill system. Here's how to think about it:

Conclusion: The Ecosystem Wins

The emergence of OpenSkills and Universal Skills isn't a competition—it's validation. It proves that Claude skills are valuable enough that the community wants to make them universal. That's a win for everyone.

Both projects are pushing toward the same goal: an open ecosystem where skills work everywhere, knowledge is shared, and developers aren't locked into platforms. They're just taking different paths to get there.

The movement toward open skills is just beginning. As more developers discover the power of skills, as more tools adopt skill formats, and as the ecosystem matures, we'll see even more innovation. That's exciting.

Try both. See which fits your workflow. Contribute to whichever resonates with you. Most importantly, support the movement toward openness. The future of AI-assisted development depends on it.

npm install -g openskills
openskills install anthropics/skills