Fleet Electron Release Workflow

VerifiedCaution

Guides the Fleet Electron release process: version bump, changelog, draft GitHub release, tagging, and CI build monitoring.

Sby Skills Guide Bot
DevOpsIntermediate
10/31/2026
Claude Code
#release-management#electron#github-releases#versioning#ci-cd

Recommended for

Automated summary

Walks through shipping a new version of the Fleet Electron app: semver bump, changelog entry, draft GitHub release, tag push, and monitoring the CI workflow through automatic publication.

Strengths

  • Makes the critical draft-first rule explicit: the release must exist as a draft before the tag is pushed or electron-builder cannot upload artifacts to it.
  • Flags that the `## vX.Y.Z` CHANGELOG.md entry is mandatory because `scripts/extract-release-notes.ts` looks it up and fails every build job when it is missing.
  • Gives concrete verification commands (`gh run list`, `gh run watch`, `gh release view`) and names the six expected CI jobs.
  • Includes a recovery procedure for a tag pushed too early: delete it locally and remotely, then recreate and re-push.

Limitations

  • Heavily tied to the Fleet repository: workflow names, jobs, scripts and artifact names are hardcoded and not reusable as-is elsewhere.
  • Assumes write access to the repo and an authenticated GitHub CLI; no fallback via the web UI or other tooling is described.
  • Does not cover rolling back an already published release or hotfix branching, and the Linux artifact verification list is cut off mid-line.
When to use it

Use it when preparing and publishing a new Fleet app version, or when debugging a release workflow failure tied to the tag, changelog or draft release.

When not to use it

Avoid it for projects other than the Fleet Electron app, or for releases that do not run through GitHub Releases and electron-builder.

Security analysis

Caution
Quality score82/100

The skill is a straightforward, well-scoped release runbook with no untrusted downloads, encoded payloads, or secret exfiltration. It does direct the agent to use powerful, state-changing tooling (git push, gh release delete, gh workflow run) against a shared repository, so it warrants 'caution' rather than 'safe', but all commands are purposeful and consistent with a normal release process.

Findings
  • •No allowed-tools declared, yet the skill instructs the agent to run git, npm, and GitHub CLI commands with repo/release write access (git push, gh release create/delete, gh workflow run). The tool declaration should include Bash/git/gh to match actual needs.
  • •Troubleshooting includes irreversible remote operations: `git push origin :refs/tags/<TAG>` (remote tag deletion) and `gh release delete <TAG> --yes` (release deletion). These are legitimate release-repair steps but are destructive and depend on correct tag substitution; a wrong version string could delete the wrong remote tag/release.
  • •Workflow pushes directly to `main` without a PR or branch check, and moving/deleting tags on a shared remote can disrupt other contributors' clones — process risk rather than a security flaw.
  • •No credential/secret handling, exfiltration, obfuscation, or safety-disabling behavior present.
  • •Includes destructive/irreversible git operations on remote refs (deleting and re-pushing tags: `git tag -d`, `git push origin :refs/tags/...`) and `gh release delete --yes`, which can remove published artifacts or rewrite tag history if run against the wrong version
  • •Commands assume GitHub CLI (`gh`) is authenticated with release/publish permissions on the repo; a mis-targeted run could affect published releases
  • •No declared allowed-tools, yet the instructions call for bash/git/npm/gh execution — the host must grant shell access for the skill to be usable
How this analysis is made

Examples

Ship a patch release
Cut a new patch release for Fleet, say 1.4.2 — bump package.json, add the changelog entry, open the draft release and push the tag.
Recover from a mis-ordered tag
I pushed the v1.4.2 tag before committing the CHANGELOG entry and the release builds failed. How do I move the tag and re-trigger the workflow?
Check release completion
The tag release for v1.5.0 is running — show me how to watch the CI jobs and confirm the draft got published with all macOS, Windows and Linux artifacts.

name: release description: This skill should be used when creating a new release for the Fleet Electron app. It covers version bumping, tagging, creating draft GitHub releases, and monitoring CI builds. Triggers on "release", "new version", "bump version", "tag release", "publish release", or any release workflow request.

Release

Overview

This skill guides the release process for the Fleet Electron app. Fleet uses electron-builder with GitHub Releases as the publish provider. The release workflow (.github/workflows/release.yml) builds for macOS (arm64 + x64), Windows, and Linux when a version tag is pushed. A final publish-release job automatically publishes the draft release after all builds succeed. CI checks live separately in .github/workflows/ci.yml.

Critical Rule

Releases MUST be created as draft. When electron-builder --publish always runs in CI, it uploads artifacts to an existing draft GitHub release matching the tag. If the release is not draft (or does not exist as draft), the build artifacts will fail to publish to it. The publish-release CI job handles publishing automatically after all builds complete.

Release Workflow

Step 1: Determine the New Version

Follow semver conventions:

  • Patch (1.2.0 → 1.2.1): Bug fixes only
  • Minor (1.2.0 → 1.3.0): New features, backward compatible
  • Major (1.2.0 → 2.0.0): Breaking changes

Step 2: Bump the Version in package.json

Update the "version" field in package.json to the new version. Do not modify package-lock.json manually — run npm install to sync it.

npm install

Step 3: Add a Changelog Entry

This step is required. The CI release workflow runs scripts/extract-release-notes.ts which looks for a ## vX.Y.Z heading in CHANGELOG.md matching the tag. If the entry is missing, all build jobs will fail.

