release
/release
Wydaje nową wersję aplikacji desktopowej: podbija wersję w apps/desktop, pisze notatki dla użytkowników w CHANGELOG.md i otwiera pull request uruchamiający zautomatyzowany pipeline tag, build, publikacja.
- Autor
- kansoku-trade ↗
- Repozytorium
- kansoku ↗
- Licencja
- AGPL-3.0
- Ostatnia zmiana repozytorium
- 26.09.2026
Ocena i bezpieczeństwo
- Pliki w paczce
- 1
- Skrypty
- 0
- Komentarze HTML
- 0
- Adresy URL w SKILL.md
- 0
Brak sygnałów. Repozytorium zmienione 26.09.2026, bez odwołań do wycofanych modeli i API.
AGPL-3.0, copyleft: przeróbki udostępniane innym muszą mieć tę samą licencję.
Co robi i kiedy
Wydaje nową wersję aplikacji desktopowej: podbija wersję w apps/desktop, pisze notatki dla użytkowników w CHANGELOG.md i otwiera pull request uruchamiający zautomatyzowany pipeline tag, build, publikacja.
Oryginalny opis (EN)
Use when the user wants to release a new desktop app version (发版 / release / 发布新版本) — bumps apps/desktop version, writes user-facing release notes into CHANGELOG.md, and opens the release PR that drives the automated tag → build → publish pipeline
Jak działa
- Steps
- Guards
Podgląd SKILL.md
---
name: release
description: Use when the user wants to release a new desktop app version (发版 / release / 发布新版本) — bumps apps/desktop version, writes user-facing release notes into CHANGELOG.md, and opens the release PR that drives the automated tag → build → publish pipeline
---
# Desktop Release
Opens a version-bump PR for the Kansoku desktop app. Everything after the PR merge is automated:
```
this skill → release PR (ci.yml gates it) → merge to main
→ desktop-tag.yml creates desktop-vX.Y.Z + dispatches desktop-release.yml
→ build, sign, appcast, publish GitHub Release (notes from CHANGELOG.md)
→ users receive the Sparkle update
```
Optional argument: `patch` | `minor` | `major` — skips the bump suggestion step.
## Steps
### 1. Preflight (stop with an explanation if any fails)
```bash
git status --porcelain # must be empty
git branch --show-current # must be main
git fetch origin main && git rev-list --count main..origin/main # must be 0
```
If `apps/pro` is present (linked worktree), also pin the release to that commit **before** opening the PR. `desktop-release.yml` fetches Pro at the GitHub Actions variable `KANSOKU_PRO_REF` and then runs `pnpm install --frozen-lockfile`. A stale pin (the SHA from the last release) against a lockfile that already absorbed a newer `apps/pro/package.json` fails install. This is what hung v0.41.0.
```bash
git -C apps/pro status --porcelain # must be empty
git -C apps/pro fetch origin
PRO_SHA="$(git -C apps/pro rev-parse HEAD)"
git -C apps/pro merge-base --is-ancestor "$PRO_SHA" origin/main # HEAD must already be on origin/main
gh variable set KANSOKU_PRO_REF --body "$PRO_SHA"
gh variable get KANSOKU_PRO_REF # must print $PRO_SHA
```
### 2. Collect what shipped
```bash
LAST_TAG=$(git describe --tags --match 'desktop-v*' --abbrev=0)
git log "$LAST_TAG"..HEAD --oneline -- apps/ packages/ patches/ scripts/
```
If `git describe` finds no tag, this is the first release — use the full history of those paths. If there are no commits touching `apps/`, `packages/`, `patches/`, or `scripts/` since the last tag, stop: nothing to release.
Read the actual diffs of significant commits when the one-line messages aren't enough to describe user-visible changes.
### 3. Decide the version
Current version: `node -p "require('./apps/desktop/package.json').version"`.
If the user passed `patch`/`minor`/`major`, apply it directly. Otherwise suggest one — any `feat` → minor, only fixes/refactors/chores → patch, breaking changes to user data or workflows → major — and **ask the user to confirm the version number before continuing**.
### 4. Write the release notes
Prepend a section to `apps/desktop/CHANGELOG.md` (below the file header, above the previous version's section):
```markdown
## X.Y.Z — YYYY-MM-DD
- 更新点……
```
Rules for the notes (they become the GitHub Release body verbatim, and users read them):
- 中文白话, user-facing. Describe what the user will notice, not what the code did. "图表页新增指标开关" not "refactor indicator pipeline".
- Skip internal-only changes (refactors, CI, tests) unless they change behavior users can feel (e.g. faster startup).
- A handful of bullet points; group related commits into one bullet.
- Tickers, CLI/API names, file paths stay in English; no finance jargon without a plain-Chinese gloss.
### 5. Bump the version
Update `version` in `apps/desktop/package.json` to the confirmed `X.Y.Z`.
### 6. Open the PR
```bash
git checkout -b release/desktop-vX.Y.Z
git add apps/desktop/package.json apps/desktop/CHANGELOG.md
git commit -m "release(desktop): vX.Y.Z"
git push -u origin release/desktop-vX.Y.Z
gh pr create --title "release(desktop): vX.Y.Z" --body "<release notes section>"
```
PR body = the new CHANGELOG section, plus one line noting that merging will auto-tag and publish the release.
### 7. Hand off
Show the PR link and remind: merge = release. After merge, `desktop-tag.yml` tags and dispatches `desktop-release.yml`; the release publishes automatically and the Sparkle feed goes live immediately.
Then switch back to main: `git checkout main`.
## Guards
- Never tag manually here — tagging is desktop-tag.yml's job after merge.
- Never skip the CHANGELOG section — desktop-release.yml fails the build if the `## X.Y.Z` section is missing.
- Version in package.json and the CHANGELOG heading must match exactly (CI cross-checks tag vs package.json).
- Never open the release PR with a stale `KANSOKU_PRO_REF`. The pin must be `apps/pro` HEAD, already on `origin/main`, and must match the lockfile's `apps/pro` specifiers.
Wersje
| Repozytorium | Wynik | Licencja |
|---|---|---|
| Ta strona · kansoku-trade/kansoku | 100 | AGPL-3.0 |
| max-sixty/worktrunk | 100 | MIT |
| gtapps/hermitd | 100 | MIT |
| gtapps/hermitd | 100 | MIT |
| anthony-chaudhary/fak | 100 | Apache-2.0 |
| tractorjuice/arc-kit | 100 | MIT |
| drvoss/everything-copilot-cli | 100 | MIT |
| sma1lboy/rove | 100 | MIT |
| codealong/codealong | 100 | Apache-2.0 |
Migawka bazy z 28.10.2026 · wersja paczki 2b77391c2d13 (skrót SHA-256 całej paczki)
Pobrania w ostatnich 30 dniach: 0 · ranking
Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.
Podobne skille
- 100ac-release
Prowadzi przepływ wydania: branch, changelog, pull request, tag i wydanie na GitHubie. - 100release-cli
Wydaje nową wersję CLI pd: uruchamia testy, podbija wersję, tworzy tag i wypycha go do zdalnego repozytorium. - 100version-release
Podbija wersję, tworzy tag wydania i wypycha tag do repozytorium. - 90qmai-release
Wydaje stabilną wersję QMAI: aktualizuje metadane i changelog, wypycha main i tworzy adnotowany tag wersji. - 100deploy
Wydaje nową wersję wipnote: uruchamia bramki jakości, podbija wersję, taguje, wypycha zmiany i uruchamia pipeline wydania na GitHubie. - 100openseo-release-notes
Przygotowuje wydanie OpenSEO: podnosi wersję, pisze notatki dla użytkowników z commitów od ostatniego tagu, przeprowadza przegląd z weryfikacją podagentów i otwiera pull request release.