release-brief

# release-brief 当需要把「一个已关闭的 issue」和「一段已���并的 diff」变成对外可读的发布摘要时，按下面的固定步骤执行，不要临场发挥顺序。 ## 触发条件 - 输入里同时存在一个 issue 标识（例如 `LP-42`）和一段 diff 或变更文件列表。 - 目标是产出发布摘要，而不是继续写代码。 ## 固定步骤 1. 读 issue：提取标题、问题描述与验收标准。 2. 读 diff：列出被改动的文件与关键函数。 3. 归类改动：区分是缺陷修复、功能新增还是纯重构。 4. 评估风险：指出回归面与需要人工确认的点。 5. 写验证步骤：给出可复制的复现或回归命令。 ## 输出契约 生成的发布摘要必须是一个 JSON 对象，且包含以下字段，缺一不可： - `issue`：issue 标识字符串。 - `summary`：一句话说明这次发布做了什么。 - `change_type`：`fix` / `feature` / `refactor` 之一。 - `risk`：风险说明，至少一句。 - `verification`：字符串数组，至少一条可执行验证命令。 ## 反例 - 只写 `summary` 而不给 `verification`：契约检查会失败。 - 把顺序打乱、先写风险再猜 issue 内容：违反固定步骤，产出不可复用。