app-release
starsforks
How to install app-release?
luochang212/skill-zoo/app-release
$npx -y skills add luochang212/skill-zoo --skill app-releaseUse when the user asks to release a new version, ship a build, or publish a Skill Zoo release. Also use when a tag push results in Homebrew 404 errors or missing artifact failures.
SKILL.md
| 1 | # Release |
| 2 | |
| 3 | ## Overview |
| 4 | |
| 5 | Release is done by pushing a `v*` tag. CI validates the release metadata, builds all platforms, creates a GitHub Release, and then updates the website version and Homebrew cask. Manual steps: update the changelog and version files, commit them together, then tag and push. The workflow is asynchronous: after a successful tag push, report that the release was triggered; do not wait for CI unless the user explicitly asks. |
| 6 | |
| 7 | **Announce at start:** "I'm using the release skill to ship a new version." |
| 8 | |
| 9 | ## When to Use |
| 10 | |
| 11 | ```dot |
| 12 | digraph when_release { |
| 13 | "User asks to release/ship/publish?" [shape=diamond]; |
| 14 | "Use this skill" [shape=box]; |
| 15 | "Homebrew 404 or artifact-not-found after a tag push?" [shape=diamond]; |
| 16 | "Use this skill" [shape=box]; |
| 17 | "Pre-release checks (code review, QA)?" [shape=diamond]; |
| 18 | "Not this skill — use requesting-code-review" [shape=box]; |
| 19 | |
| 20 | "User asks to release/ship/publish?" -> "Use this skill" [label="yes"]; |
| 21 | "User asks to release/ship/publish?" -> "Homebrew 404 or artifact-not-found after a tag push?" [label="no"]; |
| 22 | "Homebrew 404 or artifact-not-found after a tag push?" -> "Use this skill" [label="yes"]; |
| 23 | "Homebrew 404 or artifact-not-found after a tag push?" -> "Pre-release checks (code review, QA)?" [label="no"]; |
| 24 | "Pre-release checks (code review, QA)?" -> "Not this skill — use requesting-code-review" [label="yes"]; |
| 25 | } |
| 26 | ``` |
| 27 | |
| 28 | **Use when:** |
| 29 | - User says "release", "ship", "publish", "new version", "bump version" |
| 30 | - Homebrew cask update failed (404 on DMG URLs) |
| 31 | - CI `create-release` job failed to find artifacts |
| 32 | |
| 33 | **Don't use for:** |
| 34 | - Code review before releasing |
| 35 | - Deciding WHAT version number (ask the user) |
| 36 | - Feature work or bug fixes |
| 37 | |
| 38 | ## Quick Reference |
| 39 | |
| 40 | | Step | Command | |
| 41 | |------|---------| |
| 42 | | Check existing tags | `git tag --sort=-v:refname \| head -5` | |
| 43 | | Prerequisites (in order) | fmt → lint:rs → test → typecheck → lint → format:check → status | |
| 44 | | Check Rust formatting | `cargo fmt --check --manifest-path src-tauri/Cargo.toml` | |
| 45 | | Check Rust lint | `bun run lint:rs` | |
| 46 | | Check TypeScript types | `bun run typecheck` | |
| 47 | | Check frontend lint | `bun run lint` | |
| 48 | | Check frontend formatting | `bun run format:check` | |
| 49 | | Check uncommitted changes | `git status --short` | |
| 50 | | Tag and push | `git push origin main && git tag v<VERSION> && git push origin v<VERSION>` | |
| 51 | |
| 52 | ## Core Pattern |
| 53 | |
| 54 | All file changes (CHANGELOG, Cargo.toml, Cargo.lock, package.json) are made and committed together in a single commit. Do not commit after each step. (`docs/version.json` is updated by CI post-release.) |
| 55 | |
| 56 | ### 1. Confirm Version |
| 57 | |
| 58 | Ask the user. Check `git tag --sort=-v:refname | head -5` for context. Version must start with `v` (only `v*` tags trigger CI). |
| 59 | |
| 60 | ### 2. Update CHANGELOG.md |
| 61 | |
| 62 | Add a new version section before the previous release entry: |
| 63 | |
| 64 | ```markdown |
| 65 | ## [X.Y.Z] — YYYY-MM-DD |
| 66 | ``` |
| 67 | |
| 68 | Use today's date. Group changes under **Added**, **Changed**, **Fixed** headings. Review commits since the last tag with `git log --oneline v<LAST>..HEAD` to ensure nothing is missed. |
| 69 | |
| 70 | Do NOT commit yet — all changes go into one commit in Step 5. |
| 71 | |
| 72 | ### 3. Protocol Impact Check |
| 73 | |
| 74 | After writing the changelog, decide whether this release changes the desktop-owned local protocol. Desktop is the source of truth for local state; the CLI is an adjunct control surface and must follow the desktop protocol. |
| 75 | |
| 76 | Use changed paths as review prompts, not automatic gates. Relevant prompts include desktop persistence structs, archive/restore behavior, local state paths or shapes, schema versions, and CLI protocol read/write code. Trigger the protocol gate only when the release changes desktop-owned local state shape, paths, schema versions, lock/archive write semantics, or user-visible compatibility/migration behavior. |
| 77 | |
| 78 | If there is no protocol impact, note it internally and continue. Do not add "no impact" lines to CHANGELOG or commit messages. |
| 79 | |
| 80 | If there is protocol impact, verify before continuing: |
| 81 | |
| 82 | 1. `AGENTS.md` guidance still reflects the desktop-owned protocol relationship. |
| 83 | 2. `docs/local-protocol.md` reflects the current desktop protocol. |
| 84 | 3. `fixtures/local-protocol/` represents the desktop protocol, not CLI implementation convenience. |
| 85 | 4. CLI and Rust protocol fixture tests pass. |
| 86 | 5. CHANGELOG mentions any user-visible compatibility, migration, or breaking behavior. |
| 87 | |
| 88 | ### 4. Update Version Files |
| 89 | |
| 90 | Update `src-tauri/Cargo.toml` and `package.json` with `apply_patch` so the instructions work consistently on macOS, Linux, and Windows agents. Both files use bare semver without the `v` prefix. Then regenerate `Cargo.lock`: |
| 91 | |
| 92 | ```bash |
| 93 | cargo check --manifest-path src-tauri/Cargo.toml |
| 94 | ``` |
| 95 | |
| 96 | Do NOT update `docs/version.json` here — CI updates it automatically after the release is published. |
| 97 | |
| 98 | Do NOT commit yet — |
People who liked this also viewed
6 picksType
- paperclip-create-agentCreate new agents in Paperclip with governance-aware hiring. Use when you need to inspect adapter configuration options, compare existing agent configs, draft a new agent prompt/config, and submit a hSkillsJul 2026
- subagent-driven-developmentUse when executing implementation plans with independent tasks in the current sessionSkillsJul 2026
- dispatching-parallel-agentsUse when facing 2+ independent tasks that can be worked on without shared state or sequential dependenciesSkillsJul 2026
- browser-act-skill-forgeForges reusable Skill packages (SKILL.md + scripts) from website exploration via browser-act — no re-exploration later. Use when: user wants a reusable Skill for any website, needs to understand a sitSkillsJul 2026
- wizardGenerate an interactive bash wizard that walks a human through a manual procedure — third-party setup, a one-off migration, an A→B state transition — opening URLs, capturing values, confirming each stSkillsJul 2026
- wonda-cliUsing the Wonda CLI to generate images, videos, music, and audio from the terminal — plus LinkedIn, Reddit, and X/Twitter research and automationSkillsJul 2026
