PromptHub Release Sync
Use this skill for version bumps, release preparation, changelog or README
updates, website release sync, screenshots, and multilingual release material.
Read First
AGENTS.mdspec/releases/release-rules.mdspec/releases/README.md and the target version record, when presentpackage.json, workspace package manifests, and the newest relevant
CHANGELOG.md section
Do not treat this skill as a second release-policy source. Stable release
semantics belong in spec/releases/release-rules.md; this skill is the
execution procedure.
Establish Scope
Before editing, identify:
- target version and release date
- stable, prerelease, historical prerelease, or docs-only update
- affected distributions: desktop, CLI, self-hosted web, worker, mobile
- whether public copy, in-app copy, screenshots, installers, or signing changed
For non-trivial release work, create or update the matching active change
before implementation.
Source And Sync Order
- Update version-bearing manifests for affected distributions, including the
root and workspace packages when the monorepo version changes.
- Update
CHANGELOG.md and spec/releases/<version>.md.
- Sync repository-facing documentation:
README.mddocs/README.mddocs/README.en.mddocs/README.zh-TW.mddocs/README.ja.mddocs/README.de.mddocs/README.es.mddocs/README.fr.md
- Run
pnpm --dir website sync:release and inspect:
website/src/generated/release.tswebsite/src/content/docs/changelog.mdwebsite/src/content/docs/introduction.mdwebsite/src/content/docs/en/introduction.md
- Update non-generated website copy only when the release contract changed:
website/src/i18n/ui.tswebsite/src/pages/index.astrowebsite/src/pages/en/index.astro
- When desktop user-facing copy changed, synchronize all locale files under
apps/desktop/src/renderer/i18n/locales/.
- When visible GUI or feature emphasis changed, inspect and update matching
assets under
docs/imgs/ and website/public/imgs/.
- Synchronize durable conclusions into
spec/workflow/*, spec/knowledge/*,
spec/rules/*, or spec/adr/* only when their stable contracts changed.
Release Semantics
- Stable-facing badges, default downloads, and install instructions continue
to point to the latest stable version when preparing a prerelease.
- Historical prereleases below an existing stable version are manual testing
artifacts, not the default upgrade path.
- Do not document a GUI state without matching current UI evidence or updated
screenshots.
- Do not silently skip localized docs or locale files; record why a surface is
unaffected.
- When mentioning CLI availability, distinguish the CLI/npm distribution from
desktop-bundled behavior.
- Use the website sync command instead of hand-editing generated metadata.
Verification
Run the lowest relevant checks first, then:
pnpm verify:release:quick for local release-impacting changespnpm verify:release before tagging or publishing a release candidate- platform signing/notarization checks required by
spec/releases/release-rules.md for packaged macOS artifacts
Record commands, results, skipped surfaces, and residual risks in the active
change implementation.md. The quick profile is diagnostic and does not grant
release approval.
Completion Report
Report:
- target version and release type
- affected distributions and manifests
- website sync status
- screenshot status
- updated docs and locales
- verification results
- intentionally skipped surfaces and remaining release risk
1---2name: release-sync3description: PromptHub release update skill. Use for `/update-readme`, version bumps, changelog updates, website sync, GUI screenshot/doc refresh, and multilingual release/documentation alignment.4---5
6# PromptHub Release Sync
7
8Use this skill for version bumps, release preparation, changelog or README
9updates, website release sync, screenshots, and multilingual release material.
10
11## Read First
12
131. `AGENTS.md`
142. `spec/releases/release-rules.md`
153. `spec/releases/README.md` and the target version record, when present
164. `package.json`, workspace package manifests, and the newest relevant
17 `CHANGELOG.md` section
18
19Do not treat this skill as a second release-policy source. Stable release
20semantics belong in `spec/releases/release-rules.md`; this skill is the
21execution procedure.
22
23## Establish Scope
24
25Before editing, identify:
26
27- target version and release date
28- stable, prerelease, historical prerelease, or docs-only update
29- affected distributions: desktop, CLI, self-hosted web, worker, mobile
30- whether public copy, in-app copy, screenshots, installers, or signing changed
31
32For non-trivial release work, create or update the matching active change
33before implementation.
34
35## Source And Sync Order
36
371. Update version-bearing manifests for affected distributions, including the
38 root and workspace packages when the monorepo version changes.
392. Update `CHANGELOG.md` and `spec/releases/<version>.md`.
403. Sync repository-facing documentation:
41 - `README.md`
42 - `docs/README.md`
43 - `docs/README.en.md`
44 - `docs/README.zh-TW.md`
45 - `docs/README.ja.md`
46 - `docs/README.de.md`
47 - `docs/README.es.md`
48 - `docs/README.fr.md`
494. Run `pnpm --dir website sync:release` and inspect:
50 - `website/src/generated/release.ts`
51 - `website/src/content/docs/changelog.md`
52 - `website/src/content/docs/introduction.md`
53 - `website/src/content/docs/en/introduction.md`
545. Update non-generated website copy only when the release contract changed:
55 - `website/src/i18n/ui.ts`
56 - `website/src/pages/index.astro`
57 - `website/src/pages/en/index.astro`
586. When desktop user-facing copy changed, synchronize all locale files under
59 `apps/desktop/src/renderer/i18n/locales/`.
607. When visible GUI or feature emphasis changed, inspect and update matching
61 assets under `docs/imgs/` and `website/public/imgs/`.
628. Synchronize durable conclusions into `spec/workflow/*`, `spec/knowledge/*`,
63 `spec/rules/*`, or `spec/adr/*` only when their stable contracts changed.
64
65## Release Semantics
66
67- Stable-facing badges, default downloads, and install instructions continue
68 to point to the latest stable version when preparing a prerelease.
69- Historical prereleases below an existing stable version are manual testing
70 artifacts, not the default upgrade path.
71- Do not document a GUI state without matching current UI evidence or updated
72 screenshots.
73- Do not silently skip localized docs or locale files; record why a surface is
74 unaffected.
75- When mentioning CLI availability, distinguish the CLI/npm distribution from
76 desktop-bundled behavior.
77- Use the website sync command instead of hand-editing generated metadata.
78
79## Verification
80
81Run the lowest relevant checks first, then:
82
83- `pnpm verify:release:quick` for local release-impacting changes
84- `pnpm verify:release` before tagging or publishing a release candidate
85- platform signing/notarization checks required by
86 `spec/releases/release-rules.md` for packaged macOS artifacts
87
88Record commands, results, skipped surfaces, and residual risks in the active
89change `implementation.md`. The quick profile is diagnostic and does not grant
90release approval.
91
92## Completion Report
93
94Report:
95
96- target version and release type
97- affected distributions and manifests
98- website sync status
99- screenshot status
100- updated docs and locales
101- verification results
102- intentionally skipped surfaces and remaining release risk
legeling