SKILL.md, the King of Shadow AI

Agent Skills are a brilliant idea

Let’s be clear from the outset: Agent Skills are an excellent idea.

Released by Anthropic in late 2025, the format is elegant: a self-contained folder with a SKILL.md file in Markdown, YAML frontmatter, and optionally a few scripts or reference documents. When an agent encounters a task, it discovers the relevant skills and loads only the instructions it needs — keeping context light and adaptable.

The progressive disclosure principle is particularly clever: only the bare minimum enters the context window, and only when it’s useful. It’s efficient, it’s modular, it’s readable by a human and by a machine. The promise is a strong one: capture business expertise in a durable form, rather than diluting it across throwaway prompts.

In short, as a technical format, SKILL.md is a success.

But here’s the thing: what makes it strong is also what makes it fragile. Not the format itself — the organizational architecture it’s being deployed into.

The real problem: a format without governance

To see why, look at where skills actually live in most deployments today:

• In a skills/ folder on a developer’s laptop
• In a personal GitHub repository, sometimes public
• In ~/.claude/skills/, shared across projects with no inventory
• In community marketplaces with no internal review
• In a shared Drive or Notion folder, copy-pasted between colleagues

In other words: every skill is created, modified, shared and executed entirely outside any enterprise framework.

Meanwhile, inside that same company:

• The 2026 Privacy Barometer shows that 80% of organizations have no clear view of their AI usage.
• The 2026 Cloud and Threat Report finds that 47% of generative AI users still work through personal accounts.
• Industry analyses suggest that 38% of employees share sensitive information with AI platforms without approval.

Shadow AI was already a serious problem when it meant ChatGPT and Claude accessed through personal accounts. Agent Skills take it to another level: what leaves the company is no longer just data, it’s business expertise — encapsulated, versioned, shared, and completely invisible to IT.

Why SKILL.md makes Shadow AI worse

1. Tight coupling to the LLM or agent

A skill, as currently architected, is welded to its execution engine. An Anthropic skill is built for Claude. An OpenAI skill is built for GPT. A Copilot Studio skill lives inside the Microsoft ecosystem.

The practical consequence: to use a skill, you have to adopt (and usually pay for) the corresponding LLM. Every business team that discovers an interesting skill library brings a new vendor with it — a new pricing model, a new data processing agreement. IT finds out about the commitment after the fact.

This is the classic Shadow IT scenario, with a multiplier: a skill isn’t an isolated tool, it’s a block of business capability that creates operational dependency the moment it’s adopted.

2. No concept of organization

A skill has no idea which company it belongs to, which department, which function. It has no identified owner, no declared consumer, no org unit it reports into.

The result:

• No mapping is possible: there is no way to answer “how many skills are running in my company?”
• No pooling: three teams can build three near-identical skills for the same task.
• No lifecycle: who maintains a skill once its author leaves the company?
• No audit trail: you cannot produce the inventory of deployed AI systems the AI Act requires.

Article 4 of the EU AI Act requires a “sufficient level of AI literacy” across everyone exposed to these tools. That’s hard to deliver when you don’t even know which skills are in circulation.

3. No permissions, no ownership, no traceability

A SKILL.md file carries no notion of:

• Who is allowed to create it.
• Who is allowed to consume it.
• Who is accountable for its quality and compliance.
• Which uses must be logged.

It’s a sharing format, not a governance format. And that is precisely what makes it, paradoxically, the ideal format for Shadow AI: easy to create, easy to distribute, impossible to track at enterprise scale.

4. Duplication and drift

With no central catalog, business expertise dissolves into an endless set of diverging copies. The “client report generation” skill exists in seven versions, each with its own reading of the rules, its own hardcoded company data, its own bugs.

When the GDPR audit arrives, when the AI Act calls for documentation of the AI system behind an automated decision, when a customer exercises their right to erasure — nobody can answer.

This isn’t a bug, it’s a missing layer

Let’s be fair to Anthropic: SKILL.md never claimed to be a governance platform. It’s a format, and an excellent one — but only a format. The problem is that no organizational layer has been built on top of it, and the community treats that gap as if it weren’t there.

The parallel is instructive. Source code doesn’t govern itself: we had to invent Git, then GitHub, then pull request reviews, then CI/CD pipelines, then branch policies. Data doesn’t govern itself: we had to invent data catalogs, data contracts, data products. Skills need their orchestration layer too.

One approach: channel the initiative with a framework like skilder

