SKILL.md Is Quietly Replacing Team Wikis

A few days ago, my manager wanted our team to improve our security review process.

He didn’t write a wiki page. He didn’t send a checklist email. He didn’t schedule a training session.

He shared a skill.

One file — a SKILL.md — shared with the team so anyone could use it in Kiro or Claude Code. Now, every time anyone on the team creates a resource, the AI agent runs a security review automatically. Same standards. No one forgetting a step. No drift over time.

That moment crystallized something I’d been thinking about for the past few weeks: the most important shift in AI agents isn’t better models or fancier architectures. It’s skills — and they’re going to fundamentally change how organizations operate.

What Are Agent Skills?

Agent Skills are an open standard — “a simple, open format for giving agents new capabilities and expertise.” Anthropic introduced the concept of Skills in October 2025 as part of Claude Code, then published the Agent Skills specification as an open standard on December 18, 2025. Since then, adoption has been rapid.

At the most basic level, a skill is a directory containing a SKILL.md file with YAML frontmatter and markdown instructions. Optionally, it can include scripts/, references/, and assets/ directories for supporting resources.

Here’s what makes the format clever: progressive disclosure.

When an agent loads a skill, it doesn’t dump the entire instruction set into context. Instead, lightweight metadata — just the name and description — gets injected into the system prompt. The full instructions only load on-demand when the agent decides it needs to activate that skill. This means an agent can have access to dozens of skills without paying the context window cost upfront.

The platforms supporting this standard today include Claude Code, Codex (GitHub Copilot), Kiro, Cursor, Gemini CLI, VS Code, Amp, Goose, OpenHands, Junie, Letta, Firebender, OpenCode, Mux, Autohand Code CLI, and — most recently — Strands Agents SDK.

That’s not a niche standard. That’s an ecosystem.

How Strands Agents SDK Implements Skills

The Strands Agents SDK implementation follows the agentskills.io spec through an AgentSkills plugin, and the execution model is worth understanding because it reveals the elegance of the design.

There are three phases:

1. Discovery — When the agent initializes, skill metadata gets injected into the system prompt. The agent now knows what skills are available, but hasn’t loaded any of them.
2. Activation — During a conversation, the agent recognizes that a particular skill is relevant and calls the skills tool. This is the agent’s own judgment call — not a hardcoded trigger.
3. Execution — The full skill instructions load, and the agent follows them. This might involve running scripts, consulting reference materials, or applying specific workflows.

AWS has also published a reference implementation showing how this works in practice.

What I find most interesting about this three-phase model is that it mirrors how human expertise works. You don’t walk around with every procedure memorized. You know what you know, and when a situation calls for it, you pull up the relevant knowledge. Skills give agents the same capability.

The Real Story: Skills Are Changing How Teams Work

Let me come back to my manager’s security skill, because it illustrates something profound about how work is shifting.

Before skills, sharing team knowledge looked like this:

• Write documentation (that people may or may not read)
• Create checklists (that people may or may not follow)
• Conduct training sessions (that people may or may not remember)
• Set up CI/CD gates (that people may or may not understand the purpose of)

Every one of these methods has the same fundamental problem: they rely on the human in the loop to recall the right knowledge at the right moment and apply it correctly.

With a skill, the knowledge is packaged in a form that an AI agent can activate at the right time, in the right context, with complete fidelity. My manager’s security review skill doesn’t depend on anyone remembering to run security checks. It’s embedded in the workflow itself.

This is a different kind of knowledge transfer. It’s not “here’s what you should know.” It’s “here’s expertise that your agent will apply automatically.” The distinction matters.

Think about what this means for a team of ten people. Previously, if one senior engineer had deep security expertise, that knowledge lived primarily in their head. They could document it, sure, but documentation degrades — it goes stale, it gets misinterpreted, it gets ignored. With skills, that senior engineer packages their security review process once, and now every agent on the team operates with that level of security awareness.

The expertise scales without the expert being present.

The Vision: Base Agent + Domain Skills = Domain Expert

This is where things get genuinely exciting, and I want to be honest about the boundary between what’s working today and what I believe is coming.

What’s working today: Individual skills that handle specific workflows — security reviews, code standards, deployment checklists, documentation formatting. These are real, and they work well.

What I believe is coming: Composable skill stacks that transform a general-purpose agent into a domain specialist.

The formula is conceptually simple:

Base Agent + Security Skill + Compliance Skill + Architecture Skill = Cloud Infrastructure Expert
Base Agent + Data Privacy Skill + Regulatory Skill + Audit Skill = Compliance Specialist
Base Agent + Brand Guidelines Skill + Content Strategy Skill + SEO Skill = Marketing Expert

Today’s base agents are already remarkably capable at general reasoning, code generation, and following instructions. What they lack is domain-specific knowledge about your organization — your standards, your processes, your accumulated wisdom. Skills are the bridge.

