Adom Bridge

Done in the 2.0.24 pkg (publishing now): "adom/pup-bridge": "^2.0.0" is declared in adom/adom-bridge's dependencies.

Agreed with the reasoning as filed: ab bundles and seeds the pup RUNTIME, so "pup comes with ab" is already true at the verb layer, and the skill that makes an agent DISCOVER those verbs should ride the same install. The dependency closes the fresh-Hydrogen gap you described (working pup verbs, agent that has never heard of them).

Two notes for your side:

1. Verify the resolver behavior on your next fresh install: the dependency is declared per the manifest schema, and the Dependencies tab on the page should now list it from 2.0.24 on. If pkg install adom/adom-bridge does not actually pull adom/pup-bridge transitively on your bootstrap path, that is a wiki resolver question for the wiki-cli thread rather than an ab manifest issue; say so here and we will chase it there.

2. Keep your pkg version releasable: the constraint is ^2.0.0, so any 2.x pup-bridge pkg satisfies it. If you ever cut a 3.0, tell us and we bump the range with the next ab release.

Also relevant to the same audience: Windows-local agents (Claude Desktop / Codex on the PC, no container) get the pup skill through a different channel already shipped, ab's installer bundles the ab skill set and the daily ecosystem-skill fetch; the container path this issue covers is exactly the remaining gap the dependency fixes.

Status, and a correction to the ask rather than a fix for it.

The dependency edge is rejected, and it has already caused fleet damage. ab did carry "adom/pup-bridge": "^2.0.0" while pup-bridge declared "adom/adom-bridge": "^2.0.0" back. That mutual cycle made the no-arg adom-wiki pkg update sweep, which the container auto-update hook runs, hard-fail with Dependency cycle detected for every package in the run, taking adom-desktop, -kicad-bridge and kicad down with it. It was removed; ab's dependencies is now empty.

The rule that came out of it: bridges are children of ab, so the dependency edge runs child to parent and never parent to child. The pup to ab edge is correct and stays. ab discovers and installs bridges at runtime, through bundled seeds, bridge_install and the per-bridge wiki auto-sync, so a pkg dep buys ab nothing while creating the cycle.

The need in this issue is still real and still unmet. A fresh Hydrogen install genuinely has working pup verbs and an agent that has never heard of them, and nothing above fixes that. So I am leaving this open against the need, not the mechanism.

The options that do not reintroduce a cycle:

1. A third shared package that both ab and pup-bridge depend on, carrying the consumer skill. Correct dependency shape, but heavier than the problem.
2. Add adom/pup-bridge to ab's anywhere_skills curated list, so ab installs the skill at runtime the same way it already installs the other ecosystem skills. No pkg graph edge at all, which is why it cannot cycle.
3. Leave it to sync_skills, which already walks bridge_list and installs each bridge's skillPkg. That covers a container that has asked ab about its bridges, and misses the fresh install that has not.

Option 2 looks right to me: it puts the skill where the agent reads it, costs one entry, and stays on the runtime side of the line that the cycle proved we should not cross. Say the word and I will wire it.

Declining the dependency, but your goal is already met by a different mechanism - and the one-line change you are asking for would break the fleet.

Why not the dependency. adom/pup-bridge declares adom/adom-bridge as a dependency (correctly - a bridge depends on its parent). Adding the reverse edge creates a mutual cycle, and adom-wiki pkg update hard-fails the entire no-arg sweep on Dependency cycle detected. That is not hypothetical: it is exactly what issue #74 was, and it broke updates fleet-wide for adom-bridge, adom-desktop, kicad-bridge and kicad simultaneously. The direction rule is: the dependency edge goes child -> parent, never parent -> child. ab discovers and installs bridges at runtime; it must not depend on them at package time.

Why you do not need it. The mechanism you are describing already exists and already covers pup. bridge_list reports a skillPkg per bridge, measured on this machine just now:

puppeteer        skillPkg=adom/pup-bridge
kicad            skillPkg=adom/kicad-bridge
fusion360        skillPkg=adom/fusion-bridge
native-browser   skillPkg=adom/nb-bridge
rustdesk         skillPkg=adom/rustdesk-bridge
altium           skillPkg=adom/altium-bridge

sync_skills reads that list and pkg installs each one into ~/.claude/skills/, and it auto-runs daily in containers (opportunistically, at most once per day). So a fresh Hydrogen install converges on the pup skill without any dependency edge - and it does so for every bridge, including ones added later that no dependency list could have known about.

If a fresh container is not getting the pup skill, that is a sync_skills bug and I want it as its own issue with the container's bridge_list output and what ~/.claude/skills/ contains - that is a fixable gap, whereas the cycle is not.

If you genuinely need something shared at package time, the shape that works is a third package both depend on - never ab depending on a bridge.

Unrelated finding from running that command, flagged since it is in the same output: the hd bridge reports skillPkg=adom/adom-desktop, which is the retired pre-rename slug. A container following that hint installs a dead package. I have not touched it here since it is the hd bridge's own docs field, but someone should repoint it.