release-sync

# 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 1. `AGENTS.md` 2. `spec/releases/release-rules.md` 3. `spec/releases/README.md` and the target version record, when present 4. `package.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 1. Update version-bearing manifests for affected distributions, including the root and workspace packages when the monorepo version changes. 2. Update `CHANGELOG.md` and `spec/releases/<version>.md`. 3. Sync repository-facing documentation: - `README.md` - `docs/README.md` - `docs/README.en.md` - `docs/README.zh-TW.md` - `docs/README.ja.md` - `docs/README.de.md` - `docs/README.es.md` - `docs/README.fr.md` 4. Run `pnpm --dir website sync:release` and inspect: - `website/src/generated/release.ts` - `website/src/content/docs/changelog.md` - `website/src/content/docs/introduction.md` - `website/src/content/docs/en/introduction.md` 5. Update non-generated website copy only when the release contract changed: - `website/src/i18n/ui.ts` - `website/src/pages/index.astro` - `website/src/pages/en/index.astro` 6. When desktop user-facing copy changed, synchronize all locale files under `apps/desktop/src/renderer/i18n/locales/`. 7. When visible GUI or feature emphasis changed, inspect and update matching assets under `docs/imgs/` and `website/public/imgs/`. 8. 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 changes - `pnpm 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