# App Release Readiness

> Use when preparing a desktop or web app update for commit, packaging, installer validation, GitHub publication, release asset upload, or old-release pruning. Protects user data and verifies that published artifacts match the tested build.

- Skill: `sidiangongyuan/app-release-readiness` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add sidiangongyuan/app-release-readiness`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sidiangongyuan/app-release-readiness/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: sidiangongyuan (https://skillmd.com/u/sidiangongyuan)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sidiangongyuan/app-release-readiness

---


# App Release Readiness

Use this skill when a user asks to submit, push, package, upload an installer,
or confirm that the latest app update is actually available.

## Workflow

1. Preflight the repository.
   - Run `git status --short` and identify unrelated changes.
   - Confirm branch, remote, version/tag policy, and whether this is a source
     commit, installer upload, or both.
   - Do not commit build artifacts unless the repo explicitly tracks them.
   - If the user asks to limit old GitHub Releases for a maintained desktop
     app and gives no other number, keep the newest 15 release records and do
     not delete git tags.

2. Verify before packaging.
   - Run the smallest meaningful backend/frontend tests for the change.
   - Run full build checks when UI, packaging, provider, or app lifecycle code
     changed.
   - For desktop apps, include Rust/Tauri or native shell checks when present.
   - Scan for key-shaped secrets and private data when provider credentials,
     release notes, screenshots, or docs changed.

3. Package with process safety.
   - Close or handle app/sidecar processes before overwriting binaries.
   - Prefer installers that fail on locked files over half-updated installs.
   - Ensure uninstall/update behavior does not delete user data by default.

4. Inspect build outputs.
   - Record installer paths, sizes, and SHA256 hashes.
   - Compare expected sidecar/app binaries when stale-process or half-update
     bugs were part of the release.
   - Smoke-test the installed app when feasible.

5. Commit and push deliberately.
   - Stage only intended source/docs changes.
   - Use a direct commit message that names the user-visible change.
   - Push the branch and verify the remote commit SHA before publishing source
     claims or release notes that point at the new version.

6. Upload release assets when requested.
   - Use the repository's current release/tag policy.
   - Upload with replace/clobber only when the user asked for the latest asset
     to replace the old one.
   - Verify remote asset names and sizes after upload.
   - Download uploaded assets back from the release URL and verify SHA256
     against the local artifacts before saying the release is current.

7. Prune releases only when requested.
   - Delete release records, not tags, unless the user explicitly asks for tag
     deletion.
   - Re-list releases after pruning and report the final count.
   - If keeping 15 records, preserve the newest 15 by published release order.

8. Report with evidence.
   - Include commit SHA, pushed branch, tests run, package paths, hashes, and
     release URL when applicable.
   - Say explicitly if installation or provider smoke tests were not run.

## Reference Use

Read `references/app-quality-principles.md` before releasing changes that touch
data paths, provider integrations, startup behavior, user-facing errors, or
installer behavior.

Read `references/living-to-tell-casebook.md` when the release includes fixes
for stale sidecars, startup black screens, raw Not Found/Failed to fetch errors,
AI provider transport, or uninstall/data-location safety.

## Release Red Lines

- Do not say "uploaded" until the release page or API confirms the asset.
- Do not say "latest" until the remote asset hash or commit matches the
  current build.
- Do not force-push, delete tags, or replace release assets unless the user
  asked for that release behavior.
- Do not package or publish secrets, local databases, private writing content,
  logs, or screenshots containing private data.