chatandbuild/Desktop Release
skills/desktop-release/SKILL.md
Use this skill when planning or executing desktop application releases, including repeatable builds, signing, packaging, release candidates, rollout checks, and cross-platform production readiness.
$ install --global
skillsauthnpx skillsauth add chatandbuild/chatchat-skills Desktop ReleaseInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jun 23, 2026, 3:53 AM167.6s2 files scanned
SKILL.md
- id:
- desktop-release
- name:
- Desktop Release
- description:
- Use this skill when planning or executing desktop application releases, including repeatable builds, signing, packaging, release candidates, rollout checks, and cross-platform production readiness.
- category:
- DevOps
Desktop Release
Ship desktop versions safely with clear release gates, artifact verification, and rollback paths.
When to Use
- You are preparing a new desktop app version for users.
- You need a reliable signing/notarization/package workflow.
- You want pre-release checks for installers and auto-update channels.
Release Engineering Patterns
Reproducible builds. Build only from tagged commits (e.g. v1.2.3). Use deterministic environment variables, lockfiles, and CI to ensure identical artifacts across runs. Avoid building from arbitrary branches or uncommitted changes.
Code signing. macOS: Sign with Apple Developer ID and hardened runtime; use codesign --deep only when necessary. Windows: Use Authenticode with an EV or standard code-signing certificate; sign all executables and installers. Linux: GPG-sign packages and provide detached .asc files for distro maintainers.
Notarization (macOS). Use xcrun notarytool submit for Apple notarization. Store credentials in keychain or environment; avoid hardcoding. Wait for notary completion before stapling (xcrun stapler staple). Gatekeeper requires notarization for apps distributed outside the Mac App Store.
Build tooling. electron-builder: Configure mac.identity, win.certificateFile, linux.executableName; use afterSign hooks for notarization. electron-forge: Use @electron-forge/maker-* makers and @electron-forge/publisher-* publishers; integrate notarization via afterSign in forge.config.js.
Auto-Update Channel Management
Squirrel (macOS/Windows). Host RELEASES manifest and delta/full nupkg files. Ensure RELEASES lists correct version, filename, and SHA1. Clients parse this manifest to decide which files to fetch.
electron-updater. Configure provider (generic, GitHub, S3, etc.), channel (stable/beta/alpha), and updaterCacheDirName. Use allowDowngrade: false unless you need rollback. Set autoDownload and autoInstallOnAppQuit per product requirements.
Staged rollout. Use percentage-based rollout (e.g. 5% -> 25% -> 50% -> 100%) by serving different latest.yml or equivalent manifests to subsets of users. Implement server-side logic or CDN rules to vary response by user segment. Monitor crash rates and error telemetry before increasing percentage.
Common Pitfalls
- Expired certificates. Code signing certs expire; notarization requires valid Apple Developer credentials. Check expiry before release and renew proactively.
- Notarization timeout. Large binaries or Apple service delays can cause timeouts. Retry with
--wait; consider splitting very large apps. - Wrong auto-update manifest.
latest.ymlorRELEASESpointing to a previous version causes clients to skip updates or fetch wrong binaries. Validate manifest contents before publishing. - Missing checksums. Installers without SHA256/SHA512 or detached signatures break integrity verification. Always publish checksums and signatures alongside artifacts.
- Single-OS testing. Behavior differs across Windows/macOS/Linux. Test install, upgrade, and uninstall on each target OS; use clean VMs or CI runners per platform.
Workflow
- Freeze release scope and confirm versioning/changelog.
- Build reproducible artifacts per platform from a tagged commit.
- Perform signing/notarization for each target OS.
- Validate installers and first-run flows on clean environments.
- Test upgrade paths from at least one prior stable version.
- Publish artifacts and update metadata for auto-update channels.
- Roll out in stages and monitor crash/error telemetry.
Release Checklist
- [ ] Checksums and signatures verified for all artifacts.
- [ ] Changelog reflects user-visible changes and known issues.
- [ ] Auto-update manifest points to correct binaries.
- [ ] Rollback steps are documented and tested.
Output Format
Return:
- Release plan: Scope, version, gating criteria, and timeline.
- Artifact matrix: Table with columns: platform, architecture, file path, size, checksum (SHA256), signature status, notarization status (macOS).
- Validation results: Install/upgrade test outcomes per OS; first-run and auto-update verification; any failures or known issues.
- Remaining risks: Unresolved items, mitigations, and acceptance criteria for go/no-go.
- Rollout/rollback instructions: Staged percentage steps, manifest rollback procedure, and telemetry thresholds for abort.
Constraints
- Do not publish unsigned or unverified binaries.
- Keep release notes aligned with actual shipped commit.
- Avoid full rollout before canary/staged validation.
Related Skills
chatandbuild/yeet
tools
VerifiedTrustedCommunity
Use only when the user explicitly asks to stage, commit, push, and open a GitHub pull request in one flow using the GitHub CLI (`gh`).
1SKILL.mdUpdated Jul 22, 2026
chatandbuild/xlsx
development
VerifiedTrustedCommunity
Use this skill any time a spreadsheet file is the primary input or output. This means any task where the user wants to: open, read, edit, or fix an existing .xlsx, .xlsm, .csv, or .tsv file (e.g., adding columns, computing formulas, formatting, charting, cleaning messy data); create a new spreadsheet from scratch or from other data sources; or convert between tabular file formats. Trigger especially when the user references a spreadsheet file by name or path — even casually (like "the xlsx in my downloads") — and wants something done to it or produced from it. Also trigger for cleaning or restructuring messy tabular data files (malformed rows, misplaced headers, junk data) into proper spreadsheets. The deliverable must be a spreadsheet file. Do NOT trigger when the primary deliverable is a Word document, HTML report, standalone Python script, database pipeline, or Google Sheets API integration, even if tabular data is involved.
1SKILL.mdUpdated Jul 22, 2026
chatandbuild/Workout Logger
development
VerifiedTrustedCommunity
Use this skill when turning messy workout information into clear logs, comparing user-provided sessions, surfacing trends or likely PRs, and suggesting realistic next-session steps.
1SKILL.mdUpdated Jul 22, 2026
chatandbuild/webapp-testing
tools
VerifiedTrustedCommunity
Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
1SKILL.mdUpdated Jul 22, 2026