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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: sidiangongyuan
• Source: sidiangongyuan/codex-skills-library
• License: MIT

Install and usage instructions live in the source repository linked above.