dk-frontend-skills 1.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude/settings.json +69 -0
- package/.claude/skills/agentation/SKILL.md +107 -0
- package/.claude/skills/frontend-code-review/SKILL.md +167 -0
- package/.claude/skills/frontend-code-review/references/checklist.md +298 -0
- package/.claude/skills/frontend-design/LICENSE.txt +177 -0
- package/.claude/skills/frontend-design/SKILL.md +42 -0
- package/.claude/skills/moai-framework-electron/SKILL.md +328 -0
- package/.claude/skills/skill-creator/SKILL.md +356 -0
- package/.claude/skills/skill-creator/references/output-patterns.md +82 -0
- package/.claude/skills/skill-creator/references/workflows.md +28 -0
- package/.claude/skills/skill-creator/scripts/init_skill.py +303 -0
- package/.claude/skills/skill-creator/scripts/package_skill.py +110 -0
- package/.claude/skills/skill-creator/scripts/quick_validate.py +95 -0
- package/.claude/skills/ui-ux-pro-max/SKILL.md +228 -0
- package/.claude/skills/ui-ux-pro-max/data/charts.csv +26 -0
- package/.claude/skills/ui-ux-pro-max/data/colors.csv +97 -0
- package/.claude/skills/ui-ux-pro-max/data/landing.csv +31 -0
- package/.claude/skills/ui-ux-pro-max/data/products.csv +97 -0
- package/.claude/skills/ui-ux-pro-max/data/prompts.csv +24 -0
- package/.claude/skills/ui-ux-pro-max/data/stacks/flutter.csv +53 -0
- package/.claude/skills/ui-ux-pro-max/data/stacks/html-tailwind.csv +56 -0
- package/.claude/skills/ui-ux-pro-max/data/stacks/nextjs.csv +53 -0
- package/.claude/skills/ui-ux-pro-max/data/stacks/nuxt-ui.csv +51 -0
- package/.claude/skills/ui-ux-pro-max/data/stacks/nuxtjs.csv +59 -0
- package/.claude/skills/ui-ux-pro-max/data/stacks/react-native.csv +52 -0
- package/.claude/skills/ui-ux-pro-max/data/stacks/react.csv +54 -0
- package/.claude/skills/ui-ux-pro-max/data/stacks/svelte.csv +54 -0
- package/.claude/skills/ui-ux-pro-max/data/stacks/swiftui.csv +51 -0
- package/.claude/skills/ui-ux-pro-max/data/stacks/vue.csv +50 -0
- package/.claude/skills/ui-ux-pro-max/data/styles.csv +59 -0
- package/.claude/skills/ui-ux-pro-max/data/typography.csv +58 -0
- package/.claude/skills/ui-ux-pro-max/data/ux-guidelines.csv +100 -0
- package/.claude/skills/ui-ux-pro-max/scripts/core.py +238 -0
- package/.claude/skills/ui-ux-pro-max/scripts/search.py +61 -0
- package/.claude/skills/vue/SKILL.md +103 -0
- package/.claude/skills/vue/references/components.md +323 -0
- package/.claude/skills/vue/references/composables.md +358 -0
- package/.claude/skills/vue/references/directives.md +225 -0
- package/.claude/skills/vue/references/gotchas.md +438 -0
- package/.claude/skills/vue/references/provide-inject.md +174 -0
- package/.claude/skills/vue/references/reactivity.md +289 -0
- package/.claude/skills/vue/references/router.md +181 -0
- package/.claude/skills/vue/references/testing.md +294 -0
- package/.claude/skills/vue/references/typescript.md +172 -0
- package/.claude/skills/vue/references/utils-client.md +156 -0
- package/CLAUDE.md +361 -0
- package/package.json +16 -0
- package/scripts/copy-skills.js +68 -0
|
@@ -0,0 +1,177 @@
|
|
|
1
|
+
|
|
2
|
+
Apache License
|
|
3
|
+
Version 2.0, January 2004
|
|
4
|
+
http://www.apache.org/licenses/
|
|
5
|
+
|
|
6
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
7
|
+
|
|
8
|
+
1. Definitions.
|
|
9
|
+
|
|
10
|
+
"License" shall mean the terms and conditions for use, reproduction,
|
|
11
|
+
and distribution as defined by Sections 1 through 9 of this document.
|
|
12
|
+
|
|
13
|
+
"Licensor" shall mean the copyright owner or entity authorized by
|
|
14
|
+
the copyright owner that is granting the License.
|
|
15
|
+
|
|
16
|
+
"Legal Entity" shall mean the union of the acting entity and all
|
|
17
|
+
other entities that control, are controlled by, or are under common
|
|
18
|
+
control with that entity. For the purposes of this definition,
|
|
19
|
+
"control" means (i) the power, direct or indirect, to cause the
|
|
20
|
+
direction or management of such entity, whether by contract or
|
|
21
|
+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
|
22
|
+
outstanding shares, or (iii) beneficial ownership of such entity.
|
|
23
|
+
|
|
24
|
+
"You" (or "Your") shall mean an individual or Legal Entity
|
|
25
|
+
exercising permissions granted by this License.
|
|
26
|
+
|
|
27
|
+
"Source" form shall mean the preferred form for making modifications,
|
|
28
|
+
including but not limited to software source code, documentation
|
|
29
|
+
source, and configuration files.
|
|
30
|
+
|
|
31
|
+
"Object" form shall mean any form resulting from mechanical
|
|
32
|
+
transformation or translation of a Source form, including but
|
|
33
|
+
not limited to compiled object code, generated documentation,
|
|
34
|
+
and conversions to other media types.
|
|
35
|
+
|
|
36
|
+
"Work" shall mean the work of authorship, whether in Source or
|
|
37
|
+
Object form, made available under the License, as indicated by a
|
|
38
|
+
copyright notice that is included in or attached to the work
|
|
39
|
+
(an example is provided in the Appendix below).
|
|
40
|
+
|
|
41
|
+
"Derivative Works" shall mean any work, whether in Source or Object
|
|
42
|
+
form, that is based on (or derived from) the Work and for which the
|
|
43
|
+
editorial revisions, annotations, elaborations, or other modifications
|
|
44
|
+
represent, as a whole, an original work of authorship. For the purposes
|
|
45
|
+
of this License, Derivative Works shall not include works that remain
|
|
46
|
+
separable from, or merely link (or bind by name) to the interfaces of,
|
|
47
|
+
the Work and Derivative Works thereof.
|
|
48
|
+
|
|
49
|
+
"Contribution" shall mean any work of authorship, including
|
|
50
|
+
the original version of the Work and any modifications or additions
|
|
51
|
+
to that Work or Derivative Works thereof, that is intentionally
|
|
52
|
+
submitted to Licensor for inclusion in the Work by the copyright owner
|
|
53
|
+
or by an individual or Legal Entity authorized to submit on behalf of
|
|
54
|
+
the copyright owner. For the purposes of this definition, "submitted"
|
|
55
|
+
means any form of electronic, verbal, or written communication sent
|
|
56
|
+
to the Licensor or its representatives, including but not limited to
|
|
57
|
+
communication on electronic mailing lists, source code control systems,
|
|
58
|
+
and issue tracking systems that are managed by, or on behalf of, the
|
|
59
|
+
Licensor for the purpose of discussing and improving the Work, but
|
|
60
|
+
excluding communication that is conspicuously marked or otherwise
|
|
61
|
+
designated in writing by the copyright owner as "Not a Contribution."
|
|
62
|
+
|
|
63
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity
|
|
64
|
+
on behalf of whom a Contribution has been received by Licensor and
|
|
65
|
+
subsequently incorporated within the Work.
|
|
66
|
+
|
|
67
|
+
2. Grant of Copyright License. Subject to the terms and conditions of
|
|
68
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
69
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
70
|
+
copyright license to reproduce, prepare Derivative Works of,
|
|
71
|
+
publicly display, publicly perform, sublicense, and distribute the
|
|
72
|
+
Work and such Derivative Works in Source or Object form.
|
|
73
|
+
|
|
74
|
+
3. Grant of Patent License. Subject to the terms and conditions of
|
|
75
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
76
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
77
|
+
(except as stated in this section) patent license to make, have made,
|
|
78
|
+
use, offer to sell, sell, import, and otherwise transfer the Work,
|
|
79
|
+
where such license applies only to those patent claims licensable
|
|
80
|
+
by such Contributor that are necessarily infringed by their
|
|
81
|
+
Contribution(s) alone or by combination of their Contribution(s)
|
|
82
|
+
with the Work to which such Contribution(s) was submitted. If You
|
|
83
|
+
institute patent litigation against any entity (including a
|
|
84
|
+
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
|
85
|
+
or a Contribution incorporated within the Work constitutes direct
|
|
86
|
+
or contributory patent infringement, then any patent licenses
|
|
87
|
+
granted to You under this License for that Work shall terminate
|
|
88
|
+
as of the date such litigation is filed.
|
|
89
|
+
|
|
90
|
+
4. Redistribution. You may reproduce and distribute copies of the
|
|
91
|
+
Work or Derivative Works thereof in any medium, with or without
|
|
92
|
+
modifications, and in Source or Object form, provided that You
|
|
93
|
+
meet the following conditions:
|
|
94
|
+
|
|
95
|
+
(a) You must give any other recipients of the Work or
|
|
96
|
+
Derivative Works a copy of this License; and
|
|
97
|
+
|
|
98
|
+
(b) You must cause any modified files to carry prominent notices
|
|
99
|
+
stating that You changed the files; and
|
|
100
|
+
|
|
101
|
+
(c) You must retain, in the Source form of any Derivative Works
|
|
102
|
+
that You distribute, all copyright, patent, trademark, and
|
|
103
|
+
attribution notices from the Source form of the Work,
|
|
104
|
+
excluding those notices that do not pertain to any part of
|
|
105
|
+
the Derivative Works; and
|
|
106
|
+
|
|
107
|
+
(d) If the Work includes a "NOTICE" text file as part of its
|
|
108
|
+
distribution, then any Derivative Works that You distribute must
|
|
109
|
+
include a readable copy of the attribution notices contained
|
|
110
|
+
within such NOTICE file, excluding those notices that do not
|
|
111
|
+
pertain to any part of the Derivative Works, in at least one
|
|
112
|
+
of the following places: within a NOTICE text file distributed
|
|
113
|
+
as part of the Derivative Works; within the Source form or
|
|
114
|
+
documentation, if provided along with the Derivative Works; or,
|
|
115
|
+
within a display generated by the Derivative Works, if and
|
|
116
|
+
wherever such third-party notices normally appear. The contents
|
|
117
|
+
of the NOTICE file are for informational purposes only and
|
|
118
|
+
do not modify the License. You may add Your own attribution
|
|
119
|
+
notices within Derivative Works that You distribute, alongside
|
|
120
|
+
or as an addendum to the NOTICE text from the Work, provided
|
|
121
|
+
that such additional attribution notices cannot be construed
|
|
122
|
+
as modifying the License.
|
|
123
|
+
|
|
124
|
+
You may add Your own copyright statement to Your modifications and
|
|
125
|
+
may provide additional or different license terms and conditions
|
|
126
|
+
for use, reproduction, or distribution of Your modifications, or
|
|
127
|
+
for any such Derivative Works as a whole, provided Your use,
|
|
128
|
+
reproduction, and distribution of the Work otherwise complies with
|
|
129
|
+
the conditions stated in this License.
|
|
130
|
+
|
|
131
|
+
5. Submission of Contributions. Unless You explicitly state otherwise,
|
|
132
|
+
any Contribution intentionally submitted for inclusion in the Work
|
|
133
|
+
by You to the Licensor shall be under the terms and conditions of
|
|
134
|
+
this License, without any additional terms or conditions.
|
|
135
|
+
Notwithstanding the above, nothing herein shall supersede or modify
|
|
136
|
+
the terms of any separate license agreement you may have executed
|
|
137
|
+
with Licensor regarding such Contributions.
|
|
138
|
+
|
|
139
|
+
6. Trademarks. This License does not grant permission to use the trade
|
|
140
|
+
names, trademarks, service marks, or product names of the Licensor,
|
|
141
|
+
except as required for reasonable and customary use in describing the
|
|
142
|
+
origin of the Work and reproducing the content of the NOTICE file.
|
|
143
|
+
|
|
144
|
+
7. Disclaimer of Warranty. Unless required by applicable law or
|
|
145
|
+
agreed to in writing, Licensor provides the Work (and each
|
|
146
|
+
Contributor provides its Contributions) on an "AS IS" BASIS,
|
|
147
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
148
|
+
implied, including, without limitation, any warranties or conditions
|
|
149
|
+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
|
150
|
+
PARTICULAR PURPOSE. You are solely responsible for determining the
|
|
151
|
+
appropriateness of using or redistributing the Work and assume any
|
|
152
|
+
risks associated with Your exercise of permissions under this License.
|
|
153
|
+
|
|
154
|
+
8. Limitation of Liability. In no event and under no legal theory,
|
|
155
|
+
whether in tort (including negligence), contract, or otherwise,
|
|
156
|
+
unless required by applicable law (such as deliberate and grossly
|
|
157
|
+
negligent acts) or agreed to in writing, shall any Contributor be
|
|
158
|
+
liable to You for damages, including any direct, indirect, special,
|
|
159
|
+
incidental, or consequential damages of any character arising as a
|
|
160
|
+
result of this License or out of the use or inability to use the
|
|
161
|
+
Work (including but not limited to damages for loss of goodwill,
|
|
162
|
+
work stoppage, computer failure or malfunction, or any and all
|
|
163
|
+
other commercial damages or losses), even if such Contributor
|
|
164
|
+
has been advised of the possibility of such damages.
|
|
165
|
+
|
|
166
|
+
9. Accepting Warranty or Additional Liability. While redistributing
|
|
167
|
+
the Work or Derivative Works thereof, You may choose to offer,
|
|
168
|
+
and charge a fee for, acceptance of support, warranty, indemnity,
|
|
169
|
+
or other liability obligations and/or rights consistent with this
|
|
170
|
+
License. However, in accepting such obligations, You may act only
|
|
171
|
+
on Your own behalf and on Your sole responsibility, not on behalf
|
|
172
|
+
of any other Contributor, and only if You agree to indemnify,
|
|
173
|
+
defend, and hold each Contributor harmless for any liability
|
|
174
|
+
incurred by, or claims asserted against, such Contributor by reason
|
|
175
|
+
of your accepting any such warranty or additional liability.
|
|
176
|
+
|
|
177
|
+
END OF TERMS AND CONDITIONS
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: frontend-design
|
|
3
|
+
description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.
|
|
4
|
+
license: Complete terms in LICENSE.txt
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.
|
|
8
|
+
|
|
9
|
+
The user provides frontend requirements: a component, page, application, or interface to build. They may include context about the purpose, audience, or technical constraints.
|
|
10
|
+
|
|
11
|
+
## Design Thinking
|
|
12
|
+
|
|
13
|
+
Before coding, understand the context and commit to a BOLD aesthetic direction:
|
|
14
|
+
- **Purpose**: What problem does this interface solve? Who uses it?
|
|
15
|
+
- **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. There are so many flavors to choose from. Use these for inspiration but design one that is true to the aesthetic direction.
|
|
16
|
+
- **Constraints**: Technical requirements (framework, performance, accessibility).
|
|
17
|
+
- **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember?
|
|
18
|
+
|
|
19
|
+
**CRITICAL**: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work - the key is intentionality, not intensity.
|
|
20
|
+
|
|
21
|
+
Then implement working code (HTML/CSS/JS, React, Vue, etc.) that is:
|
|
22
|
+
- Production-grade and functional
|
|
23
|
+
- Visually striking and memorable
|
|
24
|
+
- Cohesive with a clear aesthetic point-of-view
|
|
25
|
+
- Meticulously refined in every detail
|
|
26
|
+
|
|
27
|
+
## Frontend Aesthetics Guidelines
|
|
28
|
+
|
|
29
|
+
Focus on:
|
|
30
|
+
- **Typography**: Choose fonts that are beautiful, unique, and interesting. Avoid generic fonts like Arial and Inter; opt instead for distinctive choices that elevate the frontend's aesthetics; unexpected, characterful font choices. Pair a distinctive display font with a refined body font.
|
|
31
|
+
- **Color & Theme**: Commit to a cohesive aesthetic. Use CSS variables for consistency. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.
|
|
32
|
+
- **Motion**: Use animations for effects and micro-interactions. Prioritize CSS-only solutions for HTML. Use Motion library for React when available. Focus on high-impact moments: one well-orchestrated page load with staggered reveals (animation-delay) creates more delight than scattered micro-interactions. Use scroll-triggering and hover states that surprise.
|
|
33
|
+
- **Spatial Composition**: Unexpected layouts. Asymmetry. Overlap. Diagonal flow. Grid-breaking elements. Generous negative space OR controlled density.
|
|
34
|
+
- **Backgrounds & Visual Details**: Create atmosphere and depth rather than defaulting to solid colors. Add contextual effects and textures that match the overall aesthetic. Apply creative forms like gradient meshes, noise textures, geometric patterns, layered transparencies, dramatic shadows, decorative borders, custom cursors, and grain overlays.
|
|
35
|
+
|
|
36
|
+
NEVER use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character.
|
|
37
|
+
|
|
38
|
+
Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices (Space Grotesk, for example) across generations.
|
|
39
|
+
|
|
40
|
+
**IMPORTANT**: Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details. Elegance comes from executing the vision well.
|
|
41
|
+
|
|
42
|
+
Remember: Claude is capable of extraordinary creative work. Don't hold back, show what can truly be created when thinking outside the box and committing fully to a distinctive vision.
|
|
@@ -0,0 +1,328 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: moai-framework-electron
|
|
3
|
+
description: >
|
|
4
|
+
Electron 33+ desktop app development specialist covering Main/Renderer
|
|
5
|
+
process architecture, IPC communication, auto-update, and packaging with
|
|
6
|
+
Electron Forge. Use when building cross-platform desktop applications.
|
|
7
|
+
license: Apache-2.0
|
|
8
|
+
compatibility: Designed for Claude Code
|
|
9
|
+
allowed-tools: Read, Grep, Glob, mcp__context7__resolve-library-id, mcp__context7__get-library-docs
|
|
10
|
+
user-invocable: false
|
|
11
|
+
metadata:
|
|
12
|
+
version: "2.0.0"
|
|
13
|
+
category: "framework"
|
|
14
|
+
status: "active"
|
|
15
|
+
updated: "2026-01-10"
|
|
16
|
+
modularized: "false"
|
|
17
|
+
tags: "electron, desktop, cross-platform, nodejs, chromium, ipc, auto-update, electron-builder, electron-forge"
|
|
18
|
+
context7-libraries: "/electron/electron, /electron/forge, /electron-userland/electron-builder"
|
|
19
|
+
related-skills: "moai-lang-typescript, moai-domain-frontend, moai-lang-javascript"
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
# Electron 33+ Desktop Development
|
|
23
|
+
|
|
24
|
+
## Quick Reference
|
|
25
|
+
|
|
26
|
+
Electron 33+ Desktop App Development Specialist enables building cross-platform desktop applications with web technologies.
|
|
27
|
+
|
|
28
|
+
Auto-Triggers: Electron projects detected via electron.vite.config.ts or electron-builder.yml files, desktop app development requests, IPC communication pattern implementation
|
|
29
|
+
|
|
30
|
+
### Core Capabilities
|
|
31
|
+
|
|
32
|
+
Electron 33 Platform:
|
|
33
|
+
|
|
34
|
+
- Chromium 130 rendering engine for modern web features
|
|
35
|
+
- Node.js 20.18 runtime for native system access
|
|
36
|
+
- Native ESM support in main process
|
|
37
|
+
- WebGPU API support for GPU-accelerated graphics
|
|
38
|
+
|
|
39
|
+
Process Architecture:
|
|
40
|
+
|
|
41
|
+
- Main process runs as single instance per application with full Node.js access
|
|
42
|
+
- Renderer processes display web content in sandboxed environments
|
|
43
|
+
- Preload scripts bridge main and renderer with controlled API exposure
|
|
44
|
+
- Utility processes handle background tasks without blocking UI
|
|
45
|
+
|
|
46
|
+
IPC Communication:
|
|
47
|
+
|
|
48
|
+
- Type-safe invoke/handle patterns for request-response communication
|
|
49
|
+
- contextBridge API for secure renderer access to main process functionality
|
|
50
|
+
- Event-based messaging for push notifications from main to renderer
|
|
51
|
+
|
|
52
|
+
Auto-Update Support:
|
|
53
|
+
|
|
54
|
+
- electron-updater integration with GitHub and S3 publishing
|
|
55
|
+
- Differential updates for smaller download sizes
|
|
56
|
+
- Update notification and installation management
|
|
57
|
+
|
|
58
|
+
Packaging Options:
|
|
59
|
+
|
|
60
|
+
- Electron Forge for integrated build tooling and plugin ecosystem
|
|
61
|
+
- electron-builder for flexible multi-platform distribution
|
|
62
|
+
|
|
63
|
+
Security Features:
|
|
64
|
+
|
|
65
|
+
- contextIsolation for preventing prototype pollution
|
|
66
|
+
- Sandbox enforcement for renderer process isolation
|
|
67
|
+
- Content Security Policy configuration
|
|
68
|
+
- Input validation patterns for IPC handlers
|
|
69
|
+
|
|
70
|
+
### Project Initialization
|
|
71
|
+
|
|
72
|
+
Creating a new Electron application requires running the create-electron-app command with the vite-typescript template. Install electron-builder as a development dependency for packaging. Add electron-updater as a runtime dependency for auto-update functionality.
|
|
73
|
+
|
|
74
|
+
For detailed commands and configuration, see reference.md Quick Commands section.
|
|
75
|
+
|
|
76
|
+
---
|
|
77
|
+
|
|
78
|
+
## Implementation Guide
|
|
79
|
+
|
|
80
|
+
### Project Structure
|
|
81
|
+
|
|
82
|
+
Recommended Directory Layout:
|
|
83
|
+
|
|
84
|
+
The source directory should contain four main subdirectories:
|
|
85
|
+
|
|
86
|
+
Main Directory: Contains the main process entry point, IPC handler definitions organized by domain, business logic services, and window management modules
|
|
87
|
+
|
|
88
|
+
Preload Directory: Contains the preload script entry point and exposed API definitions that bridge main and renderer
|
|
89
|
+
|
|
90
|
+
Renderer Directory: Contains the web application built with React, Vue, or Svelte, including the HTML entry point and Vite configuration
|
|
91
|
+
|
|
92
|
+
Shared Directory: Contains TypeScript types and constants shared between main and renderer processes
|
|
93
|
+
|
|
94
|
+
The project root should include the electron.vite.config.ts for build configuration, electron-builder.yml for packaging options, and resources directory for app icons and assets.
|
|
95
|
+
|
|
96
|
+
### Main Process Setup
|
|
97
|
+
|
|
98
|
+
Application Lifecycle Management:
|
|
99
|
+
|
|
100
|
+
The main process initialization follows a specific sequence. First, enable sandbox globally using app.enableSandbox() to ensure all renderer processes run in isolated environments. Then request single instance lock to prevent multiple app instances from running simultaneously.
|
|
101
|
+
|
|
102
|
+
Window creation should occur after the app ready event fires. Configure BrowserWindow with security-focused webPreferences including contextIsolation enabled, nodeIntegration disabled, sandbox enabled, and webSecurity enabled. Set the preload script path to expose safe APIs to the renderer.
|
|
103
|
+
|
|
104
|
+
Handle platform-specific behaviors: on macOS, re-create windows when the dock icon is clicked if no windows exist. On other platforms, quit the application when all windows close.
|
|
105
|
+
|
|
106
|
+
For implementation examples, see examples.md Main Process Entry Point section.
|
|
107
|
+
|
|
108
|
+
### Type-Safe IPC Communication
|
|
109
|
+
|
|
110
|
+
IPC Type Definition Pattern:
|
|
111
|
+
|
|
112
|
+
Define an interface that maps channel names to their payload types. Group channels by domain such as file operations, window operations, and storage operations. This enables type checking for both main process handlers and renderer invocations.
|
|
113
|
+
|
|
114
|
+
Main Process Handler Registration:
|
|
115
|
+
|
|
116
|
+
Register IPC handlers in a dedicated module that imports from the shared types. Each handler should validate input using a schema validation library such as Zod before processing. Use ipcMain.handle for request-response patterns and return structured results.
|
|
117
|
+
|
|
118
|
+
Preload Script Implementation:
|
|
119
|
+
|
|
120
|
+
Create an API object that wraps ipcRenderer.invoke calls for each channel. Use contextBridge.exposeInMainWorld to make this API available in the renderer as window.electronAPI. Include cleanup functions for event listeners to prevent memory leaks.
|
|
121
|
+
|
|
122
|
+
For complete IPC implementation patterns, see examples.md Type-Safe IPC Implementation section.
|
|
123
|
+
|
|
124
|
+
### Security Best Practices
|
|
125
|
+
|
|
126
|
+
Mandatory Security Settings:
|
|
127
|
+
|
|
128
|
+
Every BrowserWindow must have webPreferences configured with four critical settings. contextIsolation must always be enabled to prevent renderer code from accessing Electron internals. nodeIntegration must always be disabled in renderer processes. sandbox must always be enabled for process-level isolation. webSecurity must never be disabled to maintain same-origin policy enforcement.
|
|
129
|
+
|
|
130
|
+
Content Security Policy:
|
|
131
|
+
|
|
132
|
+
Configure session-level CSP headers using webRequest.onHeadersReceived. Restrict default-src to self, script-src to self without unsafe-inline, and connect-src to allowed API domains. This prevents XSS attacks and unauthorized resource loading.
|
|
133
|
+
|
|
134
|
+
Input Validation:
|
|
135
|
+
|
|
136
|
+
Every IPC handler must validate inputs before processing. Prevent path traversal attacks by rejecting paths containing parent directory references. Validate file names against reserved characters. Use allowlists for permitted directories when implementing file access.
|
|
137
|
+
|
|
138
|
+
For security implementation details, see reference.md Security Best Practices section.
|
|
139
|
+
|
|
140
|
+
### Auto-Update Implementation
|
|
141
|
+
|
|
142
|
+
Update Service Architecture:
|
|
143
|
+
|
|
144
|
+
Create an UpdateService class that manages the electron-updater lifecycle. Initialize with the main window reference to enable UI notifications. Configure autoDownload as false to give users control over bandwidth usage.
|
|
145
|
+
|
|
146
|
+
Event Handling:
|
|
147
|
+
|
|
148
|
+
Handle update-available events by notifying the renderer and prompting the user for download confirmation. Track download-progress events to display progress indicators. Handle update-downloaded events by prompting for restart.
|
|
149
|
+
|
|
150
|
+
User Notification Pattern:
|
|
151
|
+
|
|
152
|
+
Use system dialogs to prompt users when updates are available and when downloads complete. Send events to the renderer for in-app notification display. Support both immediate and deferred installation.
|
|
153
|
+
|
|
154
|
+
For complete update service implementation, see examples.md Auto-Update Integration section.
|
|
155
|
+
|
|
156
|
+
### App Packaging
|
|
157
|
+
|
|
158
|
+
Electron Builder Configuration:
|
|
159
|
+
|
|
160
|
+
Configure the appId with reverse-domain notation for platform registration. Specify productName for display in system UI. Set up platform-specific targets for macOS, Windows, and Linux.
|
|
161
|
+
|
|
162
|
+
macOS Configuration:
|
|
163
|
+
|
|
164
|
+
Set category for App Store classification. Enable hardenedRuntime and configure entitlements for notarization. Configure universal builds targeting both x64 and arm64 architectures.
|
|
165
|
+
|
|
166
|
+
Windows Configuration:
|
|
167
|
+
|
|
168
|
+
Specify icon path for executable and installer. Configure NSIS installer options including installation directory selection. Set up code signing with appropriate hash algorithms.
|
|
169
|
+
|
|
170
|
+
Linux Configuration:
|
|
171
|
+
|
|
172
|
+
Configure category for desktop environment integration. Set up multiple targets including AppImage for universal distribution and deb/rpm for package manager installation.
|
|
173
|
+
|
|
174
|
+
For complete configuration examples, see reference.md Configuration section.
|
|
175
|
+
|
|
176
|
+
---
|
|
177
|
+
|
|
178
|
+
## Advanced Patterns
|
|
179
|
+
|
|
180
|
+
For comprehensive documentation on advanced topics, see reference.md and examples.md:
|
|
181
|
+
|
|
182
|
+
Window State Persistence:
|
|
183
|
+
|
|
184
|
+
- Saving and restoring window position and size across sessions
|
|
185
|
+
- Handling multiple displays and display changes
|
|
186
|
+
- Managing maximized and fullscreen states
|
|
187
|
+
|
|
188
|
+
Multi-Window Management:
|
|
189
|
+
|
|
190
|
+
- Creating secondary windows with proper parent-child relationships
|
|
191
|
+
- Sharing state between multiple windows
|
|
192
|
+
- Coordinating window lifecycle events
|
|
193
|
+
|
|
194
|
+
System Tray and Native Menus:
|
|
195
|
+
|
|
196
|
+
- Creating and updating system tray icons with context menus
|
|
197
|
+
- Building application menus with keyboard shortcuts
|
|
198
|
+
- Platform-specific menu patterns for macOS and Windows
|
|
199
|
+
|
|
200
|
+
Utility Processes:
|
|
201
|
+
|
|
202
|
+
- Spawning utility processes for CPU-intensive background tasks
|
|
203
|
+
- Communicating with utility processes via MessageChannel
|
|
204
|
+
- Managing utility process lifecycle and error handling
|
|
205
|
+
|
|
206
|
+
Native Module Integration:
|
|
207
|
+
|
|
208
|
+
- Rebuilding native modules for Electron Node.js version
|
|
209
|
+
- Using better-sqlite3 for local database storage
|
|
210
|
+
- Integrating keytar for secure credential storage
|
|
211
|
+
|
|
212
|
+
Protocol Handlers and Deep Linking:
|
|
213
|
+
|
|
214
|
+
- Registering custom URL protocols for app launching
|
|
215
|
+
- Handling deep links on different platforms
|
|
216
|
+
- OAuth callback handling via custom protocols
|
|
217
|
+
|
|
218
|
+
Performance Optimization:
|
|
219
|
+
|
|
220
|
+
- Lazy loading windows and heavy modules
|
|
221
|
+
- Optimizing startup time with deferred initialization
|
|
222
|
+
- Memory management for long-running applications
|
|
223
|
+
|
|
224
|
+
---
|
|
225
|
+
|
|
226
|
+
## Works Well With
|
|
227
|
+
|
|
228
|
+
- moai-lang-typescript - TypeScript patterns for type-safe Electron development
|
|
229
|
+
- moai-domain-frontend - React, Vue, or Svelte renderer development
|
|
230
|
+
- moai-lang-javascript - Node.js patterns for main process
|
|
231
|
+
- moai-domain-backend - Backend API integration
|
|
232
|
+
- moai-workflow-testing - Testing strategies for desktop apps
|
|
233
|
+
|
|
234
|
+
---
|
|
235
|
+
|
|
236
|
+
## Troubleshooting
|
|
237
|
+
|
|
238
|
+
Common Issues and Solutions:
|
|
239
|
+
|
|
240
|
+
White Screen on Launch:
|
|
241
|
+
|
|
242
|
+
Verify the preload script path is correctly configured relative to the built output directory. Check that loadFile or loadURL paths point to existing files. Enable devTools to inspect console errors. Review CSP settings that may block script execution.
|
|
243
|
+
|
|
244
|
+
IPC Not Working:
|
|
245
|
+
|
|
246
|
+
Confirm channel names match exactly between main handlers and renderer invocations. Ensure handlers are registered before windows load content. Verify contextBridge usage follows the correct pattern with exposeInMainWorld.
|
|
247
|
+
|
|
248
|
+
Native Modules Fail:
|
|
249
|
+
|
|
250
|
+
Run electron-rebuild after npm install to recompile native modules. Match the Node.js version embedded in Electron. Add a postinstall script to automate rebuilding.
|
|
251
|
+
|
|
252
|
+
Auto-Update Not Working:
|
|
253
|
+
|
|
254
|
+
Verify the application is code-signed as updates require signing. Check publish configuration in electron-builder.yml. Enable electron-updater logging to diagnose connection issues. Review firewall settings that may block update checks.
|
|
255
|
+
|
|
256
|
+
Debug Commands:
|
|
257
|
+
|
|
258
|
+
Rebuild native modules with npx electron-rebuild. Check Electron version with npx electron --version. Enable verbose update logging with DEBUG=electron-updater environment variable.
|
|
259
|
+
|
|
260
|
+
---
|
|
261
|
+
|
|
262
|
+
## Resources
|
|
263
|
+
|
|
264
|
+
For complete code examples and configuration templates, see:
|
|
265
|
+
|
|
266
|
+
- reference.md - Detailed API documentation, version matrix, Context7 library mappings
|
|
267
|
+
- examples.md - Production-ready code examples for all patterns
|
|
268
|
+
|
|
269
|
+
For latest documentation, use Context7 to query:
|
|
270
|
+
|
|
271
|
+
- /electron/electron for core Electron APIs
|
|
272
|
+
- /electron/forge for Electron Forge tooling
|
|
273
|
+
- /electron-userland/electron-builder for packaging configuration
|
|
274
|
+
|
|
275
|
+
---
|
|
276
|
+
|
|
277
|
+
Version: 2.0.0
|
|
278
|
+
Last Updated: 2026-01-10
|
|
279
|
+
Changes: Restructured to comply with CLAUDE.md Documentation Standards - removed all code examples, converted to narrative text format
|
|
280
|
+
|
|
281
|
+
<!-- moai:evolvable-start id="rationalizations" -->
|
|
282
|
+
## Common Rationalizations
|
|
283
|
+
|
|
284
|
+
| Rationalization | Reality |
|
|
285
|
+
|---|---|
|
|
286
|
+
| "I can use Node.js APIs directly in the renderer process" | Renderer process runs untrusted content. Direct Node.js access is a remote code execution vector. Use IPC through the preload bridge. |
|
|
287
|
+
| "contextIsolation is unnecessary since I trust my own code" | Context isolation prevents prototype pollution from web content reaching Node.js. It is not about trusting your code, it is about isolating contexts. |
|
|
288
|
+
| "Auto-update can be configured after release" | Shipping without auto-update means users stay on vulnerable versions. Configure it before the first release. |
|
|
289
|
+
| "I will package the app later, development builds are enough for testing" | Development builds have different file paths, permissions, and code signing. Only production-packaged builds reveal real distribution issues. |
|
|
290
|
+
| "IPC is slow, I will share state through global variables" | IPC overhead is microseconds. Global variables bypass process isolation, which exists for security. |
|
|
291
|
+
|
|
292
|
+
<!-- moai:evolvable-end -->
|
|
293
|
+
|
|
294
|
+
<!-- moai:evolvable-start id="red-flags" -->
|
|
295
|
+
## Red Flags
|
|
296
|
+
|
|
297
|
+
- nodeIntegration set to true in BrowserWindow options
|
|
298
|
+
- contextIsolation set to false without documented security justification
|
|
299
|
+
- Renderer process imports directly from electron or node modules (bypass preload)
|
|
300
|
+
- No auto-update mechanism configured
|
|
301
|
+
- IPC handler does not validate or sanitize arguments from renderer
|
|
302
|
+
|
|
303
|
+
<!-- moai:evolvable-end -->
|
|
304
|
+
|
|
305
|
+
<!-- moai:evolvable-start id="verification" -->
|
|
306
|
+
## Verification
|
|
307
|
+
|
|
308
|
+
- [ ] nodeIntegration is false and contextIsolation is true in all BrowserWindows
|
|
309
|
+
- [ ] All renderer-to-main communication uses contextBridge and IPC
|
|
310
|
+
- [ ] IPC handlers validate input arguments before processing
|
|
311
|
+
- [ ] Auto-update configured and tested (show update configuration)
|
|
312
|
+
- [ ] Application packages successfully with Electron Forge (show build output)
|
|
313
|
+
- [ ] No direct require('electron') in renderer process code
|
|
314
|
+
|
|
315
|
+
<!-- moai:evolvable-end -->
|
|
316
|
+
|
|
317
|
+
## Telemetry Window
|
|
318
|
+
|
|
319
|
+
**Status**: UNCLEAR (60-day window)
|
|
320
|
+
**R4 audit verdict**: KEEP (monitor)
|
|
321
|
+
**SPEC**: SPEC-V3R2-WF-001 §6.2 (REQ-WF001-013)
|
|
322
|
+
**Window start**: 2026-04-25 (Wave 1.5 commit date)
|
|
323
|
+
**Window end**: 2026-06-24 (60 days)
|
|
324
|
+
**Re-audit trigger**: SessionStart hook activation count for this skill
|
|
325
|
+
**Decision criteria**:
|
|
326
|
+
- If activation count >= 5 during window → retain permanently
|
|
327
|
+
- If activation count = 0 during window → schedule RETIRE in v3.1
|
|
328
|
+
- If 0 < count < 5 → retain with "low-use" tag
|