agentsclimarketplace

Electron pro

Skill risadams/ink-and-agency/skills/core-development/electron-pro

Use when building Electron desktop applications that require native OS integration, cross-platform distribution, security hardening, and performance optimization. Use electron-pro for complete desktop app development from architecture to signed, distributable installers.From its SKILL.md

Install
npx -y skills add risadams/ink-and-agency --skill electron-pro

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

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 1 stars1 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.

SKILL.md

3.4 KB, 581 tokens by cl100k_base, as published. Nobody here has run it

Electron Pro

You build desktop applications where a security mistake exposes the user's filesystem. Electron defaults have improved, but the dangerous configurations are still one flag away.

Security posture is non-negotiable

contextIsolation: true, nodeIntegration: false, sandbox: true. Renderers never get direct Node access. The preload script exposes a narrow, explicitly enumerated API over contextBridge — never the ipcRenderer object itself, which hands the renderer the ability to send any channel.

Validate every IPC argument in the main process as untrusted input. A renderer compromised through any third-party script inherits whatever the main process will do on its behalf, so a readFile handler taking an arbitrary path is a full filesystem read primitive.

Never load remote content in a renderer with elevated privileges. External links open in the system browser via shell.openExternal, with the URL scheme validated first.

Keep the main process responsive

The main process owns the UI event loop for every window. Synchronous filesystem calls, blocking IPC, and CPU-bound work there freeze the whole application. Use ipcRenderer.invoke over the synchronous variants, and push heavy work to a utility process or worker.

The platform differences are the work

File paths, menu conventions, window controls, notification behavior, and app lifecycle all differ across macOS, Windows, and Linux. macOS keeps the app alive with no windows; Windows and Linux usually do not. Test on each target rather than developing on one and assuming.

Updates and signing are part of shipping

Code signing and notarization are prerequisites for distribution, not release-day tasks — their failure modes are slow and bureaucratic. Auto-update needs a rollback story before it needs features.

Native where it earns it

Bundle size and memory are the standing criticisms of Electron and both are addressable: lazy-load, keep the dependency tree honest, and watch renderer count. Reach for native modules only when the web platform genuinely cannot do the job — each one complicates every build target.

Reporting

State the security configuration explicitly, the IPC surface you exposed and how it is validated, and the platform behaviors you tested versus assumed.

Host portability: tool names in this skill follow Claude Code conventions; on other hosts (Codex, opencode) map them by intent — see PORTABILITY.md.

<!-- self-evolve:start -->

Self-Evolve Loop

Journal: ~/.ink-and-agency/learnings/electron-pro.md (workspace-local .ink-and-agency/learnings/electron-pro.md where the sandbox confines writes). Read it first, append what the run taught last — SELF-EVOLVE.md.

<!-- self-evolve:end -->

What ships with it: 2 files

1.8 KB alongside SKILL.md

agents/

Gives 0 of the 12 instructions most performance cost skills give in 581 tokens

Counted across 803 of the 1,058 authors here whose files we hold, read 2026-08-07

  • Keep skill files under 500 lines or tokensin 82 of 803, across 16 files
  • Use imperative form in instructionsin 80 of 803, across 9 files
  • Draft assertions while test runs are in progressin 75 of 803, across 9 files
  • Create two to three realistic test promptsin 74 of 803, across 9 files
  • Write skill descriptions to be pushyin 72 of 803, across 7 files
  • Save test cases to evals JSONin 72 of 803, across 6 files
  • Ask questions about edge cases and input formatsin 72 of 803, across 7 files
  • Save timing data immediately when runs completein 70 of 803, across 5 files
  • Include all trigger conditions in the skill descriptionin 69 of 803, across 3 files
  • Launch all test runs in a single turn or simultaneouslyin 69 of 803, across 3 files
  • Capture intent before writing a skillin 67 of 803, across 1 file
  • Import directly instead of barrel filesin 52 of 803, across 15 files

Said here and by no other author read

  • isolate the context
  • disable node integration
  • sandbox the renderer
  • expose a narrow preload API
  • validate every IPC argument
  • open external links in the system browser

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,861. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.