Becoming an AI Native Company: Start With Shared Skills

TLDR; Setting up a shared skills capability is the easiest first step towards becoming an AI native company. This is a practical guide on how to do it correctly.

Introduction

Skills are one of the most powerful aspects of agentic workflows and have become the standard packaging format for institutional knowledge. Think of skills as the SOPs that your agents can actually execute.

This guide covers everything you need to know to build your own shared skill library that compounds inside your company.

This guide covers what skills are, how to use them (safely), options for implementing a shared skills capability across your team or company, how to govern skills, and where the real value comes from.

An agent skill is a portable package of procedural knowledge - think of them like instructions, scripts, references, guardrails, etc. that teach an agent to do one focused task reliably.

Basically take any repetitive task - “make this code good”, “close the month-end books”, “draft this copy in our brand voice” - and the skill outlines at a very detailed level how that task should be performed.

The biggest gap is that skills are generally created at an individual level and not treated as an essential asset or artifact within a company.

That means the work done to create a skill doesn’t get leveraged by all the people who should be using it or multiple people reinvent the wheel creating various versions of the same skill.

Sharing turns skills into versioned, discoverable company assets and flips the game from single-player to multi-player. This is where you get leverage as a team or company, and it’s generally the single easiest uplift you can do on the path to becoming an AI native company.

Hiten Shah’s argument that every company’s first AI strategy should be a skill library, Atlan’s framing that “skills do for procedural knowledge what functions did for logic,” and Microsoft’s Work Trend Index concept of Owned Intelligence all converge on the same point from different angles - your private skill library is a form of owned intelligence that compounds.

One caution up front: the moat is not the actual file. A SKILL.md is trivially simple. The durable asset is the private library plus the eval and telemetry loop around it. More on that later in the article.

The open skills standard

The Agent Skills format was created by Anthropic - announced October 16, 2025 on their engineering blog, then released as an independent open standard on December 18, 2025 at agentskills.io, with a reference validator (skills-ref) at github.com/agentskills/agentskills.

The format:

A folder named after the skill
A required SKILL.md: YAML frontmatter + Markdown instructions. Only name and description are required fields; name must match the folder, lowercase-hyphen only; description up to 1,024 chars
Optional scripts/, references/, assets/
Optional frontmatter: license, compatibility, metadata, and an experimental allowed-tools

The mechanism that makes org-scale libraries viable is that agents load only name + description at startup (~100 tokens per skill), then only pull the full SKILL.md body on activation (under 5,000 tokens recommended) and read the bundled files only on demand. That means you can carry hundreds of skills without burning the context window- super important for companies trying to control token costs.

This format has been adopted by nearly every major agent harness and agentic platform so there’s very little risk that you will invest time in creating a skills library just to see something new come along and displace it.

Security - read this before you build anything

Skills present a very real attack surface if you’re downloading skills from the internet without the right precautionary measures. Since skills are essentially instructions that your agents follow, hiding malicious intent inside them is a real threat.

The base rate of bad skills is high based on two independent studies:

Snyk’s ToxicSkills study (February 5, 2026, n=3,984 skills from ClawHub and skills.sh): 37% had at least one security flaw of any severity, and 76 were confirmed malicious.
Liu et al., “Agent Skills in the Wild” (academic, n=31,132 skills): 26% contained at least one dangerous pattern and skills that bundle executable scripts are 2.x more likely to be vulnerable than instruction-only skills.

Two important points that should shape your architecture:

Prompt injection lives in the SKILL.md prose itself. No code execution required - the malicious instruction just has to enter the agent’s context window.
Skills act inside the model’s reasoning, invisible to API-level observability that watches MCP tool calls. Your existing agent monitoring may not see skill behavior at all.

Ok so this may sound scary but the practical implications are pretty obvious: treat skills exactly like OSS packages (scan, review, pin), apply extra scrutiny to anything with a scripts/ folder, never auto-import from public marketplaces without proper review, and require author-is-not-reviewer on every approval.

I personally use Nvidia’sSkillSpectorif I’m downloading any external skills.

Best approach - just build skills yourself and avoid downloading any 3rd party skills.

Implementation options

A. Private GitHub repo (easiest starting point)

A private repo of skill folders is free, version-controlled, works with every agent that reads the standard, and gets you PR review as governance without any extra overhead. Add CI for YAML lint and secret scanning and the whole process gets buttoned up pretty quickly.

Distribution is through whatever tool convention is used (.claude/skills/ paths, plugin marketplaces, various CLI installers) - the spec itself is agnostic on install mechanics.

Here’s the flow: individual drafts skill and submits PR -> PR gets review -> PR is merge -> everyone gets it on next session. And anyone can just grab the internal GitHub link and give it to their agent and say “install this.”

The downside: managing skills this way can lead to a graveyard of stale skills if nobody owns and maintains them so best to name a maintainer per skill from day one and wrap some governance around the process (see next section on this).

B. Enterprise tools (if you want real tooling)

If you want to go with an option that is a bit more robust and purpose-made for helping teams/organizations manage skills, then these may be of interest. The main benefits are scanning, signing, access control, and audit features for shared skills.

There’s a bunch of these now, I do not claim to now which ones are best, but here’s the current field for you to explore:

