✨ Features

✨ Features

Short Feature Name in Title Case

A 1–3 sentence paragraph describing what the user gets, why it matters, and any notable behaviour. Write in product-marketing voice, not commit-message voice.

• Optional nested bullets for sub-capabilities or callouts
• Keep them user-facing — what the user can now do

Second Major Feature

Another descriptive paragraph. Each major feature gets its own #### subsection.

⬆️ Enhancements

• One-line description of an improvement to an existing capability
• Another improvement, written as a clean sentence (no commit prefix, no ticket ID)

🐞 Bug fixes

• Plain-English description of what was broken and is now fixed
• Another bug fix

🛡️ Security

• Upgraded to to mitigate CVE-XXXX-NNNNN. Brief impact note.
• Other security-relevant change

格式规则逐条列出：

- 板块标题用三个 `#`（`###`），随后是「emoji + **两个空格** + 标签」——与已发布的 v1.2.0 release 完全一致。例外：🛡️ Security 用单个空格（同样对齐 v1.2.0）。
- Features 用四个 `#`（`####`），且功能名在标题内**加粗**：`#### **Feature Name**`。
- 每个功能必须是一段真正的段落而非列表——面向最终用户而非工程师写作。
- Enhancements、Bug fixes、Security 用简单列表项：不嵌套星号、不带工作项 ID、不带 PR 编号。
- **任何板块都不得出现工作项 ID（`[WEB-XXXX]`）或 PR 编号（`(#NNNN)`）**——该格式面向用户。
- **不要加 `# Release vX.Y.Z` 标题**：版本由 GitHub release tag 承载，正文直接从第一个 `### ✨ Features` 开始。
- **不要插图**：截图由用户在草稿完成后手动添加，除非用户主动要求，否则不预留图片位置。
- 空板块整体删除；板块标题与首个列表项之间、板块与板块之间各留一个空行。

### 步骤 7：写回 PR 描述

```bash
gh pr edit <PR_NUM> --body "$(cat <<'EOF'
<release notes markdown>
EOF
)"

关键细节：HEREDOC 分隔符必须用单引号 'EOF'，否则发布说明中的反引号和美元符号会被 shell 提前解释而破坏正文。

四、端到端速查（Quick Reference）

文档最后把整个流程压缩成一段可直接复制的脚本骨架：

PR=2498
gh pr view $PR --json commits --jq '.commits[] | .messageHeadline + "\n---\n" + .messageBody + "\n==="' > /tmp/commits.txt
# 读取 /tmp/commits.txt，过滤噪音，归类到四个板块，起草说明
gh pr edit $PR --body "$(cat <<'EOF'
### ✨  Features

#### **...**

...

### ⬆️  Enhancements

- ...

### 🐞  Bug fixes

- ...

### 🛡️ Security

- ...
EOF
)"