开发工具接口测试桌面应用【免费下载链接】yaakThe most intuitive desktop API client. Organize and execute REST, GraphQL, WebSockets, Server Sent Events, and gRPC 项目地址https://gitcode.com/GitHub_Trending/ya/yaak点击查看免费下载YaakREADME.md 中自述为 The most intuitive desktop API client在其开源仓库中沉淀了一套面向 AI 编码代理Codex 等的 changelog 编写技能规范位于 .codex/skills/yaak-changelog/SKILL.md。该规范定义了 Yaak 项目Beta 版本走 GitHub Release、稳定版本走网站 changelog的双轨制发布体系并给出了从识别目标版本、解析 release notes、生成_release.yaml到发布前校验的完整工作流。读完本文你将掌握如何判定一次更新应落在 GitHub Release Body 还是网站src/content/changelog/目录、如何把提交与 PR 元数据整理为符合 Yaak 风格的变更条目、以及_release.yaml与_intro.md的字段语义和检查清单。一、Yaak 变更日志的双轨制架构Yaak 的 changelog 并不只有一份而是按发布形态分为两轨二者写入位置完全不同Beta 或 draft prerelease 的变更日志只存在于 GitHub Release 上release body 本身不落盘到网站目录稳定版Stable的变更日志存放在网站文件中路径格式为src/content/changelog/YYYYMMDD_VERSION/例如src/content/changelog/20260930_2026.9.0/。这一设计的直接后果是任何编写动作的第一步都不是写文字而是先判定当前要处理的是哪一轨因为两轨的产物、位置、校验方式截然不同。仓库内的配套技能 release-generate-release-notes/SKILL.md 负责从 git 历史与 PR 元数据生成最初的 release notes 草稿而 yaak-changelog/SKILL.md 负责把这些草稿落位到正确的轨道上。二、识别目标 ReleaseBeta 还是 Stable工作流的第一步是确认目标版本属于哪一类判定依据是 tag 与 GitHub Release 的形态如果目标 tag 包含-beta或对应的 GitHub Release 是 draft prerelease则只更新 GitHub release body不得创建或编辑src/content/changelog/下的任何文件如果目标是新的稳定版则把该版本自上一个稳定版以来的所有 beta release notes 汇总然后创建或编辑网站 changelog 文件。数据来源优先使用gh api或 GitHub Release 页面在网络受限的环境下应在查询 GitHub 之前先向用户申请许可。抓取过程中需要顺带提取两类信息PR 编号用于生成 PR 链接yaak.app/feedback反馈链接Yaak 产品内嵌的用户反馈入口链接形如https://yaak.app/feedback/posts/slug。如果抓取结果中大多数 bullet 都没有携带 PR 引用规范要求用更明确的提示词重新抓取一次。同时在生成或修订 release notes 时应抓取 PR 作者信息以便为非gschier作者的外部贡献者添加署名。三、解析 Release Bullets从条目到 changelog entry拿到原始 release notes 后需要逐条解析核心规则是一条 release-note bullet 对应一个 changelog entry。解析时按下述规则处理过滤无用户价值条目跳过 dependency-only纯依赖升级、generated自动生成、build-only纯构建、test-only纯测试、CI-only纯 CI以及 internal maintenance内部维护类 bullet——除非它们具有可以用用户语言描述的明确用户可见影响跳过 beta 专属内容在稳定版网站 changelog 中跳过以[beta-only]前缀开头的 bullet保留措辞尽量保留条目原文表述仅移除标题上包裹的引号归类将每个条目映射到feature新功能、fix修复、improvement改进或breaking破坏性变更四个类别之一PR 链接化把正文中的#NNN形式编号转换为对应 PR 的完整链接格式为https://github.com/mountain-loop/yaak/pull/NNN。这里之所以要求保留原文措辞与 release-generate-release-notes/SKILL.md 中提交粒度的要求一脉相承——release notes 的草稿阶段通过git log --oneline prev_tag..target_tag收集区间内提交再对每个关联 PR 执行gh pr view PR_NUMBER --json number,title,body,author,url提取标题、正文、作者与 URL最终从 PR 中挖掘 feedback 链接、外部贡献者 handle、插件安装链接等上下文。这也是为什么正式 changelog 中每个条目都能追溯到具体 PR。四、Beta / Draft Prerelease只更新 GitHub Release Body对于 Beta 或 draft prerelease规范明确只动 GitHub不动网站不要创建网站 changelog 目录不要为 beta release 添加 changelog badge 或yaak.app/changelog/VERSION链接bullet 保持简洁优先携带 PR 链接与 feedback 链接。Feedback 链接的排版规则易错点当一个 bullet 带有 feedback URL 时把整条 changelog 文本本身用 feedback 链接包裹PR 链接紧随其后而不是在条目末尾另起一个独立的Feedback:链接。规范给出的示例为- [Fixed request history timestamps](https://yaak.app/feedback/posts/request-history-time-stamp) in [#492](https://github.com/mountain-loop/yaak/pull/492)贡献者署名规则对由外部贡献者合入的 PR 条目在其末尾追加by [handle](https://github.com/handle)对gschier项目维护者自己的 PR 则不要追加by gschier。Full Changelog 对比链接在 release body 末尾附上Full Changelog对比链接——若存在前一个 beta tag 则与前一个 beta tag 对比若是beta.1该版本首个 beta则与前一个 stable tag 对比。落地命令使用gh release edit TAG --repo mountain-loop/yaak --notes-file 路径或 GitHub Release API 更新 draft/prerelease body。规范特别强调更新完 GitHub release body 即视为完成此轨道不再执行后面的网站检查项。五、Stable创建或编辑网站 Release 目录稳定版走网站目录路径格式固定为src/content/changelog/YYYYMMDD_VERSION/对新版本YYYYMMDD取当天日期对已存在的 release保留原目录日期不要因为今天日期不同而改动Beta 版本一律不创建 changelog 目录。该目录下存在三类文件详见文件规则一节主文件_release.yaml、可选的_intro.md以及被content字段引用的扩展条目 markdown 文件。六、_release.yaml 配置详解_release.yaml是稳定版 changelog 的元数据核心支持字段包括draft是否草稿、可选的title、summary、image、youtube以及必有的entries列表。次要条目直接作为 quick entries 写入entries不设content字段只有需要独立 markdown 分节的条目才使用content字段指向同目录下的 markdown 文件。规范给出的完整示例此处补充字段注释可直接复用title: Whats New in 2026.1.0 # 可选本版本标题 summary: Brief overview of the most important additions and fixes # 可选一句话摘要 draft: true # 是否草稿状态 entries: - title: Request debugging # 条目标题 category: feature # feature | fix | improvement | breaking pr: https://github.com/mountain-loop/yaak/pull/123 # 关联 PR 链接 feedback: https://feedback.yaak.app/p/request-debugging # 可选用户反馈链接 content: request-debugging.md # 可选指向同目录扩展 markdown 文件 - title: Fix broken cookie clearing category: fix pr: https://github.com/mountain-loop/yaak/pull/124注意两点约束entries[].content引用的文件名必须真实存在于同一目录category的取值即为解析 Release Bullets一节中规定的四类映射。七、扩展主要条目Major Entries并非所有条目都需要展开。规范要求在上下文足够的前提下挑出 36 个重大条目major items进行扩展做法是为每个大条目创建slugified短横线命名的 markdown 文件例如request-debugging.md在_release.yaml的对应entries中通过content字段引用该文件在动笔前先阅读相关 PR确保扩展内容基于真实实现而非臆测仅当有助于区分大节时才为扩展条目的标题添加 emoji 前缀——普通 quick entries 不需要。八、图片处理changelog 配图遵循能复用就复用没有就占位的原则优先复用 PR 中已有的截图GitHub 私有附件链接需先转换为公开资产链接格式为https://github.com/user-attachments/assets/UUID再上传环境允许时用命令go run cmd/yaakadmin/main.go upload URL上传该命令属于 yaak.app 网站仓库的管理工具若没有真实图片则使用占位图但必须提供真实的 alt 文本与说明文字caption提交到仓库的 changelog 图片统一存放在static/changelog/VERSION/目录下。九、_intro.md 与 Yaak 写作风格_intro.md放在 release 页面顶部是一段简短的总览写作要求是聚焦整个 release 的主要主题major themes而不是逐条复述 entries 中的每个 bullet。Yaak 的 changelog 写作风格规范同样适用于 GitHub release body直接、事实化避免夸大宣传hype说清楚改了什么以及怎么用段落保持短小代码符号、设置项、字面值一律使用反引号backticks粗体bold只用于节内最重要的短语克制使用。十、文件规则与发布前检查清单文件规则File RulesBeta release 不得创建或编辑src/content/changelog/下的任何文件主文件为_release.yaml可选文件为_intro.md扩展条目文件是普通 markdown 文件如request-debugging.mdentries[].content必须匹配同目录下真实存在的 markdown 文件名提交到仓库的 changelog 图片存放于static/changelog/VERSION/。检查清单ChecksBeta release执行gh release view TAG --repo mountain-loop/yaak --json body,tagName,isDraft,isPrerelease核验并确认没有创建任何网站 changelog 文件核验带 feedback 的 bulletfeedback URL 是整条文本的链接目标而不是末尾独立的Feedback:链接。Stable release确保每条有用户影响的源 bullet 都恰好生成一个 changelog entry除非它是[beta-only]、纯依赖或内部维护类当源 release notes 提供 PR 编号时多数条目应包含pr字段确保每个被content引用的文件真实存在如需完整网站核验可运行站点并检查/changelog/VERSION与/rss.xml。十一、仓库中的配套工程背景这套 changelog 规范并非孤立存在它与仓库中的版本管理约定紧密耦合AGENTS.md 记录了 tag 安全规则应用与 CLI 都从v*tag 发布CLI 与应用版本锁定且在每个应用 tag 上向 npm 发布yaakapp/api则使用yaak-api-*独立 tag——因此 changelog 工作流中定位目标 tag前必须先确认用户要处理的是应用/CLI 还是 API 的发布release-generate-release-notes/SKILL.md 作为上游环节负责生成最初的 release notes并规定排除仅触及crates-cli/的 CLI 专属变更CLI 拥有自己的发布流程这与 changelog 解析阶段跳过无用户价值条目的原则相互呼应crates-cli/yaak-cli/skills/use-yaak/SKILL.md 则说明yaakCLI 与桌面应用共享同一本地数据库、yaak auth仅用于向插件注册表发布插件——了解这一点有助于在 release notes 中准确区分应用功能与CLI/插件生态的变更归属避免把插件功能误写入应用 changelog。结语Yaak 的 changelog 体系用一套可执行的技能规范把发版说明这种容易被忽视的环节工程化了通过 tag 形态判定轨道、按用户价值过滤条目、用_release.yaml统一元数据、以检查清单兜底质量。对于希望在多版本并行发布beta 与 stable 共存下保持变更记录准确、可追溯、可读的开源项目维护者而言这套双轨制工作流是一个相当完整的参考范式——尤其是feedback 链接包裹整条文本外部贡献者署名beta 不落网站目录等细节规则直接避免了发布实践中常见的链接失效与信息错位问题。赞分享开发工具接口测试桌面应用【免费下载链接】yaakThe most intuitive desktop API client. Organize and execute REST, GraphQL, WebSockets, Server Sent Events, and gRPC 项目地址https://gitcode.com/GitHub_Trending/ya/yaak点击查看免费下载相关推荐BrewUI项目结构拆解20个SwiftPM模块背后的设计思路BrewUI项目结构拆解20个SwiftPM模块背后的设计思路 BrewUI 是 Homebrew 官方推出的 macOS 图形界面让不熟悉终端的用户桌面应用开发工具Warp 变更日志片段语言规范Towncrier 工作流下的 Changelog 写作与审查实践Warp 变更日志片段语言规范Towncrier 工作流下的 Changelog 写作与审查实践 WarpNVIDIA 开源的 GPU 加速仿真 Pytho高性能计算物理引擎图形学机器人Puter.js 完整指南免 API Key、3 分钟接入 500 AI 模型与云存储Puter.js 完整指南免 API Key、3 分钟接入 500 AI 模型与云存储 Puter.js 把登录认证、AI 对话、云盘和键值数据库打包进一个后端前端云原生上一篇DLSS Swapper终极指南一键优化游戏性能的画质增强神器下一篇用 KubeStellar Console Agent 接管多集群 Kubernetes 运维基于 awesome-copilot 的部署与排障实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Yaak 变更日志编写指南：Beta 与 Stable 双轨制工作流及 _release.yaml 规范
开发工具接口测试桌面应用【免费下载链接】yaakThe most intuitive desktop API client. Organize and execute REST, GraphQL, WebSockets, Server Sent Events, and gRPC 项目地址https://gitcode.com/GitHub_Trending/ya/yaak点击查看免费下载YaakREADME.md 中自述为 The most intuitive desktop API client在其开源仓库中沉淀了一套面向 AI 编码代理Codex 等的 changelog 编写技能规范位于 .codex/skills/yaak-changelog/SKILL.md。该规范定义了 Yaak 项目Beta 版本走 GitHub Release、稳定版本走网站 changelog的双轨制发布体系并给出了从识别目标版本、解析 release notes、生成_release.yaml到发布前校验的完整工作流。读完本文你将掌握如何判定一次更新应落在 GitHub Release Body 还是网站src/content/changelog/目录、如何把提交与 PR 元数据整理为符合 Yaak 风格的变更条目、以及_release.yaml与_intro.md的字段语义和检查清单。一、Yaak 变更日志的双轨制架构Yaak 的 changelog 并不只有一份而是按发布形态分为两轨二者写入位置完全不同Beta 或 draft prerelease 的变更日志只存在于 GitHub Release 上release body 本身不落盘到网站目录稳定版Stable的变更日志存放在网站文件中路径格式为src/content/changelog/YYYYMMDD_VERSION/例如src/content/changelog/20260930_2026.9.0/。这一设计的直接后果是任何编写动作的第一步都不是写文字而是先判定当前要处理的是哪一轨因为两轨的产物、位置、校验方式截然不同。仓库内的配套技能 release-generate-release-notes/SKILL.md 负责从 git 历史与 PR 元数据生成最初的 release notes 草稿而 yaak-changelog/SKILL.md 负责把这些草稿落位到正确的轨道上。二、识别目标 ReleaseBeta 还是 Stable工作流的第一步是确认目标版本属于哪一类判定依据是 tag 与 GitHub Release 的形态如果目标 tag 包含-beta或对应的 GitHub Release 是 draft prerelease则只更新 GitHub release body不得创建或编辑src/content/changelog/下的任何文件如果目标是新的稳定版则把该版本自上一个稳定版以来的所有 beta release notes 汇总然后创建或编辑网站 changelog 文件。数据来源优先使用gh api或 GitHub Release 页面在网络受限的环境下应在查询 GitHub 之前先向用户申请许可。抓取过程中需要顺带提取两类信息PR 编号用于生成 PR 链接yaak.app/feedback反馈链接Yaak 产品内嵌的用户反馈入口链接形如https://yaak.app/feedback/posts/slug。如果抓取结果中大多数 bullet 都没有携带 PR 引用规范要求用更明确的提示词重新抓取一次。同时在生成或修订 release notes 时应抓取 PR 作者信息以便为非gschier作者的外部贡献者添加署名。三、解析 Release Bullets从条目到 changelog entry拿到原始 release notes 后需要逐条解析核心规则是一条 release-note bullet 对应一个 changelog entry。解析时按下述规则处理过滤无用户价值条目跳过 dependency-only纯依赖升级、generated自动生成、build-only纯构建、test-only纯测试、CI-only纯 CI以及 internal maintenance内部维护类 bullet——除非它们具有可以用用户语言描述的明确用户可见影响跳过 beta 专属内容在稳定版网站 changelog 中跳过以[beta-only]前缀开头的 bullet保留措辞尽量保留条目原文表述仅移除标题上包裹的引号归类将每个条目映射到feature新功能、fix修复、improvement改进或breaking破坏性变更四个类别之一PR 链接化把正文中的#NNN形式编号转换为对应 PR 的完整链接格式为https://github.com/mountain-loop/yaak/pull/NNN。这里之所以要求保留原文措辞与 release-generate-release-notes/SKILL.md 中提交粒度的要求一脉相承——release notes 的草稿阶段通过git log --oneline prev_tag..target_tag收集区间内提交再对每个关联 PR 执行gh pr view PR_NUMBER --json number,title,body,author,url提取标题、正文、作者与 URL最终从 PR 中挖掘 feedback 链接、外部贡献者 handle、插件安装链接等上下文。这也是为什么正式 changelog 中每个条目都能追溯到具体 PR。四、Beta / Draft Prerelease只更新 GitHub Release Body对于 Beta 或 draft prerelease规范明确只动 GitHub不动网站不要创建网站 changelog 目录不要为 beta release 添加 changelog badge 或yaak.app/changelog/VERSION链接bullet 保持简洁优先携带 PR 链接与 feedback 链接。Feedback 链接的排版规则易错点当一个 bullet 带有 feedback URL 时把整条 changelog 文本本身用 feedback 链接包裹PR 链接紧随其后而不是在条目末尾另起一个独立的Feedback:链接。规范给出的示例为- [Fixed request history timestamps](https://yaak.app/feedback/posts/request-history-time-stamp) in [#492](https://github.com/mountain-loop/yaak/pull/492)贡献者署名规则对由外部贡献者合入的 PR 条目在其末尾追加by [handle](https://github.com/handle)对gschier项目维护者自己的 PR 则不要追加by gschier。Full Changelog 对比链接在 release body 末尾附上Full Changelog对比链接——若存在前一个 beta tag 则与前一个 beta tag 对比若是beta.1该版本首个 beta则与前一个 stable tag 对比。落地命令使用gh release edit TAG --repo mountain-loop/yaak --notes-file 路径或 GitHub Release API 更新 draft/prerelease body。规范特别强调更新完 GitHub release body 即视为完成此轨道不再执行后面的网站检查项。五、Stable创建或编辑网站 Release 目录稳定版走网站目录路径格式固定为src/content/changelog/YYYYMMDD_VERSION/对新版本YYYYMMDD取当天日期对已存在的 release保留原目录日期不要因为今天日期不同而改动Beta 版本一律不创建 changelog 目录。该目录下存在三类文件详见文件规则一节主文件_release.yaml、可选的_intro.md以及被content字段引用的扩展条目 markdown 文件。六、_release.yaml 配置详解_release.yaml是稳定版 changelog 的元数据核心支持字段包括draft是否草稿、可选的title、summary、image、youtube以及必有的entries列表。次要条目直接作为 quick entries 写入entries不设content字段只有需要独立 markdown 分节的条目才使用content字段指向同目录下的 markdown 文件。规范给出的完整示例此处补充字段注释可直接复用title: Whats New in 2026.1.0 # 可选本版本标题 summary: Brief overview of the most important additions and fixes # 可选一句话摘要 draft: true # 是否草稿状态 entries: - title: Request debugging # 条目标题 category: feature # feature | fix | improvement | breaking pr: https://github.com/mountain-loop/yaak/pull/123 # 关联 PR 链接 feedback: https://feedback.yaak.app/p/request-debugging # 可选用户反馈链接 content: request-debugging.md # 可选指向同目录扩展 markdown 文件 - title: Fix broken cookie clearing category: fix pr: https://github.com/mountain-loop/yaak/pull/124注意两点约束entries[].content引用的文件名必须真实存在于同一目录category的取值即为解析 Release Bullets一节中规定的四类映射。七、扩展主要条目Major Entries并非所有条目都需要展开。规范要求在上下文足够的前提下挑出 36 个重大条目major items进行扩展做法是为每个大条目创建slugified短横线命名的 markdown 文件例如request-debugging.md在_release.yaml的对应entries中通过content字段引用该文件在动笔前先阅读相关 PR确保扩展内容基于真实实现而非臆测仅当有助于区分大节时才为扩展条目的标题添加 emoji 前缀——普通 quick entries 不需要。八、图片处理changelog 配图遵循能复用就复用没有就占位的原则优先复用 PR 中已有的截图GitHub 私有附件链接需先转换为公开资产链接格式为https://github.com/user-attachments/assets/UUID再上传环境允许时用命令go run cmd/yaakadmin/main.go upload URL上传该命令属于 yaak.app 网站仓库的管理工具若没有真实图片则使用占位图但必须提供真实的 alt 文本与说明文字caption提交到仓库的 changelog 图片统一存放在static/changelog/VERSION/目录下。九、_intro.md 与 Yaak 写作风格_intro.md放在 release 页面顶部是一段简短的总览写作要求是聚焦整个 release 的主要主题major themes而不是逐条复述 entries 中的每个 bullet。Yaak 的 changelog 写作风格规范同样适用于 GitHub release body直接、事实化避免夸大宣传hype说清楚改了什么以及怎么用段落保持短小代码符号、设置项、字面值一律使用反引号backticks粗体bold只用于节内最重要的短语克制使用。十、文件规则与发布前检查清单文件规则File RulesBeta release 不得创建或编辑src/content/changelog/下的任何文件主文件为_release.yaml可选文件为_intro.md扩展条目文件是普通 markdown 文件如request-debugging.mdentries[].content必须匹配同目录下真实存在的 markdown 文件名提交到仓库的 changelog 图片存放于static/changelog/VERSION/。检查清单ChecksBeta release执行gh release view TAG --repo mountain-loop/yaak --json body,tagName,isDraft,isPrerelease核验并确认没有创建任何网站 changelog 文件核验带 feedback 的 bulletfeedback URL 是整条文本的链接目标而不是末尾独立的Feedback:链接。Stable release确保每条有用户影响的源 bullet 都恰好生成一个 changelog entry除非它是[beta-only]、纯依赖或内部维护类当源 release notes 提供 PR 编号时多数条目应包含pr字段确保每个被content引用的文件真实存在如需完整网站核验可运行站点并检查/changelog/VERSION与/rss.xml。十一、仓库中的配套工程背景这套 changelog 规范并非孤立存在它与仓库中的版本管理约定紧密耦合AGENTS.md 记录了 tag 安全规则应用与 CLI 都从v*tag 发布CLI 与应用版本锁定且在每个应用 tag 上向 npm 发布yaakapp/api则使用yaak-api-*独立 tag——因此 changelog 工作流中定位目标 tag前必须先确认用户要处理的是应用/CLI 还是 API 的发布release-generate-release-notes/SKILL.md 作为上游环节负责生成最初的 release notes并规定排除仅触及crates-cli/的 CLI 专属变更CLI 拥有自己的发布流程这与 changelog 解析阶段跳过无用户价值条目的原则相互呼应crates-cli/yaak-cli/skills/use-yaak/SKILL.md 则说明yaakCLI 与桌面应用共享同一本地数据库、yaak auth仅用于向插件注册表发布插件——了解这一点有助于在 release notes 中准确区分应用功能与CLI/插件生态的变更归属避免把插件功能误写入应用 changelog。结语Yaak 的 changelog 体系用一套可执行的技能规范把发版说明这种容易被忽视的环节工程化了通过 tag 形态判定轨道、按用户价值过滤条目、用_release.yaml统一元数据、以检查清单兜底质量。对于希望在多版本并行发布beta 与 stable 共存下保持变更记录准确、可追溯、可读的开源项目维护者而言这套双轨制工作流是一个相当完整的参考范式——尤其是feedback 链接包裹整条文本外部贡献者署名beta 不落网站目录等细节规则直接避免了发布实践中常见的链接失效与信息错位问题。赞分享开发工具接口测试桌面应用【免费下载链接】yaakThe most intuitive desktop API client. Organize and execute REST, GraphQL, WebSockets, Server Sent Events, and gRPC 项目地址https://gitcode.com/GitHub_Trending/ya/yaak点击查看免费下载相关推荐BrewUI项目结构拆解20个SwiftPM模块背后的设计思路BrewUI项目结构拆解20个SwiftPM模块背后的设计思路 BrewUI 是 Homebrew 官方推出的 macOS 图形界面让不熟悉终端的用户桌面应用开发工具Warp 变更日志片段语言规范Towncrier 工作流下的 Changelog 写作与审查实践Warp 变更日志片段语言规范Towncrier 工作流下的 Changelog 写作与审查实践 WarpNVIDIA 开源的 GPU 加速仿真 Pytho高性能计算物理引擎图形学机器人Puter.js 完整指南免 API Key、3 分钟接入 500 AI 模型与云存储Puter.js 完整指南免 API Key、3 分钟接入 500 AI 模型与云存储 Puter.js 把登录认证、AI 对话、云盘和键值数据库打包进一个后端前端云原生上一篇DLSS Swapper终极指南一键优化游戏性能的画质增强神器下一篇用 KubeStellar Console Agent 接管多集群 Kubernetes 运维基于 awesome-copilot 的部署与排障实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
