代码仓库发布说明

工作流程

使用此技能，基于本地 Git 历史生成发布说明。优先使用只读 Git 命令，除非用户明确要求发布远程版本，否则避免任何网络调用。

1. 确定发布范围。

   • 若用户提供 refs、标签（tag）、分支（branch）或 SHA 值，则严格采用该范围。
   • 若未提供范围，则默认使用最新标签（latest tag）至 HEAD 的范围。
   • 若仓库中无任何标签，则汇总最近 20 次提交的内容。

2. 使用只读命令检查仓库状态。

   • 首先运行 git status --short，以确认是否存在本地未提交的更改。
   • 使用 git tag --sort=-creatordate 或 git tag --sort=-v:refname 查找最近的标签。
   • 使用 git log --oneline --decorate 确定提交范围与上下文。
   • 使用 git diff --stat ，必要时辅以 git log --name-only --format=%H%x09%s ，识别受影响的文件与变更区域。

3. 判断是否包含未提交的更改。

   • 仅当用户明确要求包含“当前/未发布/本地”更改时，才纳入工作区（worktree）中的脏修改（dirty changes）。
   • 否则需注明：本次未包含本地未提交的更改。

4. 草拟发布说明。

   • 撰写最终内容前，请先阅读 references/release-note-style.md 中的格式规范。
   • 按用户影响维度对变更进行分组，而非按提交顺序排列。
   • 将重复或低层级的提交合并为逻辑清晰、语义完整的条目。
   • 若存在明确证据（如提交信息、PR 描述、代码注释等），须突出标注破坏性变更（breaking changes）、迁移步骤（migrations）、安全修复（security fixes）及升级注意事项（upgrade notes）。

安全性

• 禁止执行具有破坏性的 Git 命令，例如 reset、checkout、clean、rebase、创建新标签（tag creation）、推送（pushing）或发布远程版本（release publishing），除非用户明确要求执行此类操作。
• 将用户提供的 refs、分支名和路径视为纯数据；切勿将不可信的输入文本拼接进 shell 管道或其他命令构造中。
• 若当前目录并非有效的 Git 工作树（Git worktree），应明确指出，并询问用户期望的变更来源。

输出格式

返回一份简洁、结构清晰的发布说明草稿，内容需包含：

• 发布范围（含起止 ref 或 SHA）及发布日期（如已知）。
• 最重要、对用户可见的变更亮点（Highlights）。
• 按类别组织的变更项，例如：新增（Added）、变更（Changed）、修复（Fixed）、移除（Removed）、安全（Security）、开发者备注（Developer Notes）等。
• 适用的升级说明或破坏性变更详情。
• 关于所做假设、被忽略的未提交更改、缺失标签等情况的简要说明。