JFrog Agent Skills Registry - Two-phase “Zero-Trust Consumption Model” with malicious-code and prompt-poisoning scanning, attestation evidence, and optional signing.
TrueFoundry Skills Registry - Write once, attach across agents; on-demand loading; UI or CLI; versioning and access control.
Agentman - Team/Shared tiers, granular permissions including Use-only (invoke a skill without reading its internals - genuinely useful for protecting proprietary process detail).
SkillRepo - Managed library with with skill grading, per-repo version scoping, and compliance tracking.
Scalefocus skilly - Self-hosted option for “one controlled home for every agent skill.”
Agent Skill Harbor - MIT-licensed open source option that is GitHub-native, serverless catalog with a scanner and recommended/discouraged/prohibited classes.

C. Real company implementations (just steal these)

Sometimes you just want to replicate what other good companies are doing. Thankfully many companies have posted their setups on X or company blog posts so there’s a bunch to steal from.

Anthropic internal - from their own post on how they use skills: hundreds of skills in active internal use, two-tier distribution (git repo graduating to an internal plugin marketplace), nine internal skill categories, and PreToolUse-hook telemetry measuring which skills fire, which are popular, and which under-trigger. That last part matters - it’s the only observed instance of a company instrumenting the skill loop, and it’s the pattern to copy.
Red Hat - agentic-collections with 7 skill packs, ~68+ skills encoding RHEL/OpenShift/Ansible operational knowledge. Their Lola package manager bundles skills, commands, agent instructions, and MCP servers into versioned modules.
WorkOS - workos/skills uses a pretty sophisticated router-skill pattern (2 router skills over 40+ reference files spanning AuthKit/SSO/RBAC). Production uses per the ZenML case study: a CLI installer that detects frameworks and configures AuthKit, recruiting reports, code review, Slack-to-Linear automation. Their verified eval practice is baseline comparison - same prompt with and without the skill, score the delta. Sounds complex but just throw the articles into your LLM and say “build me a plan like this.”
CloudQuery - based on Joe Karlsson’s writeup of a personal skills repo becoming de facto internal tooling for a non-technical marketing team. His lessons: CLAUDE.md-first discipline, name a maintenance owner, and he’s explicit that he measured nothing rigorously. Refreshingly honest take.

Operations - evals, versioning, lifecycle

If you’ve not heard this already, it’s always about evals. This is what separates a real skill library that compounds intelligence internally and one that just becomes a stale directory of stuff that maybe some people use on occasion.

Evals

Anthropic’s official skill-authoring best practices prescribe evaluation-driven development: run the agent without the skill to find the gap, build at least 3 test scenarios, establish the no-skill baseline, write minimal instructions, iterate against the baseline. Every serious team uses evals to measure itself, otherwise you’re just operating on vibes.

Two quick tips: skill effectiveness is model-dependent (test across different models and tiers, not just your default), and try to use different models for design and test, otherwise you can find that “Claude A” designs something that “Claude B” tests as fine but doesn’t work so well with ChatGPT. Better to use Claude to design and ChatGPT to test (or whatever models you prefer) to uncover the nuances.

Versioning and lifecycle

The two best frameworks I’ve found that help you with skills governance:

Atlan’s 7-step lifecycle: # A Practitioner’s 2026 Governance Guide
AWS Well-Architected Agentic AI Lens (AGENTOPS03-BP01): Define an agent lifecycle with clear SME ownership, testing, and governance

Just read these or at the very least feed them to your agents as reference guides to follow.

Measurement - the honest state of the art

I’ve not seen a rigorous, methodology-backed adoption or time-savings metric for internal skill sharing. The closest thing to a real method is WorkOS’s with/without-skill delta scoring and Anthropic’s hook telemetry. If you build usage instrumentation into your library, you will likely have better data than most of the industry currently publishes, so that’s the way to get onto the leading edge of this.

Skills vs MCP, and where the moat actually is

Per Anthropic’s own framing: MCP connects the agent to data and systems; skills teach it what to do with them. Access provides context, skills provide judgment.

The practical rule is that anything requiring live data or authenticated actions is an MCP server, anything encoding procedure or standards is a skill, and mature skills often call MCP tools mid-procedure.

On the moat: the skill file is the artifact everyone can see, so it’s tempting to treat the library as the asset. What compounds is actually the library plus the eval suite that proves each skill works, the telemetry that shows which skills actually fire, and the improvement loop that feeds usage back into revisions.

That loop is why Anthropic instruments skills with hooks and why the registry vendors I mentioned in 4B are trying to own the control plane - the moat is all about the data.

Getting-started roadmap

Adopt the open SKILL.md standard. Don’t try to get cute with anything else.
Stand up a private git repo. PR review is your day-one governance. Easy peasy way to start.
Pilot 5-10 high-value skills from domain experts - the people whose knowledge walks out the door otherwise. Name an owner per skill.
Write evals from day one: no-skill baseline, 3+ scenarios per skill, re-run on every change. This is the step most skip and the step that matters most.
Scan everything (use Nvidia’s SkillSpector if using any external skills), and put extra scrutiny on skills bundling scripts. Author is never reviewer.
Instrument usage (hook telemetry) before you scale. You can’t govern what you can’t see, and you’ll have better adoption data than most companies using skills.
Evaluate the external registry tools if and when volume or compliance demands it, until then just stick with an internal solution.

If you’ve implemented shared skills within your company, I’d love to hear about it. And if you need help doing it, my DMs are open.