release

Name: release
Author: kansoku-trade

226stars19forks

How to install release?

kansoku-trade/kansoku/release

$npx -y skills add kansoku-trade/kansoku --skill release

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	# Desktop Release
2
3	Opens a version-bump PR for the Kansoku desktop app. Everything after the PR merge is automated:
4
5	```
6	this skill → release PR (ci.yml gates it) → merge to main
7	→ desktop-tag.yml creates desktop-vX.Y.Z + dispatches desktop-release.yml
8	→ build, sign, appcast, publish GitHub Release (notes from CHANGELOG.md)
9	→ users receive the Sparkle update
10	```
11
12	Optional argument: `patch` \| `minor` \| `major` — skips the bump suggestion step.
13
14	## Steps
15
16	### 1. Preflight (stop with an explanation if any fails)
17
18	```bash
19	git status --porcelain # must be empty
20	git branch --show-current # must be main
21	git fetch origin main && git rev-list --count main..origin/main # must be 0
22	```
23
24	### 2. Collect what shipped
25
26	```bash
27	LAST_TAG=$(git describe --tags --match 'desktop-v*' --abbrev=0)
28	git log "$LAST_TAG"..HEAD --oneline -- apps/ packages/ patches/ scripts/
29	```
30
31	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.
32
33	Read the actual diffs of significant commits when the one-line messages aren't enough to describe user-visible changes.
34
35	### 3. Decide the version
36
37	Current version: `node -p "require('./apps/desktop/package.json').version"`.
38
39	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.
40
41	### 4. Write the release notes
42
43	Prepend a section to `apps/desktop/CHANGELOG.md` (below the file header, above the previous version's section):
44
45	```markdown
46	## X.Y.Z — YYYY-MM-DD
47
48	- 更新点……
49	```
50
51	Rules for the notes (they become the GitHub Release body verbatim, and users read them):
52
53	- 中文白话, user-facing. Describe what the user will notice, not what the code did. "图表页新增指标开关" not "refactor indicator pipeline".
54	- Skip internal-only changes (refactors, CI, tests) unless they change behavior users can feel (e.g. faster startup).
55	- A handful of bullet points; group related commits into one bullet.
56	- Tickers, CLI/API names, file paths stay in English; no finance jargon without a plain-Chinese gloss.
57
58	### 5. Bump the version
59
60	Update `version` in `apps/desktop/package.json` to the confirmed `X.Y.Z`.
61
62	### 6. Open the PR
63
64	```bash
65	git checkout -b release/desktop-vX.Y.Z
66	git add apps/desktop/package.json apps/desktop/CHANGELOG.md
67	git commit -m "release(desktop): vX.Y.Z"
68	git push -u origin release/desktop-vX.Y.Z
69	gh pr create --title "release(desktop): vX.Y.Z" --body "<release notes section>"
70	```
71
72	PR body = the new CHANGELOG section, plus one line noting that merging will auto-tag and publish the release.
73
74	### 7. Hand off
75
76	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.
77
78	Then switch back to main: `git checkout main`.
79
80	## Guards
81
82	- Never tag manually here — tagging is desktop-tag.yml's job after merge.
83	- Never skip the CHANGELOG section — desktop-release.yml fails the build if the `## X.Y.Z` section is missing.
84	- Version in package.json and the CHANGELOG heading must match exactly (CI cross-checks tag vs package.json).

People who liked this also viewed

6 picks

Type

release

226stars19forks

View on GitHub

How to install release?

kansoku-trade/kansoku/release

$npx -y skills add kansoku-trade/kansoku --skill release

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Desktop Release
2
3	Opens a version-bump PR for the Kansoku desktop app. Everything after the PR merge is automated:
4
5	```
6	this skill → release PR (ci.yml gates it) → merge to main
7	→ desktop-tag.yml creates desktop-vX.Y.Z + dispatches desktop-release.yml
8	→ build, sign, appcast, publish GitHub Release (notes from CHANGELOG.md)
9	→ users receive the Sparkle update
10	```
11
12	Optional argument: `patch` \| `minor` \| `major` — skips the bump suggestion step.
13
14	## Steps
15
16	### 1. Preflight (stop with an explanation if any fails)
17
18	```bash
19	git status --porcelain # must be empty
20	git branch --show-current # must be main
21	git fetch origin main && git rev-list --count main..origin/main # must be 0
22	```
23
24	### 2. Collect what shipped
25
26	```bash
27	LAST_TAG=$(git describe --tags --match 'desktop-v*' --abbrev=0)
28	git log "$LAST_TAG"..HEAD --oneline -- apps/ packages/ patches/ scripts/
29	```
30
31	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.
32
33	Read the actual diffs of significant commits when the one-line messages aren't enough to describe user-visible changes.
34
35	### 3. Decide the version
36
37	Current version: `node -p "require('./apps/desktop/package.json').version"`.
38
39	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.
40
41	### 4. Write the release notes
42
43	Prepend a section to `apps/desktop/CHANGELOG.md` (below the file header, above the previous version's section):
44
45	```markdown
46	## X.Y.Z — YYYY-MM-DD
47
48	- 更新点……
49	```
50
51	Rules for the notes (they become the GitHub Release body verbatim, and users read them):
52
53	- 中文白话, user-facing. Describe what the user will notice, not what the code did. "图表页新增指标开关" not "refactor indicator pipeline".
54	- Skip internal-only changes (refactors, CI, tests) unless they change behavior users can feel (e.g. faster startup).
55	- A handful of bullet points; group related commits into one bullet.
56	- Tickers, CLI/API names, file paths stay in English; no finance jargon without a plain-Chinese gloss.
57
58	### 5. Bump the version
59
60	Update `version` in `apps/desktop/package.json` to the confirmed `X.Y.Z`.
61
62	### 6. Open the PR
63
64	```bash
65	git checkout -b release/desktop-vX.Y.Z
66	git add apps/desktop/package.json apps/desktop/CHANGELOG.md
67	git commit -m "release(desktop): vX.Y.Z"
68	git push -u origin release/desktop-vX.Y.Z
69	gh pr create --title "release(desktop): vX.Y.Z" --body "<release notes section>"
70	```
71
72	PR body = the new CHANGELOG section, plus one line noting that merging will auto-tag and publish the release.
73
74	### 7. Hand off
75
76	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.
77
78	Then switch back to main: `git checkout main`.
79
80	## Guards
81
82	- Never tag manually here — tagging is desktop-tag.yml's job after merge.
83	- Never skip the CHANGELOG section — desktop-release.yml fails the build if the `## X.Y.Z` section is missing.
84	- Version in package.json and the CHANGELOG heading must match exactly (CI cross-checks tag vs package.json).

People who liked this also viewed

6 picks

Type