I was browsing GitHub late last week and stumbled on something that made me stop scrolling: a repo from Kepano (Obsidian core team) called obsidian-skills, shipping five agent skills designed to work identically across Claude Code, Codex, and OpenCode. Not “works best with Claude” with a duct-taped adapter for the others — natively portable, following the Agent Skills spec (agentskills.io) from day one.
The immediate reaction was “oh, neat, Obsidian CLI integration.” But the actual story here isn’t about Obsidian. It’s about what happens when a software company decides to publish skills as a vendor-agnostic portable unit instead of locking them to a single agent platform. This is a small, concrete example of something I’ve been wrestling with for months in my own OpenClaw setup: skills are becoming the reusable governance and procedure unit for AI agents, and portability is starting to matter in the same way it did for npm packages or browser extensions.
Why This Matters Right Now
I run a multi-agent OpenClaw fleet where each agent is configured with specific skills — one handles Slack triage, another manages GitHub PRs, a third does security audits. Those skills encode our procedures: how to prioritize a ticket, what to check before merging, which Slack channels to never auto-respond in. They’re not just “prompts with extra steps” — they’re institutional knowledge packaged as runnable code.
The problem: every skill I write is currently Claude Code-specific. If I wanted to switch a subset of agents to a different platform (say, Codex for a particular workflow where its tooling is stronger), I’d need to rewrite or heavily adapt every skill. That’s the same vendor lock-in problem we’ve been solving in other parts of the stack for years — imagine if your npm packages only worked in one runtime, or your browser extensions only worked in one browser.
Obsidian’s approach shows what the alternative looks like: publish once, run anywhere (that implements the spec). You can install obsidian-skills via the Claude Code plugin marketplace, or npx skills add, or just clone it into .codex/skills/ or ~/.opencode/skills/ and it auto-discovers. Same skill, three agents, zero code changes.
What School IT and Nonprofit Ops Teams Should Watch For
If you’re evaluating AI coding agents (or any AI tooling that uses a “skill” or “plugin” model), here’s the question you should start asking vendors: Are your skills portable, or am I writing agent-specific code?
This matters most when you’re building internal procedures that you expect to last longer than a single vendor’s product cycle. Example: a school district IT team writes a skill that checks student data privacy compliance before any code merge. If that skill is locked to one agent platform, you’re stuck with that platform until you budget time to rewrite. If it follows an interop spec like Agent Skills, you can switch platforms (or run multiple platforms simultaneously) without losing your institutional knowledge.
The educational takeaway: before you invest serious time building custom skills or procedures into an AI agent, check whether they export to a portable format. If the answer is “not really, but we have an API,” that’s a yellow flag. If the answer is “yes, we implement [specific open spec],” that’s green.
Why I’m Paying Attention
I’ve been living this problem firsthand. My OpenClaw fleet has about a dozen custom skills at this point, and I’ve already hit cases where I wished I could run the same skill on a different agent without porting it. Seeing Obsidian — a company that built its entire product on “your data is just markdown files, you can leave anytime” principles — apply that same portability lens to agent skills tells me this is becoming a real pattern, not just a one-off experiment.
If the Agent Skills spec gains traction (and the fact that three separate agent platforms already support it suggests it might), we’ll look back on this moment as the inflection point where “agent skills” became a portable unit of software, the same way npm made JavaScript packages portable across environments. That’s the shift worth tracking, and the kepano/obsidian-skills repo is just the most recent, most concrete example I’ve seen of someone building for that future.