Symposium & Dial9: Skill distribution does not deliver correctly end to end

[Fluzko]

What this is

dial9 is the first substantial consumer of Symposium's skill distribution, and the pipeline does not deliver its skills correctly. Working through it surfaced six defects in Symposium, one in the registry entry, and five in dial9. This tracks all twelve, so the first release where this works delivers something correct.

Three independent causes:

1. Symposium's distribution. Symlinked files are dropped on install, so a skill can arrive incomplete with no warning. A version declared on a plugin reference is accepted and then ignored. A plugin the user explicitly disabled installs anyway.
2. Where the skills live. They are served from a crate no application depends on, so the version a project pins cannot be applied and the newest release always wins.
3. dial9's own code and docs. One tool both crashes on traces that carry custom events and, when it does run, reports problems the trace has no evidence for. Several documented commands do not work.

The work

Symposium - symposium-dev/symposium

• Symposium & Dial9: Installing a skill silently drops its symlinked files #288
• Symposium & Dial9: A plugin reference's declared version is accepted and ignored #289
• Symposium & Dial9: A disabled plugin installs anyway, and the status output disagrees with what happened #290
• Symposium & Dial9: A malformed crate manifest is dropped without telling the author #291
• Symposium & Dial9: Can a skill directory reference files outside itself? #292
• Symposium & Dial9: Documentation contradicts the code in eight statements #293

Registry - symposium-dev/recommendations

• Symposium & Dial9: Point the dial9 entry at the crates projects actually depend on recommendations#23

dial9 - dial9-rs/dial9-tokio-telemetry

• Symposium & Dial9: Commands and references in the skills that do not work dial9-rs/dial9#913
• Symposium & Dial9: Analysis tools that crash or report unsupported findings dial9-rs/dial9#914
• Symposium & Dial9: Tools break when the toolkit's directory is renamed dial9-rs/dial9#915
• Symposium & Dial9: The setup skill never reaches Symposium users dial9-rs/dial9#916
• Symposium & Dial9: Skills are served from a crate nobody depends on dial9-rs/dial9#917

Order

Two hard constraints. dial9-rs/dial9#917 needs dial9-rs/dial9#915, because a shared library in dial9 hardcodes the skill layout and dial9-rs/dial9#917 changes where skills come from. And symposium-dev/recommendations#23 must not land before the dial9 release carrying dial9-rs/dial9#917: flipping the registry entry first makes every project at or above the version floor match a serving edge on a crate that has no skills yet, and they get nothing.

Two preferences. Do #288 early, because the fix for dial9-rs/dial9#917 introduces a symlinked directory of skills. Symposium follows the directory link, but drops the symlinked files inside it, so a source-tree install delivers every skill with the toolkit's three linked libraries missing, silently, and the Symposium path to dial9-rs/dial9#917 cannot be sanity-checked locally until #288 lands. dial9-rs/dial9#917 itself can be checked without Symposium: the binary's own unpack (dial9-viewer agents skills), a cp -RL of the source tree and the packaged .crate all show real files; only the Symposium install path is blocked. Do #293 last, because one of its eight statements depends on how #289 is resolved.

Everything else can be picked up in any order. dial9-rs/dial9#913, dial9-rs/dial9#914 and dial9-rs/dial9#915 all edit files under the same dial9 directory, and dial9-rs/dial9#913 in particular edits a script that dial9-rs/dial9#914 and dial9-rs/dial9#915 also touch, so give those three to one person or sequence them.

Worth knowing

Revision of 2026-09-17. dial9-rs/dial9#917 now serves the skills from a single crate, dial9, the only dependency the 0.5 line documents. A project declaring only dial9-tokio-telemetry is the 0.3 shape; published 0.3.x versions are immutable, so it keeps the fallback (newest viewer, skew accepted). symposium-dev/recommendations#23 was amended to two edges. One rule found while verifying it: a registry entry is gated on its top-level depends-on before any edge is evaluated, so the entry must keep dial9-tokio-telemetry in that list or the 0.3 shape gets zero skills instead of the fallback.

Two Symposium behaviours surfaced by the #917 review, not covered by #288 to #293 and only documented for now (dial9's AGENTS.md, "Where the skills live"): a crate reached both through a registry entry and through user consent (a project declaring dial9 and dial9-viewer directly, consenting to the viewer) installs every skill twice under hash-suffixed names, because the two sources hash differently; and the consent prompt for a crate a registry entry already serves is a no-op either way, accepting changes nothing and declining is not honoured (#290).

The current registry entry cannot be read by the latest published Symposium: the manifest format changed after that release, and the published parser rejects unknown fields. So this integration only works against an unreleased build today. Nobody is affected yet, so it does not gate the work, but a release is eventually needed for any of it to reach anyone. Several reproductions in the linked issues depend on this, and say so.

Two more things learned while working the batch. Claude Code registers a project skill under its directory name, not the name in its frontmatter, so a skill Symposium renamed on a collision is exposed to the agent as <name>-<hash> (see #292). And every reproduction here, plus variants and headless Claude runs, is now scripted in a standalone harness (dial9-skills-e2e, local for now): run it against a fresh upstream/main before editing any of these issues, since at least one claim (the top-level --bucket in dial9-rs/dial9#913) was fixed upstream the day the batch was filed.