Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Reusable pattern for focus-based auto-dimming of Electron overlay windows — when the app loses focus, all overlay windows fade to a low opacity; when an overlay regains focus, they return to their configured opacity. Use when building always-on-top Electron overlays that should recede while the user works in other apps.
.claude/skills/sonichi-electron-overlay-dimming/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-03 | ✗→✓ | ▲ Improved | -20% | 0% |
| case-08 | ✗→✓ | ▲ Improved | -48% | 0% |
| case-09 | ✗→✓ | ▲ Improved | -54% | 0% |
| case-11 | ✗→✓ | ▲ Improved | -30% | 0% |
| case-13 | ✗→✓ | ▲ Improved | -37% | 0% |
A small, self-contained pattern for always-on-top Electron overlays: the overlays stay readable while in use but fade out of the way when the user clicks into another application, and restore when focus returns to an overlay. First shipped in the benchmark-overlay app.
opacity drops to a dim level (~0.2).
opacity (not blindly to 1.0 — it respects any per-overlay opacity the user set).
Two pitfalls the pattern handles:
blur then a focus. Dimming on raw blur would flicker. The fix: on blur, defer ~80 ms and only dim if BrowserWindow.getFocusedWindow() is then null — i.e. the app truly lost focus, not just one window.
Auto-dim must dim from and restore to that value, so opacity is always computed as appDimmed ? DIM_OPACITY : overlay.config.opacity.
jsconst DIM_OPACITY = 0.2; let appDimmed = false; function effectiveOpacity(o) { return appDimmed ? DIM_OPACITY : o.config.opacity; } function applyOpacityAll() { for (const o of Object.values(OVERLAYS)) { if (o.win && !o.win.isDestroyed()) o.win.setOpacity(effectiveOpacity(o)); } } app.on('browser-window-focus', () => { if (appDimmed) { appDimmed = false; applyOpacityAll(); } }); app.on('browser-window-blur', () => { // Defer so an A→B overlay click doesn't briefly dim. setTimeout(() => { if (!appDimmed && !BrowserWindow.getFocusedWindow()) { appDimmed = true; applyOpacityAll(); } }, 80); });
Any code path that sets a window's opacity (e.g. a config handler) must route through effectiveOpacity() so opacity changes made while dimmed don't undim the window.
Live implementation: ~/projects/benchmark-overlay/main.js — the benchmark-overlay app applies this across three overlay windows (AI Benchmarks, System Resources, Hub Overlay).
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | pass→pass | 20,267 | 34,243 | +69% | 1 | 1 | 0% | 3,466 | 3,137 | -9% | 0 | 0 | — |
case-02 | pass→pass | 14,301 | 7,125 | -50% | 1 | 1 | 0% | 2,387 | 1,806 | -24% | 0 | 0 | — |
case-03 | fail→pass | 17,186 | 9,270 | -46% | 1 | 1 | 0% | 2,824 | 2,254 | -20% | 0 | 0 | — |
case-04 | pass→pass | 16,342 | 26,802 | +64% | 1 | 1 | 0% | 2,686 | 1,850 | -31% | 0 | 0 | — |
case-05 | pass→pass | 15,011 | 11,919 | -21% | 1 | 1 | 0% | 2,577 | 2,836 | +10% | 0 | 0 | — |
case-06 | pass→pass | 15,351 | 5,182 | -66% | 1 | 1 | 0% | 2,687 | 1,562 | -42% | 0 | 0 | — |
case-07 | pass→pass | 10,192 | 5,319 | -48% | 1 | 1 | 0% | 1,868 | 1,580 | -15% | 0 | 0 | — |
case-08 | fail→pass | 12,545 | 2,341 | -81% | 1 | 1 | 0% | 1,902 | 981 | -48% | 0 | 0 | — |
case-09 | fail→pass | 13,495 | 2,347 | -83% | 1 | 1 | 0% | 2,094 | 954 | -54% | 0 | 0 | — |
case-10 | pass→pass | 13,663 | 3,490 | -74% | 1 | 1 | 0% | 914 | 1,201 | +31% | 0 | 0 | — |
case-11 | fail→pass | 15,709 | 5,436 | -65% | 1 | 1 | 0% | 2,263 | 1,575 | -30% | 0 | 0 | — |
case-12 | pass→pass | 13,155 | 7,806 | -41% | 1 | 1 | 0% | 2,043 | 1,792 | -12% | 0 | 0 | — |
case-13 | fail→pass | 11,841 | 3,388 | -71% | 1 | 1 | 0% | 1,976 | 1,243 | -37% | 0 | 0 | — |
case-14 | pass→pass | 4,843 | 2,369 | -51% | 1 | 1 | 0% | 658 | 956 | +45% | 0 | 0 | — |
case-15 | pass→pass | 14,930 | 5,586 | -63% | 1 | 1 | 0% | 2,434 | 1,493 | -39% | 0 | 0 | — |
case-16 | fail→pass | 14,006 | 13,665 | -2% | 1 | 1 | 0% | 2,174 | 2,684 | +23% | 0 | 0 | — |
case-17 | fail→pass | 10,712 | 2,600 | -76% | 1 | 1 | 0% | 1,539 | 1,067 | -31% | 0 | 0 | — |
case-18 | pass→fail | 7,749 | 1,955 | -75% | 1 | 1 | 0% | 1,247 | 918 | -26% | 0 | 0 | — |
case-19 | pass→pass | 18,207 | 10,852 | -40% | 1 | 1 | 0% | 3,137 | 2,335 | -26% | 0 | 0 | — |
case-20 | pass→pass | 15,026 | 13,928 | -7% | 1 | 1 | 0% | 2,501 | 2,940 | +18% | 0 | 0 | — |
case-21 | pass→pass | 14,975 | 10,619 | -29% | 1 | 1 | 0% | 2,757 | 2,372 | -14% | 0 | 0 | — |
case-22 | pass→pass | 12,458 | 7,553 | -39% | 1 | 1 | 0% | 2,072 | 1,880 | -9% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted. The headline lift of +27 percentage points is the difference between those two pass rates over the 22 comparable cases. 1 case got worse with the skill loaded, and it is included in that figure.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.