That’s exactly the angle a framework like skilder takes. The point isn’t to replace the SKILL.md format — which remains excellent — but to add a layer of organization, ownership and coordination on top of it.

The core concept: the Role

A Role is a named, thematic collection of skills that maps to an actual function or persona in the company. Instead of letting skills float around loose, you group them by business use:

• A “Pre-Sales” Role gathers the skills for handling objections, drawing on competitive intelligence, and guiding a prospect through the sales cycle.
• A “Legal Assistant” Role gathers the skills for contract analysis, regulatory monitoring, and drafting amendments.
• A “DevOps” Role gathers the skills for deployment, monitoring, and incident response.

When an employee — or an agent — takes on the “Pre-Sales” Role, they get the full, coherent set of capabilities approved for that function in one move. No more, no less.

Why this changes everything

This deceptively simple mechanism resolves several structural problems of Shadow AI:

1. It channels initiative instead of banning it. A salesperson who cobbled together their own skill can propose it for inclusion in the “Sales” Role. Individual initiative becomes a company asset instead of staying in the shadows.
2. It makes mapping trivial. “Which skills are running in my company?” becomes simply “which Roles do we have, and what’s inside them?”. The catalog is centralized, versioned, audited.
3. It introduces explicit ownership. Every skill has an owner and declared consumers. Maintenance, quality and compliance have a name and a face attached.
4. It decouples expertise from the execution engine. With an MCP-compatible approach, the same skill can be consumed by Claude, by Copilot, or by an in-house agent, with no rewrite. No more implicit vendor lock-in.
5. It makes context selection intelligent. Instead of loading the entire library into the context window, the agent loads only the skills in the active Role. Fewer tokens, fewer hallucinations, better performance.
6. It offers a credible alternative to Shadow AI. The core problem with Shadow AI isn’t that employees have bad intentions. It’s that they need to be productive and the official tools arrive too late. Giving teams a platform where they can build, share and consume approved skills inside the company’s boundary means offering the fluidity of the shadow with the guarantees of the sanctioned.

The conceptual architecture

The idea fits in a few lines:

Workspace (enterprise boundary)
└── Roles (business functions / personas)
    └── Skills (units of capability, SKILL.md compatible)
        ├── Instructions
        ├── MCP tools (LLM-agnostic)
        ├── References (markdown documents)
        └── Scripts (Python, sandboxed execution)

The SKILL.md format is preserved. A standard Anthropic skill can be imported as-is. But it now belongs to a workspace, is organized into Roles, exposed through an agent-agnostic protocol (MCP), traced, versioned, and subject to explicit permissions.

What this means for CIOs and AI leads

If you own AI governance in your organization today, here is the concrete question to ask: could you, this morning, list every SKILL.md file circulating in your company?

If the answer is no — and statistically it is, in 80% of cases — then publishing a policy or banning ChatGPT is no longer enough. The missing layer is structural:

1. Map what already exists. The skills already sitting in Git repositories, in ~/.claude/, in marketplaces. This is the AI equivalent of the GDPR record of processing activities.
2. Centralize creation. One place where a skill is declared, versioned and published, with an identified owner and consumer.
3. Structure by Role, not by technology. Think Roles before you think models. A salesperson doesn’t need to know whether they’re using Claude or GPT. They need the “Sales” Role.
4. Decouple from the LLM. Pick an abstraction layer — MCP is today’s de facto standard — that lets you swap models without rewriting your skills.
5. Make internal skill creation official. Shadow AI thrives when the official channel is slower than the unofficial one. If getting a skill approved takes 48 hours and comes with an identified owner, nobody will bother building one on the side.

Conclusion

SKILL.md isn’t the problem. It may well be one of the best formats for encapsulating AI expertise to have emerged in the last two years.

But a format is not a platform. And as long as the ecosystem keeps treating skills the way we treated shell scripts in 2005 — passed around by hand, no owner, no catalog, no lifecycle — SKILL.md will remain, despite itself, the king of Shadow AI: the most convenient, most shareable and most invisible format enterprises have ever let into their systems.

The good news is that the fix isn’t to replace the format. It’s to add the organizational layer it’s missing. Roles to structure how the business actually works. A workspace to draw the enterprise boundary. MCP compatibility to avoid vendor lock-in. A catalog to make visible what’s already circulating.

Shadow AI isn’t a signal that AI should be banned. It’s a signal that it finally needs a framework where it can thrive without hiding.

---

Want to map the skills already circulating in your organization, or structure their adoption around clear business roles? That’s exactly the problem skilder solves.