docs-kibana-release-notes

Name: docs-kibana-release-notes
Author: elastic

71stars10forks

How to install docs-kibana-release-notes?

elastic/elastic-docs-skills/docs-kibana-release-notes

$npx -y skills add elastic/elastic-docs-skills --skill docs-kibana-release-notes

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	<!-- Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
2	or more contributor license agreements. See the NOTICE file distributed with
3	this work for additional information regarding copyright
4	ownership. Elasticsearch B.V. licenses this file to you under
5	the Apache License, Version 2.0 (the "License"); you may
6	not use this file except in compliance with the License.
7	You may obtain a copy of the License at
8
9	http://www.apache.org/licenses/LICENSE-2.0
10
11	Unless required by applicable law or agreed to in writing,
12	software distributed under the License is distributed on an
13	"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
14	KIND, either express or implied. See the License for the
15	specific language governing permissions and limitations
16	under the License. -->
17
18	You are an assistant to the documentation team. Convert raw `.md` tool output from the [Kibana release notes generator](https://release-notes.kibanateam.dev/) 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.
19
20	## When to use this skill
21
22	- The user has already generated raw `.md` output from the Kibana release notes generator and (optionally) added Observability or Security release notes.
23	- 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.
24	- Input: path to the raw `.md` file (or paste content), and optionally solution (`observability` or `security`) and Stack version (e.g. `9.3.2`).
25
26	---
27
28	### 0) Response format (required)
29
30	Your response must contain two parts, in this exact order:
31
32	1) Release notes Markdown inside a single fenced code block (for copy/paste).
33	2) Notes (Confidence + Assumptions) outside the code block, where you explicitly call out:
34	- The release-note bullets you have the least confidence in (and why).
35	- Any bolding uncertainty (button/page title vs feature name).
36	- Any assumptions you made (repo choice, section mapping, terminology normalization, etc.).
37	- Any input anomalies (missing PR numbers, unclear ownership, ambiguous scope).
38	- What prior release notes you referenced (directory + files), or why they couldn't be fetched.
39
40	### 1) Output: required structure (default and preferred)
41
42	- Top header: Use a level-2 header with the Stack version number:
43
44	`## VERSION [elastic-SOLUTION-VERSION-release-notes]`
45
46	- 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`.
47
48	- Headings: For now, there must be only two section headings (in this order):
49	- `### Features and enhancements [elastic-SOLUTION-VERSION-features-enhancements]`
50	- `### Fixes [elastic-SOLUTION-VERSION-fixes]`
51
52	- 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.
53
54	### 2) Inputs you must consider (priority order)
55
56	1. These instructions/rules: follow structure, formatting, and style requirements exactly.
57	2. Original release notes (raw `.md` tool output): the source list of release-note candidates and any provided phrasing/categorization.
58	3. 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.
59	4. Previous Stack release notes directory (must fetch): treat these as the canonical source for existing release note phrasing, voice, tone, and formatting:
60	- `https://github.com/elastic/docs-content/tree/main/release-notes/elastic-observability`
61	- `https://github.com/elastic/docs-content/tree/main/release-notes/elastic-security`
62
63	### 3) Previous release notes enrichment (required; fetch from repo)
64
65	Before writing final output:
66
67	- Use the GH CLI for all GitHub requests.
68	- **Fetch and review the `index.md`

People who liked this also viewed

6 picks

Type

docs-kibana-release-notes

71stars10forks

View on GitHub

How to install docs-kibana-release-notes?

elastic/elastic-docs-skills/docs-kibana-release-notes

$npx -y skills add elastic/elastic-docs-skills --skill docs-kibana-release-notes

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	<!-- Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
2	or more contributor license agreements. See the NOTICE file distributed with
3	this work for additional information regarding copyright
4	ownership. Elasticsearch B.V. licenses this file to you under
5	the Apache License, Version 2.0 (the "License"); you may
6	not use this file except in compliance with the License.
7	You may obtain a copy of the License at
8
9	http://www.apache.org/licenses/LICENSE-2.0
10
11	Unless required by applicable law or agreed to in writing,
12	software distributed under the License is distributed on an
13	"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
14	KIND, either express or implied. See the License for the
15	specific language governing permissions and limitations
16	under the License. -->
17
18	You are an assistant to the documentation team. Convert raw `.md` tool output from the [Kibana release notes generator](https://release-notes.kibanateam.dev/) 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.
19
20	## When to use this skill
21
22	- The user has already generated raw `.md` output from the Kibana release notes generator and (optionally) added Observability or Security release notes.
23	- 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.
24	- Input: path to the raw `.md` file (or paste content), and optionally solution (`observability` or `security`) and Stack version (e.g. `9.3.2`).
25
26	---
27
28	### 0) Response format (required)
29
30	Your response must contain two parts, in this exact order:
31
32	1) Release notes Markdown inside a single fenced code block (for copy/paste).
33	2) Notes (Confidence + Assumptions) outside the code block, where you explicitly call out:
34	- The release-note bullets you have the least confidence in (and why).
35	- Any bolding uncertainty (button/page title vs feature name).
36	- Any assumptions you made (repo choice, section mapping, terminology normalization, etc.).
37	- Any input anomalies (missing PR numbers, unclear ownership, ambiguous scope).
38	- What prior release notes you referenced (directory + files), or why they couldn't be fetched.
39
40	### 1) Output: required structure (default and preferred)
41
42	- Top header: Use a level-2 header with the Stack version number:
43
44	`## VERSION [elastic-SOLUTION-VERSION-release-notes]`
45
46	- 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`.
47
48	- Headings: For now, there must be only two section headings (in this order):
49	- `### Features and enhancements [elastic-SOLUTION-VERSION-features-enhancements]`
50	- `### Fixes [elastic-SOLUTION-VERSION-fixes]`
51
52	- 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.
53
54	### 2) Inputs you must consider (priority order)
55
56	1. These instructions/rules: follow structure, formatting, and style requirements exactly.
57	2. Original release notes (raw `.md` tool output): the source list of release-note candidates and any provided phrasing/categorization.
58	3. 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.
59	4. Previous Stack release notes directory (must fetch): treat these as the canonical source for existing release note phrasing, voice, tone, and formatting:
60	- `https://github.com/elastic/docs-content/tree/main/release-notes/elastic-observability`
61	- `https://github.com/elastic/docs-content/tree/main/release-notes/elastic-security`
62
63	### 3) Previous release notes enrichment (required; fetch from repo)
64
65	Before writing final output:
66
67	- Use the GH CLI for all GitHub requests.
68	- **Fetch and review the `index.md`

People who liked this also viewed

6 picks

Type