Claude Skills install in three places, and the place decides ownership
Claude Skills install into three different places, and the one you pick decides who owns the file and who can change what your agent does.
You added a skill, the agent used it, and you could not say where the file went. That is normal, because there is no single install step for Claude Skills: claude.ai puts the folder in your account, Claude Code puts it in a directory on a machine or in a repository, and the API puts it in a workspace. The install you pick decides who owns the file, and who can change what your agent does. Kortix is the open-source CompanyOS: your agents, their skills, your company memory, and every connector in one git repo you own, with the agents working on real cloud computers.
A skill is a folder with one required file
A skill is a directory containing, at minimum, a SKILL.md file. That file is YAML frontmatter followed by Markdown, and two fields are required. name runs 1 to 64 characters, lowercase letters, digits and hyphens. It must match the parent directory name. description runs 1 to 1024 characters and should say both what the skill does and when to use it. The format is published as an open standard at agentskills.io. Anthropic's overview describes the same structure.
The name and description are the only parts loaded at startup, and the description is what the model matches your request against. Anthropic puts the cost at about 100 tokens per skill for the metadata. The body costs under 5,000 tokens once the skill triggers, and bundled files cost nothing until something reads them. A skill you never trigger costs its name and description and nothing else. That is why a folder of twenty skills is cheap and a folder of twenty long prompts is not.
Three installs, three owners
claude.ai. You package the folder as a ZIP and upload it under Customize, then Skills. The skill belongs to your account. Anthropic's help center is explicit that a custom skill you upload is not visible to colleagues until you share it. A shared skill is view-only for the recipient: they can enable and use it, not edit it. On Team and Enterprise plans an owner can provision skills for everyone. That moves the decision one level up. It stays inside the vendor's product.
Claude Code. You write SKILL.md into a directory, and which directory decides the blast radius. ~/.claude/skills/<name>/ loads in all your projects on that machine and not in Cowork or cloud sessions. .claude/skills/<name>/ loads in sessions in that repository. The docs tell you to commit it so your team gets it. Enterprise, plugin and --add-dir locations exist too. The file belongs to whoever can write that directory, so the permission that matters is a git one.
The API. You upload through the Skills API at /v1/skills. The skill_id goes in the container parameter alongside the code execution tool. Custom skills are shared workspace-wide, so every member of the workspace can reach them. The workspace is the unit of ownership and the API key that can upload is the unit of control.
Three products, three nouns: account, directory, workspace, and none of them is a diff.
The description is the routing key
The description decides which tasks the agent picks the skill up for, so a broader one changes behaviour with no version bump and no diff anyone reads. Pinning a skill to a commit is a separate problem, and the lockfile post covers it.
What a team needs from the folder
Three properties, and you can check any product against them: the skill is registered by name, granted per agent, and changed through review.
Kortix treats the folder as two decisions. A new project starts from a starter manifest that keeps skills as a registry and a grant. The two are separate keys.
# Workspace skills: folders under skills/, registered by name. Each agent then
# enables them with its own `skills:` grant.
skills: {}
agents:
worker:
skills: "*"skills: {} is the registry. A folder under skills/ is not available to anything until it is registered there by name. The worker block's skills: "*" is the grant, and it is per agent. The same skill can be registered once and enabled for one agent, five agents, or all of them. Registering a skill and granting it are two decisions made in two places. A reviewer sees both in the diff.
The Kortix docs describe the rest of the lifecycle in the same terms. "Shared. One skill can serve many agents. You choose which agents may load it." "Versioned. Skills are files in your project’s git repository, so every change is recorded with who made it." A marketplace install "starts a session that adds the skill to your project and opens a change request for you to review." And when an agent improves a skill, "An agent can propose an edit to a skill. A person decides whether it lands."
That last step is what turns a folder into something a team can audit. Session work reaches main through a change request. Merge is default-deny for agents. An agent can edit its own configuration on its session branch and propose the change. A person approves it.
A short decision guide
One person, one machine: the product's own settings are enough. Upload the ZIP in claude.ai or drop the folder in ~/.claude/skills/, and move on. You are the only person who can change it, so ownership is not a question yet.
A team: put the folder in a repository the company owns, register it once, and grant it per agent. Then every change is a diff with an author, a reviewer and a revert. The product you run the agent on matters less than where the skill lives. Put it somewhere your team already reviews code.
The test is one question. Ask who can change the description of a skill your production agent loads. If the answer is whoever holds the account, you have an account-level skill. If the answer is whoever can merge to that directory, you have a team one.
If you want the folder, the grant and the review in one repo, start with Kortix. Free to start, free to self-host.