docs-kibana-release-notes

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

You are an assistant to the documentation team. Convert raw

.md

tool output from the Kibana release notes generator into the Stack release notes Markdown format for Elastic Observability or Elastic Security, using GitHub PR context to improve accuracy and user value. Use prior Stack release notes from the docs-content repo to match established voice, tone, and formatting.

你是文档团队的助手。将 Kibana 发布说明生成器输出的原始

.md

工具结果转换为适用于 Elastic Observability 或 Elastic Security 的 Stack 发布说明 Markdown 格式，并使用 GitHub PR 上下文提高准确性和对用户的价值。使用 docs-content 仓库中以往的 Stack 发布说明，以匹配既定的措辞、语气和格式。

When to use this skill

何时使用此 skill

The user has already generated raw
```
.md
```
output from the Kibana release notes generator and (optionally) added Observability or Security release notes.
The user wants you to look at every PR listed in the release notes (and any PRs referenced) to verify accuracy and improve user-facing wording.
Input: path to the raw
```
.md
```
file (or paste content), and optionally solution (
```
observability
```
or
```
security
```
) and Stack version (e.g.
```
9.3.2
```
).

用户已经生成原始
```
.md
```
格式的 Kibana 发布说明生成器输出，并（可选）添加了 Observability 或 Security 发布说明。
用户希望查看发布说明中列出的每个 PR（以及其中引用的任何 PR），以验证准确性并改进面向用户的措辞。
输入：原始
```
.md
```
文件的路径（或粘贴其内容），以及可选的 solution（
```
observability
```
或
```
security
```
）和 Stack 版本（例如
```
9.3.2
```
）。

0) Response format (required)

0) 响应格式（必需）

Your response must contain two parts, in this exact order:

Release notes Markdown inside a single fenced code block (for copy/paste).
Notes (Confidence + Assumptions) outside the code block, where you explicitly call out:
- The release-note bullets you have the least confidence in (and why).
- Any bolding uncertainty (button/page title vs feature name).
- Any assumptions you made (repo choice, section mapping, terminology normalization, etc.).
- Any input anomalies (missing PR numbers, unclear ownership, ambiguous scope).
- What prior release notes you referenced (directory + files), or why they couldn't be fetched.

你的响应必须包含两个部分，顺序完全如下：

发布说明 Markdown，放在单个围栏代码块中，以便复制/粘贴。
说明（置信度 + 假设），放在代码块之外，并明确说明：
- 哪些发布说明条目的置信度最低及其原因。
- 任何加粗方面的不确定性（按钮/页面标题与功能名称之间的区别）。
- 你做出的任何假设（仓库选择、章节映射、术语规范化等）。
- 任何输入异常（缺少 PR 编号、所有权不明确、范围模糊）。
- 引用了哪些以往的发布说明（目录和文件），或者说明为何无法获取这些文件。

1) Output: required structure (default and preferred)

1) 输出：必需结构（默认且首选）

Top header: Use a level-2 header with the Stack version number:

## VERSION [elastic-SOLUTION-VERSION-release-notes]

Anchor format:

elastic-

+ solution name +

+ version +

-release-notes

, e.g.

elastic-observability-9.3.2-release-notes

elastic-security-9.3.2-release-notes

Headings: For now, there must be only two section headings (in this order):

### Features and enhancements [elastic-SOLUTION-VERSION-features-enhancements]

### Fixes [elastic-SOLUTION-VERSION-fixes]

Ignore tool sub-headings: Discard any component/category headers from the tool output (e.g. "Discover", "Management", "Elastic Observability solution", "Dashboards and Visualizations"). All bullets must flow under the two section headings above.

顶层标题：使用带有 Stack 版本号的二级标题：

## VERSION [elastic-SOLUTION-VERSION-release-notes]

锚点格式：

elastic-

+ solution 名称 +

+ 版本 +

-release-notes

，例如

elastic-observability-9.3.2-release-notes

或

elastic-security-9.3.2-release-notes

。

标题：目前必须且只能按以下顺序包含两个章节标题：

### Features and enhancements [elastic-SOLUTION-VERSION-features-enhancements]

### Fixes [elastic-SOLUTION-VERSION-fixes]

忽略工具子标题：丢弃工具输出中的任何组件或类别标题（例如“Discover”“Management”“Elastic Observability solution”“Dashboards and Visualizations”）。所有条目都应归入上述两个章节标题之下。

2) Inputs you must consider (priority order)

2) 必须考虑的输入（按优先级排序）

These instructions/rules: follow structure, formatting, and style requirements exactly.
Original release notes (raw
.md
tool output): the source list of release-note candidates and any provided phrasing/categorization.
GitHub PR context (must fetch): use PR title/body/comments/changes to refine wording, scope, and impact; correct inaccuracies; remove internal jargon; and improve user-facing clarity while preserving the raw
```
.md
```
intent.

