Electron Orchestrator
Entry skill for Electron desktop apps (Chromium + Node.js). It places a task on the
process × concern map and routes. The defining model — the main/renderer split and the
context-isolation security boundary — lives in electron-core; read it before wiring IPC
or exposing anything to the renderer.
Cluster map (routing targets)
electron-core — process model (main vs renderer vs preload), the security checklist, app lifecycle, and the Electron-vs-Tauri decision.electron-main-renderer-ipc — the IPC contract: contextBridge in a preload, ipcMain.handle/ipcRenderer.invoke, typed channels, no remote module.electron-security — the hardening checklist: contextIsolation: true, nodeIntegration: false, sandbox: true, CSP, validate IPC inputs, restrict navigation/window.open.electron-builder-packaging — build & distribute: electron-builder/Forge, per-OS installers, code signing (Authenticode / Apple Developer ID), notarization.electron-auto-update — autoUpdater / electron-updater, update feeds, signing for updates, staged rollouts.
Routing Rules by Intent
- "How do main and renderer talk?" →
electron-main-renderer-ipc (+ electron-core for the trust boundary).
- "Is my app secure / harden it" →
electron-security.
- "Build installers / sign / notarize" →
electron-builder-packaging.
- "Ship updates to installed apps" →
electron-auto-update.
- "Use a native Node addon" →
electron-core (ABI/electron-rebuild notes) → packaging.
- "Should I even use Electron?" →
electron-core (Electron vs Tauri tradeoff); for the Rust/web alternative see the tauri cluster.
Standard Operating Flow
- Locate the task: process model / IPC, security, packaging, or updates.
- If it crosses the main↔renderer boundary, pull the trust model from
electron-core first — the renderer is untrusted.
- Delegate; for "ship it", sequence package → sign → notarize → wire auto-update.
- Return: chosen spoke(s), the security implications, target OS(es), and the next action.
Guardrails
See electron-core. In short: the renderer is untrusted — keep contextIsolation on,
nodeIntegration off, sandbox on; expose only a minimal, typed contextBridge API (never the
whole ipcRenderer or Node); validate every IPC argument in the main process; set a strict CSP;
and always sign + notarize before distributing or auto-updating.
Loading spokes on demand
To keep CLI startup context lean, this cluster's spokes are not separately registered as skills — only this orchestrator and its *-core are enumerated. When you route to a spoke named above, load it on demand by reading its file:
~/.agents/skill-clusters/skills/<spoke-name>/SKILL.md (or skills/<spoke-name>/SKILL.md inside the skill-clusters repo).
1---2name: electron-orchestrator3description: Route an Electron desktop-app task to the right spoke — the main/renderer process model & IPC, the security checklist (context isolation, sandbox, CSP), packaging/signing/notarization, auto-update, or native modules. USE WHEN building, securing, or shipping an Electron app but the specific concern isn't named. For a smaller/Rust alternative, weigh the tauri cluster.4---56# Electron Orchestrator78Entry skill for **Electron** desktop apps (Chromium + Node.js). It places a task on the9process × concern map and routes. The defining model — the **main/renderer split** and the10**context-isolation security boundary** — lives in `electron-core`; read it before wiring IPC11or exposing anything to the renderer.1213## Cluster map (routing targets)1415- `electron-core` — process model (main vs renderer vs preload), the security checklist, app lifecycle, and the Electron-vs-Tauri decision.16- `electron-main-renderer-ipc` — the IPC contract: `contextBridge` in a preload, `ipcMain.handle`/`ipcRenderer.invoke`, typed channels, no remote module.17- `electron-security` — the hardening checklist: `contextIsolation: true`, `nodeIntegration: false`, `sandbox: true`, CSP, validate IPC inputs, restrict navigation/`window.open`.18- `electron-builder-packaging` — build & distribute: electron-builder/Forge, per-OS installers, code signing (Authenticode / Apple Developer ID), notarization.19- `electron-auto-update` — `autoUpdater` / `electron-updater`, update feeds, signing for updates, staged rollouts.2021## Routing Rules by Intent2223- **"How do main and renderer talk?"** → `electron-main-renderer-ipc` (+ `electron-core` for the trust boundary).24- **"Is my app secure / harden it"** → `electron-security`.25- **"Build installers / sign / notarize"** → `electron-builder-packaging`.26- **"Ship updates to installed apps"** → `electron-auto-update`.27- **"Use a native Node addon"** → `electron-core` (ABI/`electron-rebuild` notes) → packaging.28- **"Should I even use Electron?"** → `electron-core` (Electron vs Tauri tradeoff); for the Rust/web alternative see the **tauri** cluster.2930## Standard Operating Flow31321. Locate the task: process model / IPC, security, packaging, or updates.332. If it crosses the main↔renderer boundary, pull the trust model from `electron-core` first — the renderer is **untrusted**.343. Delegate; for "ship it", sequence package → sign → notarize → wire auto-update.354. Return: chosen spoke(s), the security implications, target OS(es), and the next action.3637## Guardrails3839See `electron-core`. In short: **the renderer is untrusted** — keep `contextIsolation` on,40`nodeIntegration` off, `sandbox` on; expose only a minimal, typed `contextBridge` API (never the41whole `ipcRenderer` or Node); validate every IPC argument in the main process; set a strict CSP;42and always sign + notarize before distributing or auto-updating.4344## Loading spokes on demand4546To keep CLI startup context lean, this cluster's spokes are **not** separately registered as skills — only this orchestrator and its `*-core` are enumerated. When you route to a spoke named above, **load it on demand** by reading its file:4748`~/.agents/skill-clusters/skills/<spoke-name>/SKILL.md` (or `skills/<spoke-name>/SKILL.md` inside the skill-clusters repo).
Sheshiyer