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
How do you install this skill?
- 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.
- Shell / CLI
- Local filesystem
OpenChamber repository codebase (packages/electron, packages/ui, packages/web)Electron/Node.js toolchain for tests and packaging
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.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/openchamber/openchamber.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/.agents/skills/desktop-shell" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
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.
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 does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| OpenChamber Desktop Shell Skill this page | 54 · Use with care | ★ 12k | 11d ago | MIT |
| OpenChamber UI/API Decoupling Skill | 58 · Recommended | ★ 12k | 11d ago | MIT |
| Desktop App Control with Computer Use | 61 · Recommended | ★ 6.4k | 12d ago | Apache-2.0 |
| AionUi Architecture Conventions | 57 · Use with care | ★ 34k | 11d ago | Apache-2.0 |
| VS Code Integrated Browser Architecture ✓ Microsoft · Official | 56 · Use with care | ★ 194k | 11d ago | MIT |
How did FollowSkills review this skill?
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.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →