Two unrelated skills can both be called code-review. Or security. Or pdf-processing.

Which one did the agent load? A good question. Before anyone says “security.” We’ve already solved this problem in software packaging. Skills still treat a friendly flat name — just the label, no owner — as if it were identity.

What the current spec does

The Agent Skills specification requires a simple name that matches the skill folder. Valid examples in the spec itself look like pdf-processing, data-analysis, and code-review.

Optional metadata can hold an author or version, but that is not a standard namespace — a publisher prefix that makes two code-review skills different things.1

Illustrative names, not current Skills syntax.

So the friendly label is the identity. That worked when Skills lived mostly as local folders on one machine. We’ve been here before — every package ecosystem hit the same wall once more than one publisher used the same short name.

Collisions exist because names are flat

Client guidance says that when two skills share a name, project-level takes priority over user-level, with a warning when one covers the other.2

The same guidance notes that project skills come from the repo — which may be freshly cloned and untrusted — and recommends a trust check so a new clone doesn’t silently inject instructions.

Those are observations, not a claim that project skills are malware. Precedence exists because the name is flat. Trust checks matter for any local project content. Ambiguous identity creates operational confusion first — and an avoidable attack surface second, as identity hygiene, not as an exploit story.

We’ve already learned this lesson

Other ecosystems kept friendly labels and added durable identity:

  • npm uses scopes like @organization/package3
  • Maven uses groupId + artifactId + version4
  • Docker Hub uses namespace/repository:tag5

The lesson is not a dunk on Skills authors. Labels that work on one machine get awkward when many publishers ship the same friendly name.

Ecosystem growth needs identity growth

Skills are moving from local folders toward shared ecosystems. On one laptop, a flat code-review is fine. Across many publishers, collisions show up once they share the same label — and a quiet moment of “wait, which one?” for whoever is watching the agent.

Computing already learned that display names and identities diverge as soon as more than one publisher enters the room. An emerging AI tooling ecosystem appears to be relearning an old software-engineering lesson — not inventing a brand-new security problem.

Community proposals float shapes like owner/skill@version for cross-references. That is a proposal, not the current standard.6

What we can do while the standards catch up

We don’t need to wait for agreement on namespaces to ask where a skill came from. Before relying on one, identify its source, keep the exact revision you reviewed, and check which copy your agent will load. If two skills share a name, resolve that ambiguity before depending on the result. If your tool cannot show which copy it loaded, treat that as a limit on what you can verify.

A short record can help: where the skill came from, which revision you reviewed, what you use it for, and who will maintain it. Make updates deliberate, review changes to the instructions and any included scripts, and keep a way to return to the previous version if something breaks.

Knowing where instructions came from helps us inspect and reproduce the work. It does not prove those instructions are sound or suitable for every task. That still takes review, testing, and judgment.

A future standard may change how we write a skill’s identity. Until then, these habits can reduce the friction of conflicting names and the risk of relying on instructions we did not mean to load. When someone asks, “Which one did the agent load?” we should have an answer they can check.

Footnotes

  1. Agent Skills specification: https://agentskills.io/specification ↩

  2. Adding Skills support (collisions + trust): https://agentskills.io/client-implementation/adding-skills-support ↩

  3. npm scopes: https://docs.npmjs.com/cli/v11/using-npm/scope/ ↩

  4. Maven naming conventions: https://maven.apache.org/guides/mini/guide-naming-conventions.html ↩

  5. Docker Hub repositories: https://docs.docker.com/docker-hub/repos/ ↩

  6. Community proposal only (not current spec): https://github.com/agentskills/agentskills/issues/256 ↩