docs-serverless-changelog

Name: docs-serverless-changelog
Author: elastic

71stars10forks

How to install docs-serverless-changelog?

elastic/elastic-docs-skills/docs-serverless-changelog

$npx -y skills add elastic/elastic-docs-skills --skill docs-serverless-changelog

Installs into the current project.

Summary

Convert raw Markdown tool output into Elastic Cloud Serverless changelog format using GitHub PR context and prior Serverless release notes. Use when drafting or editing Serverless changelog entries from 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 Markdown tool output into the Serverless Changelog Markdown format, using GitHub context to improve accuracy and user value. Use prior Serverless 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 raw `.md` output from a release notes generator that needs to be converted to Serverless changelog format.
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).
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 date and anchor:
43
44	`## Month Day, Year [serverless-changelog-MMDDYYYY]`
45
46	- Date format: `Month Day, Year` (for example, `March 23, 2026`)
47	- Anchor format: `serverless-changelog-` + MMDDYYYY (zero-padded), for example `serverless-changelog-03232026`
48
49	- Headings: There must be only two section headings (in this order):
50	- `### Features and enhancements [serverless-changelog-MMDDYYYY-features-enhancements]`
51	- `### Fixes [serverless-changelog-MMDDYYYY-fixes]`
52
53	- Ignore tool sub-headings: Discard any component/category headers from the tool output (for example, "Discover", "Management", "Elastic Observability solution", "Dashboards and Visualizations"). All bullets must flow under the two section headings above.
54
55	### 2) Inputs you must consider (priority order)
56
57	1. These instructions/rules: follow structure, formatting, and style requirements exactly.
58	2. Original release notes (raw `.md` tool output): this is the source list of release-note candidates and any provided phrasing/categorization.
59	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.
60	4. Previous Serverless release notes directory (must fetch): treat this directory as the canonical source for existing release note phrasing, voice, tone, and formatting conventions:
61	- `https://github.com/elastic/docs-content/tree/main/release-notes/elastic-cloud-serverless`
62
63	### 3) Previous release notes enrichment (required; use entire directory)
64
65	Before writing final output:
66
67	- Use the GH CLI for all GitHub requests.
68	- Fetch and review all files in the directory `release-notes/elastic-cloud-serverless` in `elastic/docs-content`:
69	- Use the directory contents to infer:
70	- Typical bullet phrasing, voice, and tense
71	- How UI labels are bolded vs feature names
72	- How technical terms and settings are formatted
73	- Preferred specificity level (what's included vs omitted)
74	- Any recurring Serverless terminology patterns
75	- Apply what you learn when rewriting bullets from the tool output + PR context:
76	-

People who liked this also viewed

6 picks

Type

docs-serverless-changelog

71stars10forks

View on GitHub

How to install docs-serverless-changelog?

elastic/elastic-docs-skills/docs-serverless-changelog

$npx -y skills add elastic/elastic-docs-skills --skill docs-serverless-changelog

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 Markdown tool output into the Serverless Changelog Markdown format, using GitHub context to improve accuracy and user value. Use prior Serverless 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 raw `.md` output from a release notes generator that needs to be converted to Serverless changelog format.
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).
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 date and anchor:
43
44	`## Month Day, Year [serverless-changelog-MMDDYYYY]`
45
46	- Date format: `Month Day, Year` (for example, `March 23, 2026`)
47	- Anchor format: `serverless-changelog-` + MMDDYYYY (zero-padded), for example `serverless-changelog-03232026`
48
49	- Headings: There must be only two section headings (in this order):
50	- `### Features and enhancements [serverless-changelog-MMDDYYYY-features-enhancements]`
51	- `### Fixes [serverless-changelog-MMDDYYYY-fixes]`
52
53	- Ignore tool sub-headings: Discard any component/category headers from the tool output (for example, "Discover", "Management", "Elastic Observability solution", "Dashboards and Visualizations"). All bullets must flow under the two section headings above.
54
55	### 2) Inputs you must consider (priority order)
56
57	1. These instructions/rules: follow structure, formatting, and style requirements exactly.
58	2. Original release notes (raw `.md` tool output): this is the source list of release-note candidates and any provided phrasing/categorization.
59	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.
60	4. Previous Serverless release notes directory (must fetch): treat this directory as the canonical source for existing release note phrasing, voice, tone, and formatting conventions:
61	- `https://github.com/elastic/docs-content/tree/main/release-notes/elastic-cloud-serverless`
62
63	### 3) Previous release notes enrichment (required; use entire directory)
64
65	Before writing final output:
66
67	- Use the GH CLI for all GitHub requests.
68	- Fetch and review all files in the directory `release-notes/elastic-cloud-serverless` in `elastic/docs-content`:
69	- Use the directory contents to infer:
70	- Typical bullet phrasing, voice, and tense
71	- How UI labels are bolded vs feature names
72	- How technical terms and settings are formatted
73	- Preferred specificity level (what's included vs omitted)
74	- Any recurring Serverless terminology patterns
75	- Apply what you learn when rewriting bullets from the tool output + PR context:
76	-

People who liked this also viewed

6 picks

Type