electron-best-practices
Electron Best Practices
Use this skill for Electron work that needs durable guidance without relying on copied docs.
Default Stance
- Prefer Electron Forge for new apps.
- Prefer TypeScript unless the project is already committed to plain JavaScript.
- Prefer preload scripts with
contextIsolation: trueand narrow IPC bridges. - Prefer Vite for a new modern frontend build, but stay with Webpack or another existing toolchain when the project already uses it.
- Defer version-sensitive config, CLI flags, and API edge cases to the official docs in
references/doc-index.md.
Workflow
- Identify whether the task is about architecture, security, IPC, packaging, updates, or tooling.
- Open
references/doc-index.mdfirst to choose the right official source. - Open one focused reference file from this skill for durable guidance:
references/architecture-and-security.mdreferences/forge-workflows.mdreferences/common-recipes.md
- Preserve the current project stack when it already exists. Only apply the Forge-first defaults when the user has not chosen another path.
- When exact config or command syntax matters, verify it against the linked Electron or Electron Forge docs instead of guessing or reusing stale snippets.
Reference Routing
- Use
references/architecture-and-security.mdfor main vs renderer vs preload boundaries, secure IPC design, BrowserWindow defaults, and hardening. - Use
references/forge-workflows.mdfor scaffolding, TypeScript setup, Vite vs Webpack, makers, publishers, debugging, and update planning. - Use
references/common-recipes.mdfor evergreen implementation shapes such as secure IPC bridges, window lifecycle, menus and tray, native dialogs, and updater entrypoints. - Use
references/doc-index.mdwhenever you need the current official page for syntax, options, or release-sensitive behavior.
Guardrails
- Do not expose raw Node access to renderer code unless the project has a deliberate and reviewed reason.
- Do not widen IPC channels more than the task requires.
- Do not migrate an existing build tool without a user reason.
- Do not treat this skill as a local mirror of Electron docs; treat it as a routing and decision layer over official docs.
More from mylesmcook/mcook-skills
adversarial-review
Use this skill when you need a serious code review, diff review, or implementation-plan review from independent reviewers. In Codex hosts, prefer a fresh Codex subagent for the Codex reviewer; otherwise use the Codex, Claude Code, and Gemini reviewer paths when available. Return a PASS, CONTESTED, or REJECT verdict.
13subagent-driven-development
Use after an implementation plan is approved to execute mostly independent tasks through fresh subagents with scoped context, harness-aware model routing, proportional review gates, and mandatory controller verification.
10brainerd
>
10simple-code
Reduce incidental complexity in code and design. Use when shaping APIs, module boundaries, refactors, tests, naming, and architecture tradeoffs with a bias toward concrete, local, reversible solutions.
7git-it-out
Use this skill when the user explicitly wants final end-of-session closeout and no more branch or PR limbo: proper verification, proper commits, main/mainline landing, push, repo-native merge/release/deploy/publish steps, tracker updates, Entire/checkpoint handling when configured, and a concise handoff. Reach for it on prompts like 'git it out', 'get it out', 'ship this', 'I'm done', 'I'm going to bed', 'take this off my plate', 'finish the session', or 'get this into production'. Do not use it for greenfield implementation, open-ended debugging, broad refactors, or inventing a release process from scratch.
7laws-of-taste
>-
6