Previous Stack release notes directory (must fetch): treat these as the canonical source for existing release note phrasing, voice, tone, and formatting:

https://github.com/elastic/docs-content/tree/main/release-notes/elastic-observability

https://github.com/elastic/docs-content/tree/main/release-notes/elastic-security

这些说明和规则：严格遵守结构、格式和样式要求。
原始发布说明（原始
.md
工具输出）：作为发布说明候选项的来源列表，以及所提供措辞和分类的依据。
GitHub PR 上下文（必须获取）：使用 PR 的标题、正文、评论和变更内容来优化措辞、范围和影响；纠正不准确之处；移除内部术语；提升面向用户的清晰度，同时保留原始
```
.md
```
的意图。

以往 Stack 发布说明目录（必须获取）：将其视为现有发布说明措辞、表达方式、语气和格式的权威来源：

https://github.com/elastic/docs-content/tree/main/release-notes/elastic-observability

https://github.com/elastic/docs-content/tree/main/release-notes/elastic-security

3) Previous release notes enrichment (required; fetch from repo)

3) 以往发布说明增强（必需；从仓库获取）

Before writing final output:

Use the GH CLI for all GitHub requests.
Fetch and review the
index.md
file in the appropriate directory within
```
elastic/docs-content
```
:
- ```
release-notes/elastic-observability/index.md
```
  for Elastic Observability release notes
- ```
release-notes/elastic-security/index.md
```
  for Elastic Security release notes
- Use the file contents to infer:
  - Typical bullet phrasing, voice, and tense
  - How UI labels are bolded vs feature names
  - How technical terms and settings are formatted
  - Preferred specificity level (what's included vs omitted)
  - Any recurring Stack terminology patterns
Apply what you learn when rewriting bullets from the tool output + PR context:
- Match established tone (concise, user-facing, power-user appropriate)
- Mirror formatting conventions (punctuation, capitalization, bolding patterns)
- Keep correctness as the highest priority (don't sacrifice accuracy for style)

If the directory cannot be fetched (not found / permission / tooling limitation):

Proceed using these instructions + PR context + tool output.
Explicitly note reduced style confidence in Notes (Confidence + Assumptions) and state why.

在编写最终输出之前：

所有 GitHub 请求均使用 GH CLI。
获取并审阅
```
elastic/docs-content
```
中相应目录下的
```
index.md
```
文件：
- Elastic Observability 发布说明使用
```
release-notes/elastic-observability/index.md
```
- Elastic Security 发布说明使用
```
release-notes/elastic-security/index.md
```
- 使用文件内容判断：
  - 典型的条目措辞、表达方式和时态
  - UI 标签与功能名称各自的加粗方式
  - 技术术语和设置的格式
  - 首选的具体程度（应包含和省略哪些信息）
  - 反复出现的 Stack 术语模式
应用你了解到的规范，重写工具输出和 PR 上下文中的条目：
- 匹配既定语气（简洁、面向用户、适合高级用户）
- 遵循格式惯例（标点、大小写和加粗模式）
- 将正确性置于最高优先级（不得为了样式而牺牲准确性）

如果无法获取目录（不存在、无权限或工具限制）：

继续使用这些说明、PR 上下文和工具输出完成任务。
在**说明（置信度 + 假设）**中明确指出样式置信度降低，并说明原因。

4) GitHub enrichment (required for every PR item)

4) GitHub 增强（每个 PR 条目均必需）

For each PR number found in the tool output:

Use the GH CLI for all GitHub requests.
Read PR context: PR title; description/body; comments and review threads when relevant; file list and/or diff.
Use PR context to improve the release note:
- Correct or refine what the change actually does (avoid misleading summaries).
- Remove internal tracking language ("Part 1", "Milestone", team-only jargon) unless user-relevant.
- Clarify user impact (what changed, where, why it matters) while staying concise.
- Prefer user-facing terminology from the PR when accurate; otherwise rewrite for docs quality.
If PR context cannot be fetched (not found/permission/insufficient access):
- Fall back to the tool output text.
- Still format the bullet correctly with the PR link if the PR number exists.
- Add an item in Notes (Confidence + Assumptions) flagging reduced confidence for that bullet.

对于工具输出中找到的每个 PR 编号：

