Electron orchestrator

Skill Sheshiyer/skill-clusters/skills/electron-orchestrator

Hub-and-spoke agent-skill clusters, one per stack (Astro·GSAP·Remotion, Tauri, …). Installable via skills.sh.

Install

npx -y skills add Sheshiyer/skill-clusters --skill electron-orchestrator

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

3.3 KB, 706 tokens by cl100k_base, as published. Nobody here has run it

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).

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.