I work at Google Cloud but use Claude Code for most of my development work. When both platforms launched extension systems in October 2025 (Claude Skills and Gemini CLI Extensions), I had a thought:

Why can’t these be the same thing?

Both platforms independently arrived at the same solution to the same problem. They just chose different implementation formats. That doesnt’ sound huge. But that fragmentation creates unnecessary cognitive load for anyone building extensions or choosing between platforms.

Here’s what I learned after building the same extension for both platforms, and why I think the two leaders in this space should standardize on a single format.

What Skills and Extensions Actually Are

Before we talk about the problem, let’s be clear about what these things do.

Skills and Extensions aren’t just wrappers around data sources. They solve a bigger problem: How do you teach an AI assistant to solve specific types of problems using specific workflows?

Take my agent-benchmark-kit as an example. It’s a Claude Skill that helps create and run benchmarks for AI agents. There’s no MCP server. No database connections. No external APIs.

It’s pure implementation context:

  • “Here’s how to create test suites by asking 5 questions”
  • “Here’s the evaluation rubric format”
  • “Here’s how to score agent output against ground truth”
  • “Here’s when to rotate tests as agents improve”

The skill provides knowledge, patterns, and workflows. It teaches Claude how to approach a problem in a consistent manner.

That’s different from MCP. MCP provides access to datasources (databases, APIs, file systems). Skills and Extensions provide the context and integration patterns to use those datasources effectively.

Some Skills use MCP servers. Some don’t. Both are valuable.

The Fragmentation Problem

Here’s where it gets frustrating.

Claude Skills and Gemini CLI Extensions solve the exact same problem. They both provide:

  • Discovery mechanisms (how the AI finds available extensions)
  • Implementation context (how to solve specific types of problems)
  • Integration patterns (how to use tools effectively)
  • Progressive disclosure (load context only when needed)

But they’re completely incompatible. You can’t take a Claude Skill and use it in Gemini CLI. You can’t take a Gemini Extension and use it in Claude Code.

The fragmentation hurts everyone.

Not because the code is hard to write. The code isn’t the problem.

The problem is cognitive load. Maintaining two parallel implementations for the same good idea is heavier than sharing that idea needs to be.

As someone who leverages both platforms, I feel this too often. I have great workflows in Claude. I want to test them in Gemini. But I can’t just copy a skill. I have to re-implement it as an extension with different manifests, different discovery, different configuration patterns.

The functionality is identical. The value is identical. Only the packaging differs.

That’s wasted mental energy that could be spent improving the actual implementation. It’s yum vs. apt all over again (no Coke or Pepsi for this Linux nerd - It’s Diet Pepsi all the way).

MCP Is Part of the Solution (But Not All of It)

The Model Context Protocol is an open standard that Anthropic introduced in November 2024. It defines how AI assistants communicate with external tools and data sources.

MCP is important because it provides universal access to datasources:

  • One PostgreSQL MCP server works with Claude, Gemini, and (soon) GitHub Copilot
  • One Google Docs MCP server works across all platforms
  • One file system MCP server works everywhere

That’s powerful. Instead of building platform-specific integrations, you build one MCP server and it works everywhere.

But MCP isn’t the whole story.

MCP handles the “how do I access this data” problem. Skills and Extensions handle the “how do I use this data to solve specific problems” problem.

Example: You could have an MCP server that provides access to Google Analytics data. That’s useful. But a Google Analytics Extension would also include:

  • Common analysis patterns (“compare this month to last month”)
  • Report templates (“show me a standard SEO report”)
  • Best practices (“here’s how to interpret bounce rate”)
  • Integration workflows (“pull this data and format it for a blog post”)

The MCP server gives you raw access. The Extension gives you the knowledge layer on top.

Both platforms recognize this. That’s why both have Extensions/Skills systems alongside MCP support. They’re solving different problems at different layers.

The opportunity is to standardize the Extension/Skill layer, not just the MCP layer.

I Tried Building the Same Extension Twice

To understand the fragmentation problem firsthand, I built a PostgreSQL database query helper that works as both a Claude Skill and a Gemini CLI Extension.

The repository structure tells the story:

database-query-helper/
├── .claude-plugin/
│   └── marketplace.json          # Claude discovery
├── SKILL.md                       # Claude entry point
├── GEMINI.md                      # Gemini entry point
├── gemini-extension.json          # Gemini discovery
├── shared/
│   ├── reference.md               # Shared documentation
│   └── examples.md                # Shared examples
└── mcp-server/
    └── index.js                   # Shared MCP implementation

85% of the code is identical. The MCP server, the documentation, the helper scripts, all shared. Only the discovery and configuration differ.

But here’s what that 15% difference means in practice:

When I update the extension, I don’t update one file. I update:

  • The shared implementation (once)
  • The Claude manifest (separate update)
  • The Gemini manifest (separate update)
  • The Claude entry point (separate update)
  • The Gemini entry point (separate update)

That’s 5 mental contexts for every change. Not because the logic is complex, but because the packaging is incompatible.

When I want to add a new feature:

  • Do both platforms support this capability?
  • How do I configure it in each manifest?
  • How do I document it in both entry points?
  • How do I test it in both environments?

The cognitive load scales with the number of platforms, not with the complexity of the implementation.

If I wanted to support a third platform, that’s 3x the mental overhead. Four platforms? 4x.

This is the problem standardization solves. Not “write less code” but “maintain fewer mental models.”

How Other Platforms Handle This

The fragmentation isn’t unique to Claude and Gemini. Every AI coding platform faces the same problem: how do users extend functionality?