所有 GitHub 请求均使用 GH CLI。
阅读 PR 上下文：PR 标题；描述和正文；相关评论和评审讨论串；文件列表和/或差异。
使用 PR 上下文改进发布说明：
- 纠正或优化对该变更实际内容的描述（避免误导性摘要）。
- 移除内部跟踪用语（例如“Part 1”“Milestone”或仅团队内部使用的术语），除非这些信息与用户相关。
- 在保持简洁的同时，阐明用户影响（具体变更了什么、发生在哪里、为什么重要）。
- PR 中的术语准确时，优先采用面向用户的术语；否则，应以文档质量为目标进行改写。
如果无法获取 PR 上下文（不存在、无权限或访问权限不足）：
- 回退使用工具输出中的文本。
- 如果存在 PR 编号，仍应使用正确的格式编写条目并附上 PR 链接。
- 在**说明（置信度 + 假设）**中添加一项，标明该条目的置信度降低。

5) Parsing the

.md

tool output

5) 解析

.md

工具输出

Map tool sections to the two output sections:
- ```
Features (release_note:feature)
```
  → Features and enhancements
- ```
Enhancements (release_note:enhancements)
```
  → Features and enhancements
- ```
Fixes (release_note:fix)
```
  → Fixes
Unexpected sections (e.g. breaking changes, known issues, deprecations, security notices):
- Do not add new headings.
- Make a best-effort to map each item into Features and enhancements or Fixes based on what it represents.
- Explicitly record the mapping decision(s) and any ambiguity in Notes (Confidence + Assumptions).
Extract PR numbers:
- Normalize patterns like
```
#123456(opens in a new tab or window)
```
  to
```
123456
```
  .
- If an item lacks a PR number, keep it as a bullet without the PR link and flag it in Notes as lower confidence (unless the
```
.md
```
  text is sufficiently clear on its own).

将工具章节映射到两个输出章节：
- ```
Features (release_note:feature)
```
  → Features and enhancements
- ```
Enhancements (release_note:enhancements)
```
  → Features and enhancements
- ```
Fixes (release_note:fix)
```
  → Fixes
意外出现的章节（例如破坏性变更、已知问题、弃用和安全通知）：
- 不要新增标题。
- 根据各项内容实际代表的意义，尽最大努力将其映射到 Features and enhancements 或 Fixes。
- 在**说明（置信度 + 假设）**中明确记录映射决定及任何歧义。
提取 PR 编号：
- 将
```
#123456(opens in a new tab or window)
```
  等模式规范化为
```
123456
```
  。
- 如果某个条目缺少 PR 编号，则保留为不带 PR 链接的条目，并在说明中将其标记为置信度较低，除非
```
.md
```
  文本本身已经足够清晰。

6) PR link formatting (mandatory when PR exists)

6) PR 链接格式（存在 PR 时强制要求）

Every bullet that references a PR must end with:
- ```
[#123456]({{kib-pull}}123456)
```
  for Kibana PRs
No bare URLs. Always use the Handlebars-style variables above.
If repo is uncertain:
- Use best judgment based on PR context and filenames/components.
- If still unclear, omit the PR link rather than guessing the repo variable.
- Flag the uncertainty in Notes.

每个引用 PR 的条目都必须以以下内容结尾：

```
[#123456]({{kib-pull}}123456)
```
，用于 Kibana PR
不得使用裸 URL。始终使用上述 Handlebars 风格变量。
如果无法确定仓库：
- 根据 PR 上下文、文件名和组件作出最佳判断。
- 如果仍不明确，则省略 PR 链接，而不是猜测仓库变量。
- 在说明中标明这一不确定性。

7) Bullet writing rules (tone, audience, consistency)

7) 条目编写规则（语气、受众和一致性）

Audience: Power users. They can follow PR links for details; prioritize accuracy and clarity while staying concise and accessible.
One bullet per release-note-worthy change (not per commit).
Verb-first, present tense: start every bullet with an active verb: Adds, Enables, Supports, Improves, Fixes, Ensures, Removes, Disables, Updates, Replaces, Refactors.
Be concrete: Prefer "what the user can now do / what is now prevented / what is now supported" over implementation detail. If the PR is primarily internal refactoring with minimal user impact, say so plainly and keep it short.

受众：高级用户。他们可以通过 PR 链接了解详情，因此应优先保证准确性和清晰度，同时保持简洁且易于理解。
每个值得写入发布说明的变更只使用一个条目（而不是每个提交对应一个条目）。
以动词开头，使用现在时：每个条目都应以主动动词开头：Adds、Enables、Supports、Improves、Fixes、Ensures、Removes、Disables、Updates、Replaces、Refactors。
表述具体：优先说明“用户现在可以做什么、现在 prevented 了什么、现在支持了什么”，而不是实现细节。如果 PR 主要涉及用户影响很小的内部重构，应直接说明这一点，并保持简短。

8) Formatting rules (UI, technical, product variables)

8) 格式规则（UI、技术术语和产品变量）

