app

Adom Desktop

Public Made by Adom

by adom

Installs the adom-desktop CLI and its Claude skills INTO A CLOUD CONTAINER so an AI assistant there can understand and drive Adom Desktop over the relay. This is the container side, NOT the app itself. The Adom Desktop app is the signed Windows installer under Download below: run THAT on the PC you want the AI to control. Rule of thumb: pkg install here (in your Linux container), Download there (on your Windows PC). Once installed, the AI can drive file transfer, screenshots, notifications, KiCa

adom-desktoptauriclaude-codebridgekicadfusion360puppeteerdesktop-automation
Overview Files Skills Discover Packages Releases Dependencies Issues6 Breadcrumbs Pull Requests Activity
Closed feature request

Bundle the adom-wiki CLI with Adom Desktop so wiki commit/push can run on the user's PC (avoid the pull-to-container round trip)

noah · 11d ago ·closed by John Lauer

Problem

When an AI assistant (running in the cloud/Docker container) version-controls a users local project on the Adom Wiki, the files live on the USERS PC but the adom-wiki CLI only exists in the container. So every commit is a round trip:

  1. adom-desktop pull_file each changed file from the PC into the container,
  2. adom-wiki repo push <owner>/<slug> --files ... -m "..." from the container.

For a KiCad project that means copying the .kicad_pro/.kicad_sch (+ hierarchical sub-sheets) / .kicad_pcb / .step / .glb across on every single commit — slow, brittle (a missed sub-sheet = a broken commit), and it duplicates files that already sit on the PC. It also means the containers copy and the PCs copy can drift.

Request

Bundle the adom-wiki CLI with Adom Desktop (the AD installer already drops adom-desktop-cli.exe into %LOCALAPPDATA%\Adom Desktop\ and puts it on PATH — ship adom-wiki.exe the same way), and expose a verb so a cloud/relay AI can run wiki repo operations DIRECTLY on the PC where the files already are. Sketch:

  • adom-desktop wiki_push {repo, cwd, files[], message} → runs adom-wiki repo push locally in the project dir on the PC, no pull needed.
  • Or a generic adom-desktop wiki_exec {args[], cwd} passthrough to the bundled adom-wiki.
  • Auth: reuse the users existing adom-wiki` token/session on the PC (AD is already signed in to Adom Cloud), so the AI never handles credentials.

Benefit

commit my project becomes a single call that runs where the files live — no per-file pull_file, no missed sub-sheets, no container/PC drift. This is the #1 friction point in the "version-control my KiCad board on the wiki from a cloud AI" workflow today.

Environment

  • adom-desktop 1.9.102; adom-wiki CLI 1.0.22
  • Reproduced repeatedly 2026-07-09..10 committing a hierarchical KiCad project to a private wiki page

1 Reply

John Lauer · 6d ago

Shipped in AD 1.9.116. (1) adom-wiki.exe now ships in the installer next to adom-desktop-cli.exe in %LOCALAPPDATA%\Adom Desktop\ (verify_bundle gates it so it can never silently drop out). (2) New verb wiki_exec, the generic passthrough you sketched: adom-desktop wiki_exec '{"args":["repo","push","adom/my-board","--files","board.kicad_pcb","board.kicad_sch","-m","rev B"],"cwd":"C:\Users\me\boards\my-board"}' runs adom-wiki ON the PC in the project dir, so commits need zero per-file pull_file and there is no container/PC drift. Auth: AD injects the signed-in user's session token as ADOM_WIKI_TOKEN; the caller never handles credentials. Returns {exitCode, stdout, stderr, timedOut, durationMs}. It is Tier-2 gated for relay callers (same class as shell_execute) since it writes to the wiki as the user; on John-style boxes with Bypass granted it just runs. Update the laptop AD to 1.9.116 (auto-update banner or relay apply_update) and refresh the container CLI to see the verb in the help map.

Log in to reply.