writing-releases

用途：依据 commit 与 PR 数据，按 Medusa 既有风格生成 GitHub 发布说明草稿。\n\n主要能力与约束：必须包含 Full Changelog 链接，且固定为最后一行，格式为 Full Changelog: vPREV...vNEW。不设顶级 Breaking Changes 章节，破坏性变更嵌入对应 Highlight 子节并标 🚧 Breaking change。每条 Features/Bugs/Chores 条目须含作者链接与 PR 链接。Highlights 仅收录重要变更，常规新增归入 Features/Bugs。除破坏性变更 Highlight 上的 🚧 外不使用 emoji。若 Highlight 要求开发者安装包、执行命令或改配置，需附精确命令的围栏代码块。\n\n使用方式：写作前至少加载一个参考文件——格式与条目对应 reference/format.md，判断是否写 Highlights 与识别破坏性变更对应 reference/release-types.md，撰写 Highlights 对应 reference/highlights.md。章节顺序（仅保留有内容的章节）为 Highlights、Features、Bugs、Documentation、Chores、Other Changes、New Contributors，最后接 Full Changelog 链接。发布类型判定：仅常规修复/杂项、无用户影响时采用 Minimal，无 Highlights；单一重要变更为发布主因时用 Single Highlight；多个重要特性或修复时用 Multi-Highlight；.changeset/ 中任何 minor changeset 的 PR 应在其 Highlight 加 🚧。\n\n适用场景：为 Medusa 各版本整理发布说明。限制与常见错误：顶部不加标题或 # 级标题；不新增顶级 Breaking Changes 章节；不把常规修复或小功能放进 Highlights；不遗漏末尾链接；条目不可缺作者或 PR 链接；不以 PR 标题原文充当 Highlight 标题；不把所有 feat: commit 都当 Highlight；不在别处用 emoji；有开发者操作步骤的 Highlight 必须带代码块。以上来自公开资料，未提供其他功能、收费或平台信息。