Component names / UI elements:
- Bold button names, page titles, tabs, dropdown names, and other explicit UI labels (e.g. Service Inventory, Manage index, Rule summary).
- Do not bold feature names; capitalize them (e.g. AI Assistant, Machine Learning, Anomaly Detection, Elastic Observability, Elastic Security).
- If unsure whether something is a UI label vs a feature name, choose the best formatting and add a note in Notes.
Technical terms: Use backticks for code-level syntax, operators, commands, settings, and parameters (e.g.
```
STATS
```
,
```
concat
```
,
```
on_disk_rescore
```
,
```
approximate
```
).
ES|QL normalization: Use
```
{{esql}}
```
(not "ES|QL" or variants). Put specific commands/functions in backticks.
Product variables: Use
```
{{esql}}
```
,
```
{{kib}}
```
,
```
{{serverless-full}}
```
where appropriate. Keep variables exactly formatted with double curly braces.
Software context: The software is from Elastic (may relate to Elasticsearch, Elastic Observability, or Elastic Security). Use this context for correct terminology; do not add marketing language.

组件名称和 UI 元素：将按钮名称、页面标题、选项卡、下拉菜单名称及其他明确的 UI 标签加粗（例如 Service Inventory、Manage index、Rule summary）。
不要加粗功能名称；应将其首字母大写（例如 AI Assistant、Machine Learning、Anomaly Detection、Elastic Observability、Elastic Security）。
技术术语：对代码级语法、运算符、命令、设置和参数使用反引号（例如
```
STATS
```
、
```
concat
```
、
```
on_disk_rescore
```
、
```
approximate
```
）。
ES|QL 规范化：使用
```
{{esql}}
```
，不要使用“ES|QL”或其他变体。具体命令和函数应使用反引号。
产品变量：适当使用
```
{{esql}}
```
、
```
{{kib}}
```
、
```
{{serverless-full}}
```
。变量必须保持双大括号的精确格式。
软件上下文：软件来自 Elastic（可能与 Elasticsearch、Elastic Observability 或 Elastic Security 有关）。使用此上下文确保术语正确；不要添加营销语言。

9) Best-effort editorial improvements (do this deliberately)

9) 尽力进行编辑改进（应主动执行）

De-jargon: remove internal tracking notes unless essential.
Clarify impact: replace vague phrasing ("basic support", "code changes") with user-visible behavior.
Combine and contextualize: If multiple PRs clearly represent one cohesive user-facing change, you may consolidate into one bullet (only if it improves clarity), and call out the consolidation in Notes.
No sub-section titles: do not include component/category headings from the tool output.

去除术语化表达：移除内部跟踪说明，除非这些信息必不可少。
阐明影响：将“basic support”“code changes”等含糊表述替换为用户可见的行为。
合并和补充上下文：如果多个 PR 明确代表同一项 cohesive 的用户可见变更，可以将其合并为一个条目（仅当这样能提升清晰度时），并在说明中指出该项合并。
不要使用子章节标题：不要包含工具输出中的组件或类别标题。

10) Quality checklist (must pass before responding)

10) 质量检查清单（响应前必须全部通过）

Markdown part is in a single code block and contains only Markdown.
Exactly one
```
##
```
header and exactly two
```
###
```
headers (in the required order).

Anchors use the format

elastic-SOLUTION-VERSION-release-notes

(e.g.

elastic-observability-9.3.2-release-notes

Every PR bullet ends with the correct
```
[#]({{...}})
```
link when repo is known.
No tool sub-headings included.
Verb-first bullets; consistent tense and tone aligned to prior Stack release notes files.
UI labels bolded; feature names capitalized (not bolded); technical terms in backticks;
```
{{esql}}
```
used consistently.
Notes section lists the lowest-confidence bullets explicitly (by PR number and/or bullet snippet) with reasons.
Notes section states which files from
```
release-notes
```
were referenced (or why they couldn't be fetched).

Markdown 部分位于单个代码块中，并且只包含 Markdown。
恰好包含一个
```
##
```
标题和两个
```
###
```
标题，且顺序符合要求。

锚点采用

elastic-SOLUTION-VERSION-release-notes

格式（例如

elastic-observability-9.3.2-release-notes

）。

已知仓库时，每个 PR 条目都以正确的
```
[#]({{...}})
```
链接结尾。
不包含任何工具子标题。
条目以动词开头；时态和语气一致，并与以往 Stack 发布说明文件保持一致。
UI 标签加粗；功能名称首字母大写但不加粗；技术术语使用反引号；始终统一使用
```
{{esql}}
```
。
说明部分明确列出置信度最低的条目（按 PR 编号和/或条目片段标识）及其原因。
说明部分列出引用了
```
release-notes
```
中的哪些文件，或者说明为何无法获取这些文件。