SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillssgc-electron-delta-updater

sgc-electron-delta-updater

Design & creation

View repository

Updated 10-16 00:01

About this skill

Electron incremental auto-update

Deliver a verifiable incremental update pipeline for an existing Electron app; base it on the user's actual installation package, public update source, and installation results, not on CI success.

Triggers

Activate when

  • The user says "add incremental auto-update to this Electron App" or "checking for updates keeps spinning".
  • The user mentions macOS Sparkle, appcast, DMG, blockmap, signing, notarization, or delta update packages.
  • User asks to “add a delta updater”, “ship Sparkle updates”, or “verify an Electron update release”.

Do not activate when

  • The user only wants to change the version number, update log, or a regular download page; use version management or a release workflow.
  • The user wants web hot updates, PWA cache updates, or mobile OTA; use the update mechanism of the corresponding platform.

Workflow (MANDATORY)

You MUST follow these steps in order.

Step 0: Establish the update contract

  • Identify target platforms, package format, current updater library, update feed, signing owner, release channel, and rollback expectation.
  • Treat macOS delta-only behavior as an explicit product promise only when complete archives are intentionally excluded.
  • Separate four states: check, download/stage, install handoff, and post-restart verification.
  • Read references/electron-macos-delta.md for macOS Sparkle work and references/release-verification.md before modifying a release pipeline.

Step 1: Make checks bounded and recoverable

  • Use one in-flight check per update service.
  • Pass an AbortSignal through every network layer, including appcast fetches.
  • On timeout, abort the request, wait for stale updater state and connections to settle, then allow a later retry.
  • Configure the updater's own network session; do not assume it inherits a developer shell proxy.
  • Keep the UI state retryable after every timeout, download failure, or malformed feed.

Step 2: Enforce the artifact policy

  • Generate architecture-specific feed entries and match each delta to its source and target version.
  • Verify signature, length, architecture, and URL before staging an update.
  • In delta-only mode, stop on any complete-package fallback; surface a manual-install path instead of silently downloading a larger archive.
  • If a local feed proxy is required, bind it to loopback, permit only the verified delta URL, preserve HTTP range behavior, and keep the served artifact URL ending in .delta.

Step 3: Coordinate install and restart

  • Complete application cleanup before giving control to the native updater.
  • Keep the process alive until asynchronous install handoff is confirmed.
  • Use references/release-verification.md to verify the staged update and the installed version after relaunch.
  • For a normal user-invoked app restart without an update, use sgc-electron-app-relaunch instead.

Step 4: Validate the deliverable

  • Add tests for single-flight checks, timeout abort, stale-check recovery, rejected full fallback, feed proxy ranges, and asynchronous install handoff.
  • Run the project's format, lint, typecheck, test, package, signing, and notarization checks that apply.
  • Verify the public release page plus direct appcast and delta asset responses; compare the final artifact's version, digest, size, signature, and notarization state.
  • Report the updater backend, supported platforms, checked URLs, installed-version proof, and any manual-install condition.

Dependencies

  • An Electron project with a defined packaging and signing owner.
  • Sparkle tooling only for macOS Sparkle paths.

General feedback loop

When the user raises modification suggestions in a Skill-driven task, before continuing with the current artifact you must do the following:

  1. First determine whether the suggestion is task-specific(this time only) or reusable(reusable across tasks).
  2. task-specific Only modify the current task, do not change the Skill.
  3. reusable First determine the scope: for domain rules, first update the corresponding canonical Skill; for rules that apply to all Skills, first update the shared specification.
  4. After completing rule updates, versioning, lint, and distribution verification, apply the modification to the current task.
  5. reusable The modification invalidates previous "confirm", "continue", and "send it"; after completing the current artifact modification and read-back, you must stop and wait for the user's next instruction, without automatically proceeding to publishing, committing, or other external writes.