| name | app-release-readiness |
| description | 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. |
| license | MIT |
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