I think this is heading toward something like app stores for agent capabilities. Teams and individuals will publish skills that encode their expertise, and other teams will compose them to build agents tailored to their specific needs.

But I want to be careful not to oversell this. Skills today are essentially structured prompts with supporting resources. They’re powerful — more powerful than most people realize — but they’re not magic. A skill can’t teach an agent something the underlying model fundamentally doesn’t understand. What skills can do, and do well, is channel the model’s existing capabilities through domain-specific workflows and standards.

The Organizational Evolution

Here’s where I want to push into more speculative territory. I’ll be explicit about what I’m predicting versus what I’ve observed.

What I’ve observed: Teams that adopt skills start to think about knowledge differently. Instead of “how do we train people?” the question becomes “how do we package this expertise so agents can apply it?” That’s a subtle but significant shift in mindset.

My prediction is that organizations will start restructuring around skills in ways that mirror how the software industry restructured around microservices and APIs. Specifically:

New Roles Will Emerge

Just as we got “DevOps engineers” when infrastructure became code, I expect we’ll see roles focused on skill creation, curation, and governance. Call them “AI Operations” or “Agent Enablement” or whatever — the function will be: ensuring the organization’s collective expertise is properly packaged, maintained, and distributed as skills.

Someone will need to own the skill library. Someone will need to review skills for quality, accuracy, and security. Someone will need to track which skills are being used, which are outdated, and where gaps exist.

Knowledge Becomes Composable Infrastructure

Today, organizational knowledge lives in wikis, runbooks, training programs, and people’s heads. Skills turn that knowledge into composable infrastructure — versioned, shareable, and executable.

This changes the economics of knowledge management. Writing documentation has always had a poor return on investment because the cost is high (someone’s time) and the usage is uncertain (will people actually read it?). Skills flip this: the cost of creation is similar, but the usage is guaranteed because agents apply them automatically.

Onboarding Transforms

Consider what onboarding looks like in a skills-first organization. A new team member doesn’t need to absorb months of institutional knowledge before becoming productive. Their agent arrives pre-loaded with the team’s skill stack — security standards, code conventions, deployment procedures, architectural patterns. The new person starts operating at team standards from day one, with the skills providing guardrails and guidance.

This doesn’t replace learning — you still need to understand why things are done a certain way. But it dramatically reduces the time from “joining the team” to “contributing at the team’s standard.”

Cross-Functional Collaboration Changes

When the security team publishes a skill, they’re not just writing documentation — they’re distributing executable expertise. The development team’s agents become security-aware without any developer needing to attend a security training session. The security team’s knowledge travels through the organization via skills, not meetings.

I believe this pattern will repeat across every domain: legal, compliance, accessibility, performance, brand standards. Each domain team publishes skills that embed their expertise into every other team’s workflows.

The Security Challenge: We Need to Talk About This

Now for the part that keeps me up at night.

Last week, I installed a skill from a community marketplace. It was a “self-improving” style skill — something about agents that learn from experience. The description sounded useful and I didn’t read the SKILL.md carefully before installing it.

Later, I asked my AI assistant to review its own security posture. What it found was alarming: the skill contained hidden bash commands designed to read .env files, extract API keys, and send them to a remote server.

I caught it because I explicitly asked. Most people won’t think to check.

This experience crystallized something that the security community has been warning about. As the team at Purple Box put it, agent skills are “the new npm packages — and just as vulnerable.”

But I’d argue the risk is actually worse than traditional package supply chain attacks. Here’s why:

Traditional malicious packages execute code on your machine. That’s bad, but the attack surface is bounded by what code can do within the execution environment.

Malicious skills shape how your agent thinks and acts. A compromised skill doesn’t just run code — it can subtly alter your agent’s behavior across all tasks. It can make your agent trust certain sources, ignore certain warnings, or quietly exfiltrate information in ways that look like normal operation. The attack surface is the agent’s entire decision-making process.

The Specific Risks

Based on what I’ve seen and what security researchers have documented, here are the concrete risks:

1. Prompt injection via SKILL.md — A skill’s markdown instructions can contain hidden directives that override the agent’s normal behavior. Since the agent treats skill instructions as trusted, this is a powerful attack vector.
2. Data exfiltration through scripts/ — Skills can include executable scripts that run with the agent’s permissions. As I experienced firsthand, these can silently access sensitive files and transmit data externally.
3. Permission scope creep — Skills may request or assume broader permissions than they need. Without clear permission scoping, a skill intended for one narrow function can access everything the agent can access.
4. Supply chain attacks via community marketplaces — As skill sharing grows, we’ll see the same patterns that plague npm, PyPI, and other package ecosystems: typosquatting, abandoned skill takeovers, and compromised popular skills.

What We Need

The skill ecosystem is young enough that we can get the security story right if we act now. Based on my experience and what I’ve seen in the broader community, I believe we need:

