release-sync
starsforks
How to install release-sync?
legeling/prompthub/release-sync
$npx -y skills add legeling/PromptHub --skill release-syncPromptHub release update skill. Use for /update-readme, version bumps, changelog updates, website sync, GUI screenshot/doc refresh, and multilingual release/documentation alignment.
SKILL.md
| 1 | # PromptHub Release Sync |
| 2 | |
| 3 | Use this skill for version bumps, release preparation, changelog or README |
| 4 | updates, website release sync, screenshots, and multilingual release material. |
| 5 | |
| 6 | ## Read First |
| 7 | |
| 8 | 1. `AGENTS.md` |
| 9 | 2. `spec/releases/release-rules.md` |
| 10 | 3. `spec/releases/README.md` and the target version record, when present |
| 11 | 4. `package.json`, workspace package manifests, and the newest relevant |
| 12 | `CHANGELOG.md` section |
| 13 | |
| 14 | Do not treat this skill as a second release-policy source. Stable release |
| 15 | semantics belong in `spec/releases/release-rules.md`; this skill is the |
| 16 | execution procedure. |
| 17 | |
| 18 | ## Establish Scope |
| 19 | |
| 20 | Before editing, identify: |
| 21 | |
| 22 | - target version and release date |
| 23 | - stable, prerelease, historical prerelease, or docs-only update |
| 24 | - affected distributions: desktop, CLI, self-hosted web, worker, mobile |
| 25 | - whether public copy, in-app copy, screenshots, installers, or signing changed |
| 26 | |
| 27 | For non-trivial release work, create or update the matching active change |
| 28 | before implementation. |
| 29 | |
| 30 | ## Source And Sync Order |
| 31 | |
| 32 | 1. Update version-bearing manifests for affected distributions, including the |
| 33 | root and workspace packages when the monorepo version changes. |
| 34 | 2. Update `CHANGELOG.md` and `spec/releases/<version>.md`. |
| 35 | 3. Sync repository-facing documentation: |
| 36 | - `README.md` |
| 37 | - `docs/README.md` |
| 38 | - `docs/README.en.md` |
| 39 | - `docs/README.zh-TW.md` |
| 40 | - `docs/README.ja.md` |
| 41 | - `docs/README.de.md` |
| 42 | - `docs/README.es.md` |
| 43 | - `docs/README.fr.md` |
| 44 | 4. Run `pnpm --dir website sync:release` and inspect: |
| 45 | - `website/src/generated/release.ts` |
| 46 | - `website/src/content/docs/changelog.md` |
| 47 | - `website/src/content/docs/introduction.md` |
| 48 | - `website/src/content/docs/en/introduction.md` |
| 49 | 5. Update non-generated website copy only when the release contract changed: |
| 50 | - `website/src/i18n/ui.ts` |
| 51 | - `website/src/pages/index.astro` |
| 52 | - `website/src/pages/en/index.astro` |
| 53 | 6. When desktop user-facing copy changed, synchronize all locale files under |
| 54 | `apps/desktop/src/renderer/i18n/locales/`. |
| 55 | 7. When visible GUI or feature emphasis changed, inspect and update matching |
| 56 | assets under `docs/imgs/` and `website/public/imgs/`. |
| 57 | 8. Synchronize durable conclusions into `spec/workflow/*`, `spec/knowledge/*`, |
| 58 | `spec/rules/*`, or `spec/adr/*` only when their stable contracts changed. |
| 59 | |
| 60 | ## Release Semantics |
| 61 | |
| 62 | - Stable-facing badges, default downloads, and install instructions continue |
| 63 | to point to the latest stable version when preparing a prerelease. |
| 64 | - Historical prereleases below an existing stable version are manual testing |
| 65 | artifacts, not the default upgrade path. |
| 66 | - Do not document a GUI state without matching current UI evidence or updated |
| 67 | screenshots. |
| 68 | - Do not silently skip localized docs or locale files; record why a surface is |
| 69 | unaffected. |
| 70 | - When mentioning CLI availability, distinguish the CLI/npm distribution from |
| 71 | desktop-bundled behavior. |
| 72 | - Use the website sync command instead of hand-editing generated metadata. |
| 73 | |
| 74 | ## Verification |
| 75 | |
| 76 | Run the lowest relevant checks first, then: |
| 77 | |
| 78 | - `pnpm verify:release:quick` for local release-impacting changes |
| 79 | - `pnpm verify:release` before tagging or publishing a release candidate |
| 80 | - platform signing/notarization checks required by |
| 81 | `spec/releases/release-rules.md` for packaged macOS artifacts |
| 82 | |
| 83 | Record commands, results, skipped surfaces, and residual risks in the active |
| 84 | change `implementation.md`. The quick profile is diagnostic and does not grant |
| 85 | release approval. |
| 86 | |
| 87 | ## Completion Report |
| 88 | |
| 89 | Report: |
| 90 | |
| 91 | - target version and release type |
| 92 | - affected distributions and manifests |
| 93 | - website sync status |
| 94 | - screenshot status |
| 95 | - updated docs and locales |
| 96 | - verification results |
| 97 | - intentionally skipped surfaces and remaining release risk |
People who liked this also viewed
6 picksType
- lark-drive飞书云空间（云盘/云存储）：管理 Drive 文件和文件夹，包含上传/下载、创建文件夹、复制/移动/删除、查看元数据、评论/权限/订阅、标题、版本、飞书文档密级标签（secure labels）和本地文件导入。用户需要整理云盘目录、处理云空间资源 URL/token、判断链接类型/真实 token/标题，或导入 Word/Markdown/Excel/CSV/PPTX/.base 为 docx/sSkillsJul 2026
- lark-sharedUse for lark-cli setup/auth tasks: auth login/status/logout, user vs bot identity, business-domain permissions (--domain, including all/docs/drive), missing scopes, revoking authorization, or handlingSkillsJul 2026
- lark-whiteboard飞书画板：查询和编辑飞书云文档中的画板。支持导出画板为预览图片、导出原始节点结构、使用多种格式更新画板内容。 当用户需要查看画板内容、导出画板图片、编辑画板时使用此 skill。不负责：飞书云文档内容编辑（lark-doc）、文档内嵌电子表格/Base（lark-sheets / lark-base）。SkillsJul 2026
- lark-task飞书任务：管理任务、清单和任务智能体。创建待办任务、查看和更新任务状态、拆分子任务、组织任务清单、分配协作成员、上传任务附件、注册或注销任务智能体、更新任务智能体的主页数据、写入智能体任务记录。当用户需要创建待办事项、查看任务列表、跟踪任务进度、管理项目清单或给他人分配任务、为任务上传附件文件、注册注销任务智能体、更新智能体主页数据、写入任务记录时使用。SkillsJul 2026
- lark-attendance飞书考勤打卡：查询自己的考勤打卡记录SkillsJul 2026
- lark-apps妙搭（Spark/Miaoda）应用开发与托管：应用创建、本地全栈开发、云端生成迭代、创意设计（UI mockup / 可交互原型 / 线框图 / 落地页 / 仪表盘 / 幻灯片 deck / 视觉探索）、AI相关能力和飞书平台能力或者其他外部能力集成、日志/Trace/监控指标/PV/UV 查询、环境变量管理、应用角色与成员管理、自动化触发器（定时/记录变更/Webhook/飞书审批）。当用户要SkillsJul 2026