Add the entry at the top of CHANGELOG.md:

## v<NEW_VERSION>

- Summary of changes

Step 4: Commit Version Bump and Changelog Together

git add package.json package-lock.json CHANGELOG.md
git commit -m "chore: bump version to <NEW_VERSION>"

Step 5: Push to Main

git push origin main

Step 6: Create Draft Release and Push Tag

First, create the draft release on GitHub:

gh release create v<NEW_VERSION> --draft --title "v<NEW_VERSION>" --generate-notes

Then create and push the tag locally. Draft releases do not create remote tags, so the tag must be pushed to trigger the release workflow:

git tag v<NEW_VERSION>
git push origin v<NEW_VERSION>

Important: The tag must point to a commit that already includes the CHANGELOG.md entry. If you accidentally pushed the tag before the changelog commit, move the tag:

git tag -d v<NEW_VERSION> && git push origin :refs/tags/v<NEW_VERSION>
git tag v<NEW_VERSION> && git push origin v<NEW_VERSION>

Step 7: Monitor CI

The tag push triggers the release workflow (.github/workflows/release.yml). Monitor it:

gh run list --limit 5
gh run watch

Six jobs run for a tag release:

  • verify-version (ubuntu-latest) - checks that the tag matches package.json
  • release-mac-arm64 (macos-15)
  • release-mac-x64 (macos-15)
  • release-win (windows-latest)
  • release-linux (ubuntu-latest)
  • publish-release — runs after all four build jobs succeed, automatically publishes the draft release

Each build job uses electron-builder --publish always which uploads artifacts to the draft release. Once all four succeed, publish-release flips the release from draft to published.

Step 7: Verify the Release

After CI completes (including the publish-release job), verify the release is published with all artifacts:

gh release view v<NEW_VERSION>

Expected artifacts:

  • macOS: Fleet-<VERSION>-arm64.dmg, Fleet-<VERSION>.dmg (x64), latest-mac.yml
  • Windows: Fleet-Setup-<VERSION>.exe, latest.yml
  • Linux: Fleet-<VERSION>.AppImage, Fleet-<VERSION>.deb, latest-linux.yml

The latest-*.yml files are auto-update manifests used by electron-updater.

Troubleshooting

"No changelog entry found" error in CI

The extract-release-notes.ts script requires a ## vX.Y.Z heading in CHANGELOG.md matching the tag. Add the entry, commit it to main, then move the tag to that commit:

git tag -d v<NEW_VERSION> && git push origin :refs/tags/v<NEW_VERSION>
git tag v<NEW_VERSION> && git push origin v<NEW_VERSION>

Do not use gh run rerun — the re-run checks out the tag commit, not main, so new commits won't be picked up unless the tag is moved first.

CI build job failed — release stays in draft

The publish-release job only runs when all four build jobs succeed. If any build fails, the release remains draft. Fix the issue and re-run the failed job:

gh run rerun <RUN_ID> --failed

electron-builder publish is idempotent for draft releases — it will upload/overwrite artifacts. Once the re-run succeeds, publish-release will run automatically.

Artifacts missing from release

Verify the release is still in draft state. If it was accidentally published before CI completed, delete the release (not the tag), recreate as draft, and re-run CI:

gh release delete v<NEW_VERSION> --yes
gh release create v<NEW_VERSION> --draft --title "v<NEW_VERSION>" --generate-notes --target main
gh workflow run release.yml

Version mismatch error in CI

The verify-version job checks that the tag matches package.json. Ensure the version bump commit was pushed before the tag was created.

From the file to a first result

The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.

View the source and supporting files

This download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.

1. Download the file

Download SKILL.md

From the root of a test project, save the file as .skill-downloads/fleet-electron-release-workflow-mvg6ty55/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.

Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.

mkdir -p '.skill-downloads/fleet-electron-release-workflow-mvg6ty55' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/fleet-electron-release-workflow-mvg6ty55/download' --output '.skill-downloads/fleet-electron-release-workflow-mvg6ty55/SKILL.md.part' && mv '.skill-downloads/fleet-electron-release-workflow-mvg6ty55/SKILL.md.part' '.skill-downloads/fleet-electron-release-workflow-mvg6ty55/SKILL.md'

2. Check prerequisites

Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.

No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.

The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.

3. Load the skill

After inspection, copy the complete folder into your project using one of the commands below, then open a new tool session. The command stops if a folder with the same name already exists: compare the files before replacing it.

Claude Code
test -f '.skill-downloads/fleet-electron-release-workflow-mvg6ty55/SKILL.md' && test -s '.skill-downloads/fleet-electron-release-workflow-mvg6ty55/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/release' && cp -R '.skill-downloads/fleet-electron-release-workflow-mvg6ty55' '.claude/skills/release'

OpenSkills

OpenSkills must already be installed. The local install/read procedure is checked with OpenSkills 1.5.0, which requires Node.js ≥ 20.6.0. Catalog slugs are not resolved automatically.

Official OpenSkills installation
openskills install './.skill-downloads/fleet-electron-release-workflow-mvg6ty55'

openskills read 'fleet-electron-release-workflow-mvg6ty55'

Reading should display the installed file content and its base directory. It does not run the skill or install its dependencies.

For an agent that reads AGENTS.md, then sync the index. This command changes AGENTS.md: review the diff before using it.

openskills sync

Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.

4. Try a first task

Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:

Read .skill-downloads/fleet-electron-release-workflow-mvg6ty55/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.

Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.

Related skills