Adom Bridge
Public Made by Adomby adom
Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-onl
Bridge SDK: add a standard section + template for filing issues against AD (and other repos a bridge depends on)
A bridge author (human or AI) constantly finds AD-core bugs and gaps during a normal dev cycle, and the natural mistake is to file them on the bridge's OWN wiki page issue list, where AD-core never sees them. I just did exactly that (filed three AD-core bridge-lifecycle asks as pup bridge issue #18, a note to myself; moved to this repo as a sibling issue). Since every bridge depends massively on AD-core, this will be one of the most common author actions, so the Bridge SDK should teach it with a standard template.
Ask: add a short section to the Bridge SDK billboard (skills/BRIDGE_SDK.md -> the
adom-desktop-bridges page, all three copies README.md / SKILL.md / bridges-SDK.md). Proposed
paste-ready content below. Tune wording as you like; the load-bearing rule is "file the issue on the
repo that owns the code that must change, and for AD-core asks that means adom/adom-desktop, not your
own page."
Filing issues against AD (and the other repos you depend on)
You WILL find AD-core bugs and gaps while building your bridge. That is expected and useful. But file them in the RIGHT repo's issue list, or the people who can fix them never see it.
The rule: an issue lives on the issue list of the repo that OWNS the code that must change.
- A bug in YOUR bridge's verb / hint / self-heal / status chip -> YOUR page's issue list (or just fix it, you own it).
- A missing or broken AD-CORE capability (a lifecycle verb, a spawn / provision / bind behavior, the
relay passthrough dropping a field, a manifest field AD must honor, the status-chip contract) ->
adom/adom-desktop's issue list, NOT your own page. AD-core's maintainers and AI watchadom/adom-desktop; they do NOT read your bridge page's issues. An AD ask filed on your own page is a note to yourself. - A wiki or CLI bug ->
adom/wiki. A sibling bridge's bug -> that bridge's page.
How (the CLI):
adom-wiki issue list adom/adom-desktop # FIRST: skim for a dup, comment if one exists
adom-wiki issue create adom/adom-desktop \
--title "<verb or subsystem>: <the gap in one line>" \
--category bug-report \
--body "$(cat your-writeup.md)"
Write the body like a good bug report: what you hit live (with the date + AD version), the measured behavior, the AD-owned root cause if you found it, and a concrete ask. Separate clearly what is AD-core's to fix from what is yours, and say so explicitly so the two are never conflated.
After you file: the AD-core thread replies on that issue. Read the reply, it may change your plan (e.g. "fixed in AD X.Y, bump your pin"). That issue thread is the cross-repo channel; keep the loop closed there.
Why this matters most for AD: AD-core spawns you, provisions your runtime, relays your verbs, and installs you, so AD is the repo you will file against most often. Get the destination right the first time.
Precedent that this is the established pattern (all correctly on adom/adom-desktop): #26 / #27 (pup -> AD Chrome-for-Testing), #16 (pup -> AD window-verb interception), #3 / #20 / #21 (Bridge SDK asks). The template just makes new authors do by default what these did by hand.