GitHub Copilot launched GitHub App-based extensions in February 2025, then deprecated them in November 2025 in favor of MCP. Not because GitHub Apps were bad, but because maintaining a proprietary format when an open standard exists didn’t make sense.

VS Code Extensions have been around for years with a well-established format. But those are IDE extensions, not AI assistant extensions. Different problem space.

Cursor and Windsurf both support MCP servers but don’t have Skills/Extensions-like systems yet. They’re still figuring out how to package implementation context effectively.

The pattern is clear: every platform is building toward the same solution, just with different formats.

MCP is getting adopted for datasource access. Extensions/Skills are emerging for implementation context and workflows. But everyone’s doing it slightly differently, creating unnecessary fragmentation.

This is exactly the kind of scenario where industry standardization makes sense.

What Standardization Would Look Like

Imagine if Claude Skills and Gemini Extensions used the same format.

Not the same implementation. Platforms can still compete on discovery, curation, and integration quality. But the same packaging format.

One entry file instead of SKILL.md and GEMINI.md. One manifest instead of marketplace.json and gemini-extension.json. One mental model instead of learning two parallel systems.

Extension developers would:

  • Write the extension once
  • Publish to both platforms from the same repository
  • Maintain a single mental model
  • Focus cognitive energy on improving functionality, not managing packaging

Users would:

  • Install extensions the same way on both platforms
  • Keep their extensions when switching platforms
  • See better quality (developers can focus on making extensions better instead of maintaining parallel versions)

Platforms would still compete on:

  • Core product quality (Claude’s UI vs Gemini’s terminal experience)
  • Discovery and curation (how users find extensions)
  • Integration patterns (how extensions work with platform features)
  • Performance and reliability

The standardization removes the cognitive overhead of fragmentation without removing the competition that drives innovation.

This is co-existence, not consolidation.

Why This Probably Won’t Happen (But Should)

I’m realistic about the odds here.

Both Anthropic and Google have incentives to maintain differentiation. Skills and Extensions are still new (launched October 2025). Neither company wants to give up control over their extension format.

There are legitimate technical reasons for differences:

  • Claude’s progressive disclosure model vs Gemini’s upfront loading
  • Different configuration needs (environment variables vs interactive prompts)
  • Platform-specific capabilities that don’t map 1:1

And there’s the NIH (Not Invented Here) factor. It’s hard to standardize when you believe your format is better.

But here’s the thing: Anthropic already proved the value of open standards by creating MCP. Google adopted it. GitHub migrated to it. The industry is converging.

The same logic applies to Skills and Extensions. They solve the same problem. Both formats are good. The fragmentation is unnecessary.

If Anthropic and Google announced a joint working group to define a universal extension format, the entire industry would follow. They’re the two leaders in this space. Their cooperation would establish the standard.

It would be co-existence, not capitulation. Both platforms would continue to compete on product quality. But extension developers and users would benefit from reduced cognitive load.

That’s what makes this frustrating. The solution is obvious. The benefits are clear. The leadership exists.

It just requires both companies to prioritize interoperability over differentiation for this one piece of the stack.

What This Means Right Now

Until standardization happens (if it happens), here’s the reality:

If you’re building extensions:

  • Accept that you’ll need platform-specific wrappers
  • Use the database-query-helper repository as a template for dual-platform support
  • Separate shared implementation from platform-specific packaging
  • Manage the cognitive load by keeping manifests and entry points as thin as possible

If you’re choosing platforms:

  • Don’t pick based on extension ecosystems (they’re both too new)
  • Choose based on core product quality and your specific workflow needs
  • Expect extension portability to improve over time (but don’t count on it yet)
  • Be ready to re-implement your favorite extensions if you switch platforms

If you work at Anthropic or Google:

  • Consider the value of co-existence through standardization
  • Look at how MCP adoption benefited the entire industry
  • Remember that competition on core product quality is more sustainable than fragmentation
  • Think about the cognitive load you’re creating for developers who use both platforms

The window is still open. Skills and Extensions are both less than a month old. Now is the time to standardize before ecosystems diverge further.

Conclusion

Claude Skills and Gemini Extensions solve the same problem. Both provide implementation context, integration patterns, and workflows that make AI assistants more useful for specific tasks.

The fragmentation between them creates unnecessary cognitive load. Not because the code is hard to write, but because maintaining parallel implementations is harder than sharing a good idea needs to be.

Anthropic and Google are the two leaders in this space. Both have shown willingness to adopt open standards. MCP proves that. Both could easily standardize on a single extension format and be interchangeable while continuing to compete on core product quality.

That’s the opportunity: co-existence through standardization.

MCP standardized datasource access. Extension/Skill formats could standardize implementation context. Platforms would still compete on discovery, curation, integration quality, and user experience.

But extension developers and users would benefit from reduced cognitive load, better portability, and a healthier ecosystem.

The window is still open. Both systems launched in October 2025. They haven’t diverged too far yet. Now is the time to standardize before the ecosystems split further and entrenchment makes it politically impossible.

I’m not holding my breath. But I am hopeful.

Because the alternative (fragmenting a good idea across incompatible platforms) hurts everyone. Maybe I’ll make a cross-platform Skill/Extennsion (Skill-stenstion?) that creates cros-platform Skill/Extensions (workshopped Skill-stention, I didn’t like it).

Want to see the code? Check out the database-query-helper repository showing how I built the same extension for both platforms.

Want to learn more about MCP? See the official specification and servers registry.