CtrlK
BlogDocsLog inGet started
Tessl Logo

desktop-shell

Use when changing Electron main/preload code, desktop IPC, native windows, menus, dialogs, notifications, updater behavior, deep links, SSH or tunnels, child processes, packaged startup, or Windows process spawning.

59

Quality

68%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/desktop-shell/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

78%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The content is a lean, well-structured, actionable rule set for Electron native behavior with explicit validation criteria; its only meaningful gap is the absence of explicit error-recovery feedback loops in its workflows.

Suggestions

Add an explicit validate->fix->retry loop in the Packaging And Lifecycle and Windows Background Processes sections so error recovery is sequenced, not just completion criteria stated.

Tighten the few rationale statements (e.g., 'windowsHide reliably controls only the directly spawned process', 'Electron is the desktop release target') that restate points already implied by the rules.

Provide one short copy-paste spawn snippet combining windowsHide + stdio: 'ignore' + unref() so the common background-helper case is fully executable at a glance.

DimensionReasoningScore

Conciseness

The body is dense and rule-driven with no concept padding (no 'what is Electron' filler) and assumes Claude's competence; a few rationale lines like 'windowsHide reliably controls only the directly spawned process' and 'Electron is the desktop release target' could be trimmed, keeping it just below the lean 5.

4 / 5

Actionability

Concrete, executable specifics are present (windowsHide: true, stdio: 'ignore', unref(), powershell.exe -NoProfile -NonInteractive -WindowStyle Hidden -EncodedCommand ..., main.mjs, bundle-main.mjs) with only minor gaps; as an instruction-only skill its guidance is actionable, but much remains principle-level rather than copy-paste steps, so it does not reach 5.

4 / 5

Workflow Clarity

The IPC section gives a clear numbered 1-5 sequence and the Validation section states explicit completion criteria ('completion requires both HMR development and bundled UI validation'; 'completion requires inspection of the complete process tree with no console flash; command success alone is insufficient'), but explicit error-recovery feedback loops (validate -> fix -> retry) are not spelled out, capping it below 5.

4 / 5

Progressive Disclosure

At ~45 lines with no bundle files needed, the body is organized into clear, well-labeled sections (Required Context, Runtime Boundary, IPC And Security, Windows Background Processes, Packaging And Lifecycle, Validation) with one-level pointers to repo files (packages/electron/README.md, bundle-main.mjs); per the under-50-lines guidance, well-organized sections alone justify a 5.

5 / 5

Total

17

/

20

Passed

Description

57%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is highly specific and trigger-rich for the Electron desktop-native domain, but it omits any statement of what the skill actually does, leaving completeness as the dominant weakness.

Suggestions

Add a leading 'what' clause before the 'Use when' triggers, e.g. 'Provides guidance for Electron main/preload, native windows, IPC, and packaging. Use when changing ...', so both what and when are explicit.

Include a few common natural synonyms users say (system tray, context menus, autoUpdater) to round out trigger coverage.

Disambiguate the boundary with the sibling ui-api-decoupling skill directly in the description to reduce overlap risk.

DimensionReasoningScore

Specificity

Lists many concrete capability areas ('Electron main/preload code, desktop IPC, native windows, menus, dialogs, notifications, updater behavior, deep links, SSH or tunnels, child processes, packaged startup, Windows process spawning') with comprehensive coverage of the desktop-native domain, though these are domains/behaviors rather than verb-actions, so it sits just below the 5 anchor.

4 / 5

Completeness

The description is entirely a 'Use when...' clause — it answers 'when' explicitly but never states what the skill does, matching the anchor 'only when is present without what'; per the guideline to score only what is explicitly stated, the missing 'what' cannot be inferred, so it cannot reach 3.

2 / 5

Trigger Term Quality

Strong, natural domain keywords a desktop developer would actually say (Electron, preload, IPC, dialogs, deep links, updater, child processes, packaged startup), but a few common variations are missing (system tray, context menus, autoUpdater) so it is not quite the comprehensive 5.

4 / 5

Distinctiveness Conflict Risk

Triggers are tightly scoped to Electron native concerns (a clear niche), but the body references a sibling skill (ui-api-decoupling) owning the shared UI/runtime contract, indicating a minor overlap risk with a closely related skill rather than the minimal-conflict 5.

4 / 5

Total

14

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
openchamber/openchamber
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.