| name | docs-kibana-release-notes |
| version | 1.0.1 |
| description | Convert raw Kibana release notes tool output into Stack release notes (Elastic Observability or Elastic Security) using GitHub PR context and prior release notes. Use when drafting or editing Stack 9.x release notes from the Kibana release notes generator output. |
| argument-hint | <path-to-raw-rn.md> [observability|security] [version] |
| disable-model-invocation | true |
| context | fork |
| allowed-tools | Read, Grep, Bash(gh *) |
| sources | ["https://release-notes.kibanateam.dev/","https://github.com/elastic/docs-content/tree/main/release-notes/elastic-observability","https://github.com/elastic/docs-content/tree/main/release-notes/elastic-security"] |
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.
When to use this 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).
0) Response format (required)
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.
1) Output: required structure (default and preferred)
-
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 or elastic-security-9.3.2-release-notes.
-
Headings: For now, there must be (in this order):
