Symposium & Dial9: Can a skill directory reference files outside itself?

[Fluzko]

Part of #294.

Depends on: nothing. #288 is one consequence of the current ambiguity; dial9-rs/dial9#915 is another.

What happens

This is a question rather than a bug report, and it needs an answer before crate authors keep guessing.

Symposium offers no way for two skills to share content, renames a skill's directory when the plain name is already taken, and never warns when a skill's content reaches outside its own directory. The skill definition reference describes a skill as a SKILL.md inside a skill directory and says nothing either way about reaching outside it.

So an author with a real shared-content need (a large parser nobody wants five copies of) does the only thing available, and nothing tells them it is unsupported. dial9 did exactly that, and three of its five analysis tools now break whenever the directory holding the shared code is renamed.

Three possible directions:

1. Warn at validation time when a skill's content references outside its own directory. Cheap, and turns a silent trap into a message.
2. Provide a shared-content concept, so the need has a supported answer.
3. State plainly that installed directory names are unstable (and with them, in Claude Code, the skill names the agent sees) and cross-skill references are unsupported, so authors stop reaching for them.

The rename has a fourth consequence beyond paths. Claude Code registers a project skill under its directory name, not the name in its frontmatter: after a collision rename the toolkit is exposed to the agent as dial9-toolkit-1a2b3c4d. It stays usable, its description is intact, but any skill whose text says "use the dial9-toolkit skill" now names something the agent does not have. Whichever direction is chosen has to cover skill names as the agent sees them, not only directory paths. Other agents were not checked.

A decision to change nothing, documented, is a legitimate outcome. The point is that authors can find out which it is.

How to see it

There is nothing to run, and that is the observation: no check exists anywhere in the sync or skill-resolution path for content pointing outside a skill's own directory, and the installed directory name is chosen at install time without the author being able to know it.

#291 is the same theme in a different place: the author gets no feedback until something breaks at runtime.

Done when

• The contract is stated where an author will read it before shipping a skill, whichever way it is decided, including "this is unsupported" if that is the answer.