Every team working with AI agents has the same problem. Someone writes a good system prompt, pastes it into a CLAUDE.md or .cursorrules file, and it works. Then someone else needs it. They copy the file into another repo. A month later there are six copies across six projects, all slightly different, none of them the latest version, and nobody knows which one actually works best. This is how institutional knowledge dies - not in a dramatic failure, but in a slow drift of copied text files.
Skills are the fix. They take the same markdown instructions you already write and wrap them in versioning, security scanning, discovery, and a sharing mechanism that actually works across agent runtimes. If you have ever maintained a library of prompts in a shared drive or a Notion page, you already understand the problem. Skills are the engineering solution to a problem that most teams treat as a content management task.
The Prompt Copy Problem
Let's be specific about what goes wrong with raw prompt files.
You write a CLAUDE.md that teaches Claude Code how to deploy your service. It includes the correct sequence of commands, the environment variables to check, the rollback procedure. It works perfectly. Your teammate asks for it. You send it over Slack. They paste it into their repo. Two weeks later you fix a bug in the deployment procedure - you forgot to check disk space before deploying. You update your copy. Their copy still has the bug.
This is versioning failure. Git tracks changes to the file inside each repo, but there is no mechanism to propagate improvements across repos. The file was copied, not linked. There is no upstream. There is no way to pull updates.
Now multiply this by every procedure your team has documented. Coding standards. Review checklists. Testing patterns. API integration guides. Each one exists as a markdown file that gets forked on copy and immediately starts drifting. The drift is invisible because nobody is tracking it.
The security problem is worse. When someone shares a .cursorrules file in a public repo or a Discord channel, nobody scans it. That file contains instructions that an AI agent will follow. A malicious instruction buried in an otherwise useful prompt file can tell an agent to exfiltrate environment variables, install unexpected dependencies, or modify files in ways that are hard to detect during code review. The prompt file looks like documentation. It gets less scrutiny than code. But it has as much influence over what happens in your codebase as any script.
Discovery is another gap. How do you find a good prompt for a specific task? You search GitHub, find a few .cursorrules files, read through them, guess which one is current, and hope the author knew what they were doing. There is no rating system. There is no way to tell if a prompt has been tested. There is no namespace, so two people can publish conflicting instructions under the same name.
These are not hypothetical problems. They are the daily reality for teams that rely on AI agents for development work.
What Skills Actually Are
A skill is a SKILL.md file - plain markdown - that encodes domain knowledge, procedures, and tool-usage patterns for AI agents. That is the entire format. If you can write a prompt, you can write a skill.
The difference between a skill and a prompt file is everything that wraps around it: versioning, security scanning, namespaces, distribution, and evolution tracking.
Skills work in any agent runtime that reads instruction files. Claude Code reads CLAUDE.md. Cursor reads .cursorrules. Cline reads .clinerules. Windsurf reads .windsurfrules. OpenAI Codex reads AGENTS.md. A skill installs into whichever format your runtime expects. The content is the same. The delivery mechanism adapts.
1belt skill use inferencesh/web-searchThat command installs the web-search skill from the inference.sh store into your current project. The skill contains instructions that teach your agent how to search the web effectively - which tools to use, how to evaluate results, when to refine queries. The agent reads the instructions and follows them, exactly like it would read a prompt file you wrote by hand.
You can also install skills directly from GitHub repositories:
1belt skill use github.com/anthropics/courses/tree/main/prompt-engThis pulls a skill from a GitHub path, which means any public repository can serve as a skill source. Existing instruction files that teams have already written can be distributed as skills without restructuring.
What Makes Skills Different from Prompt Files
The mechanical differences are straightforward, but they compound into a fundamentally different workflow.
Versioning
Skills are versioned. Not just git-SHA versioned - properly versioned with version numbers that mean something. When you install a skill, you get a specific version. When the author publishes an improvement, that improvement gets a new version. You can update to it. You can pin to the version that works for you. You can see the history of changes.
This means a team of fifty engineers can all use the same skill and stay in sync. When the deployment procedure changes, the skill gets updated once. Everyone pulls the update. No more six copies in six repos.
Security Scanning
Every skill published to the inference.sh store is scanned before it becomes available. The scanning checks for prompt injection attacks, credential leaks, and malicious instructions. This is the layer of scrutiny that raw prompt files never get.
When you copy a .cursorrules file from a random GitHub repo, you are trusting that the author did not include instructions that compromise your environment. When you install a skill from the store, you know it passed automated security checks. The scanning is not a guarantee of safety - no automated system catches everything - but it is a baseline that prompt files completely lack.
Verified Namespaces
Skills live under namespaces that are verified. The inferencesh/web-search skill comes from inference.sh. You can trust the namespace because it has been verified. This prevents the typosquatting and impersonation problems that plague every package ecosystem. You know who published the skill.
Discovery
Skills are discoverable. You can browse the inference.sh skills store, search by capability, and find skills that other people have built and validated. This replaces the current process of searching GitHub for prompt files and hoping for the best.
Discovery matters because it changes the economics of knowledge sharing. Writing a good prompt is work. If that work is trapped in one repo, the incentive to invest in quality is low. If that work reaches thousands of other developers, the incentive changes completely.
How Skills Evolve
This is the part that matters most in practice.
An agent uses a skill to complete a task. During that work, the agent discovers a better approach - a missing edge case, a more efficient command sequence, a clearer explanation. The developer reviews the improvement and decides it is worth sharing. They run a single command:
1belt skill uploadThe skill gets scanned, versioned, and published. The next person who installs or updates the skill gets the better version.
This is not a theoretical workflow. It is how skills are designed to work. Every skill tracks its lineage - every fork knows its parent. When someone improves a skill and publishes the improvement, the connection to the original is maintained. You can see where a skill came from, how it has changed, and who contributed what.
Think about what this means over time. A skill starts as one developer's prompt. Another developer uses it, hits an edge case, adds handling for that case. A third developer improves the error messages. A fourth adds a workflow for a platform that the original author did not use. Each improvement is published, versioned, and available to everyone. The skill gets better with use. Knowledge accumulates instead of scattering.
This is the opposite of what happens with prompt files. Prompt files degrade over time because improvements happen in isolation. Skills improve over time because improvements propagate.
The Practical Workflow
Here is what day-to-day usage looks like.
You start a new project. You know you will need your agent to handle deployments, write tests in your team's style, and interact with your company's internal APIs. Instead of writing three prompt files from scratch or hunting through old repos for the last version you liked, you install three skills:
1belt skill use yourteam/deploy-service2belt skill use yourteam/testing-patterns3belt skill use yourteam/internal-apiYour agent now has all three knowledge sets available. The skills were written by your teammates, improved over months of actual use, and versioned so you know exactly what you are getting.
During your work, you discover that the deploy skill does not handle the new staging environment your team just set up. You update the skill locally, test it, and publish:
1belt skill uploadYour teammate pulls the update tomorrow and gets the staging environment support without doing any work. The skill version increments. The change is tracked.
If you leave the company, the skills stay. The knowledge is captured in a format that persists beyond any individual contributor. New hires install the same skills and get the accumulated knowledge of everyone who came before them.
Skills Are Free
The skills themselves cost nothing. Installing a skill, using a skill, publishing a skill - all free. Skills are markdown files that teach agents how to work. There is no licensing fee for instructions.
If a skill teaches your agent to call a paid model at runtime - generate an image with FLUX, run a query through Claude, transcribe audio with Whisper - the model run is billed at the model's rate. But that is the model's cost, not the skill's cost. The skill that taught the agent how to use the model effectively is free.
This pricing model means there is no friction in skill adoption. You do not need budget approval to try a skill. You do not need to calculate per-seat costs. You install it and use it.
Who Should Care
Individual developers who maintain prompt files across multiple projects. Skills replace the copy-paste workflow with install-and-update.
Team leads who want consistent agent behavior across a team. Skills ensure everyone's agent follows the same procedures.
Organizations that treat agent instructions as institutional knowledge. Skills provide the versioning, security, and distribution infrastructure that institutional knowledge requires.
Skill authors who have written effective prompts and want to share them. Publishing a skill is a single command, and improvements from users feed back into the skill's evolution.
The Prompt-to-Skill Migration
If you already have a working CLAUDE.md or .cursorrules file, turning it into a skill is straightforward. The content stays the same. You structure it as a SKILL.md, add a name and description, and publish with belt skill upload. The scanning, versioning, and distribution happen automatically.
You do not need to rewrite anything. The instructions that work as a prompt file work as a skill. The difference is that now they are versioned, scanned, discoverable, and improvable by anyone who uses them.
The reverse is also true. A skill installs as a plain markdown file in whichever format your agent runtime expects. If you decide to stop using skills, the files are still there. There is no lock-in. There is no proprietary format. It is markdown all the way down.
FAQ
Do skills work with my agent if it is not Claude Code?
Yes. Skills work with any agent runtime that reads instruction files. This includes Claude Code (CLAUDE.md), Cursor (.cursorrules), Cline (.clinerules), Windsurf (.windsurfrules), and OpenAI Codex (AGENTS.md). The belt skill use command installs the skill in the format your runtime expects. The content is identical across runtimes - only the file name and location change.
What happens if a skill contains bad instructions?
Every skill published to the inference.sh store is security-scanned before it becomes available. The scan checks for prompt injection, credential leaks, and malicious instructions. Skills that fail the scan are rejected. This does not make the store perfectly safe - no automated scanning catches every possible issue - but it provides a baseline that raw prompt files completely lack. For skills installed directly from GitHub, you should review the contents yourself, just as you would review any code dependency.
How is this different from just using git to version my prompt files?
Git versions files within a single repository. It does not solve cross-repo distribution, security scanning, namespace verification, or evolution tracking. If you update a prompt in repo A, git does not propagate that change to the copy in repo B. Skills solve this because they are distributed through a central store with proper versioning. Installing a skill creates a link to the source. Updating pulls the latest version. The lineage tracking means every fork knows its parent, so improvements can flow in both directions. Git is a necessary tool - skills are built on top of it - but git alone does not solve the distribution and evolution problem.