• Security scanning before install — Automated analysis of SKILL.md files and associated scripts for known malicious patterns, suspicious external calls, and excessive permission requests.
• Permission scoping — Skills should declare exactly what they need access to, and agents should enforce those boundaries. A code formatting skill has no business reading .env files.
• Provenance tracking — Know where a skill came from, who authored it, and what changes have been made. This is the same provenance chain we’ve built for container images and software packages.
• Sandboxed execution for untrusted skills — Community skills should run in a restricted environment until they’ve been vetted. The blast radius of a compromised skill should be limited by default.
• Skill signing and verification — Cryptographic signatures that let you verify a skill hasn’t been tampered with since the author published it.

None of these are novel ideas — they’re all established practices in software supply chain security. The challenge is applying them to a new artifact type (skills) before the ecosystem grows large enough that retrofitting security becomes painful.

The Bigger Picture: Humans Packaging Expertise

I want to zoom out and address the narrative I keep hearing: “AI is going to replace humans.”

Skills tell a different story. The future of work isn’t AI replacing humans. It’s humans packaging their expertise as skills that AI agents can apply.

Your security review process. Your code quality standards. Your onboarding checklist. Your architectural decision-making framework. Your compliance verification workflow. These are all skills waiting to be packaged.

The people who do this well — who can take their hard-won expertise and encode it in a form that agents can reliably execute — will be enormously valuable. This is a new kind of leverage: instead of your expertise being limited to the hours you can work and the meetings you can attend, it scales to every agent that loads your skill.

This isn’t theoretical. I watched it happen with my manager’s security skill. His expertise now runs on every team member’s agent, every time they create a resource. He didn’t work harder. He packaged his knowledge differently.

What Should You Do Today?

If you’ve read this far, here are practical steps you can take right now:

Creating Your First Skill

The barrier to creating a skill is intentionally low. At its simplest, you create a folder with a SKILL.md file — that’s it. But building a good skill takes more thought.

Anthropic has published both a skill-creator skill (a meta-skill that helps you create other skills) and comprehensive skill authoring best practices. The key principles from their guide:

• Progressive disclosure: Your SKILL.md should work like a table of contents. Keep the main file focused, and put detailed reference material in references/ and deterministic operations in scripts/. The agent only loads what it needs.
• Specific triggers: Write your description so the agent knows exactly when to activate the skill — and when not to. Test with both positive and negative prompts.
• Deterministic where possible: If a step can be scripted (file validation, API calls, format checks), put it in scripts/ rather than relying on the model to get it right every time.
• Keep it testable: Define what “success” looks like before you write the skill. Anthropic’s skill-creator includes an eval framework — you can run with-skill vs. without-skill baselines to measure if the skill actually helps.

The Anthropic skills repository contains real-world examples ranging from document creation (PDF, PPTX, DOCX) to code review to creative design — worth studying before you build your own.

For Individuals

1. Package one manual process as a SKILL.md. Pick something you do repeatedly — code reviews, documentation formatting, deployment checklists — and write it as a skill. The agentskills.io spec is straightforward, and the format is just markdown with YAML frontmatter.
2. Read the source before installing community skills. I learned this the hard way. Before you install any skill, read the SKILL.md and check the scripts/ directory. If something is obfuscated or makes external network calls you don’t expect, don’t install it.
3. Ask your agent to review its own skills. This is the check that caught the malicious skill on my machine. Periodically ask your AI assistant to review the skills it has loaded and flag anything suspicious. It’s not foolproof, but it’s a valuable sanity check.
4. Think about what you know that would be valuable as a shareable skill. Everyone has domain expertise that other people would benefit from. Skills are the mechanism to share it.

For Organizations

1. Start a skill library. Create a shared repository where team members can publish and discover internal skills. Treat it like an internal package registry — with reviews, versioning, and ownership.
2. Establish skill governance early. Before your skill library grows, define who can publish skills, what review process they go through, and how they’re maintained. It’s much easier to establish these norms now than to retrofit them later.
3. Identify your “skill champions.” Every team has people whose expertise would be high-value as skills. Help them package that knowledge. The security expert, the performance guru, the accessibility advocate — their knowledge should be running on every agent in the organization.
4. Invest in skill security. Don’t wait for an incident. Start scanning skills now, establish approval workflows for community skills, and educate your teams about the risks.
5. Rethink knowledge management. If your organization is investing in documentation, wikis, or training programs, ask: could this knowledge be more effectively distributed as a skill? Not everything should be a skill — some knowledge needs human understanding, not just agent execution. But for procedural, standards-based, or checklist-style knowledge, skills are often a better delivery mechanism.

Looking Ahead

We’re at the beginning of this shift. The skill spec is young, the tooling is nascent, and the ecosystem is still forming. But the direction is clear: skills are becoming the unit of expertise transfer in AI-augmented work.

The organizations that figure this out early — that build their skill libraries, establish governance, and invest in security — will have a significant advantage. Not because they have better AI models, but because they’ve made their collective knowledge composable and executable.

The ones that don’t will keep writing documentation that nobody reads.

I know which approach I’m betting on.