OpenChamber Desktop Shell Skill
Gives AI agents the correct architecture boundaries and security rules when changing OpenChamber's Electron main/preload code, IPC, or packaging.
The skill is security-centric: main-process gating of privileged commands, narrowest preload payloads, no filesystem/shell/credential exposure to remote pages, and windowsHide for child processes — consistent with least privilege and data-flow transparency; as internal repo guidance it has no external destructive effects. Deducted for: no user-confirmation or rollback mechanisms; trust-boundary operations (deep links, credentials, runtime switching) stated only as principles without concrete mitigation or recovery steps; unverified publisher leaves attribution incomplete.
Instructions are internally consistent, ownership conditions (main/preload/renderer) are clear, and validation steps are actionable (process-tree inspection, HMR plus bundled validation). Deducted for: no committed test evidence covering the skill's key paths, referenced files (packages/electron/README.md) absent from evidence, and error/failure feedback deferred to the wider repo — static review cannot confirm reproducibility.
Trigger conditions in the description are specific (Electron main/preload, IPC, native windows, SSH, packaging), with a clean boundary against the ui-api-decoupling skill. Deducted for: applicability limited to this repository's contributors; no Chinese-language support; no reachability disclosure for target environments; non-fit boundaries only implicit.
Well-layered structure (required context → runtime boundary → IPC security → Windows processes → packaging → validation), progressive disclosure is sensible, and the repo has MIT license, version 1.22.2, active CI and maintenance signals. Deducted for: the skill file itself has no version/changelog, heavy dependence on files not provided in evidence (packages/electron/README.md, bundle-main.mjs), and maintenance responsibility rests on an individual author.
For the contributor's core task (safely modifying the desktop shell) it provides a directly usable checklist and hard constraints; the Windows no-console-flash and minimal-IPC rules add real marginal value over unguided edits. Deducted for: output is normative guidance rather than a verifiable artifact; completion depends on the executor, and static review cannot confirm usable results.
The repo provides MIT license, security policy, CI workflows, and test scripts (electron test/type-check in package.), partially corroborating a verification culture. Deducted for: no committed test content covering this skill's key paths (Electron tests, process-tree checks) appears in evidence; claims are largely authorial norms without third-party execution evidence, so 4/5 under the static cap.
- This is a purely static source review; no tests or validation commands were executed.
- The skill heavily depends on packages/electron/README.md and bundle-main.mjs, which were not provided in the evidence; actual usability must be verified by the user.
- Trust-boundary operations (deep links, credentials, runtime switching) are stated only as principles without concrete mitigation or rollback steps; review them independently.
- Publisher identity is unverified by the curated registry; attribution is limited.
- This is internal repo development guidance and is largely inapplicable outside openchamber contributions.
What does this skill do, and when should you use it?
desktop-shell is an agent skill inside the OpenChamber repository at .agents/skills/desktop-shell/SKILL.md. It instructs agents on how to safely modify the Electron desktop code: main/preload responsibility splits, privileged IPC handling, native windows and updater behavior, and Windows hidden background-process spawning. It also defines completion criteria (dual HMR and packaged validation, process-tree inspection). It is a pure guidance skill with no executable scripts.
Requires the agent to read packages/electron/README.md and nearby code before editing and assign each changed behavior to main, preload, renderer/UI, or web/runtime ownership; enforces that Electron boots @openchamber/web in the same Node process with no sidecar server; sets IPC security rules (preload bridge shapes only on renderer-facing changes, privileged commands gated in main, narrowest payloads, never expose filesystem/shell/tokens to remote pages); mandates windowsHide: true and stdio: 'ignore' for background child processes on Windows while avoiding cmd.exe /c shims that flash consoles; and defines packaging/lifecycle preservation plus validation gates (focused Electron tests, HMR + bundled UI validation, full process-tree inspection for Windows process work).
- A developer maintaining the OpenChamber desktop app needs to modify Electron main/preload code or add a privileged IPC command
- Adding or adjusting native menus, dialogs, notifications, or updater behavior in the desktop app
- Fixing Windows background child processes that flash a console window
- Implementing or modifying trust-boundary features such as deep links, SSH host imports, or tunnel lifecycle
- Changing packaging (bundle-main.mjs, native module config) while keeping dev and packaged builds behaviorally identical
What are this skill's strengths and limitations?
- Clearly defines Electron's privilege and trust boundaries, preventing agents from leaking desktop privileges to remote pages
- Contains uncommon, practical Windows hidden-child-process best practices (windowsHide, stdio ignore, avoiding cmd.exe shims)
- Defines explicit completion criteria: dual HMR + packaged validation and process-tree checks, not just command success
- Clean ownership split with the ui-api-decoupling skill for multi-skill collaboration
- Pure rules skill with no scripts or automated checks; effectiveness depends on the model following instructions
- Tightly bound to OpenChamber-specific structure (packages/electron, bundle-main.mjs, main.mjs); adapting it to other Electron projects requires significant edits
- No accompanying test suite, so the rules themselves have no independent verification evidence
- Standalone installation and usage are not documented
How do you install this skill?
The skill ships inside the openchamber/openchamber repository at .agents/skills/desktop-shell/. To use it in another Agent Skills-compatible client, copy that folder (including SKILL.md) into the client's skills directory; no standalone install command is documented. Prerequisite: you must have the OpenChamber repository itself — the skill only makes sense against that codebase's Electron layer.
How do you use this skill?
When a task involves Electron main/preload, desktop IPC, native windows, menus, dialogs, notifications, the updater, deep links, SSH/tunnels, child processes, or packaged startup, the agent should load this skill (its description lists these triggers). Read packages/electron/README.md first; if the change adds renderer-facing capabilities or touches shared bridge contracts, also load the ui-api-decoupling skill. On completion, run focused Electron tests per the validation section; startup/routing/packaging changes require both HMR development and bundled UI validation, and Windows process work requires inspecting the full process tree with no console flash.