From 475d38aa99a3873d3e2110e89c7626ccfafaad02 Mon Sep 17 00:00:00 2001 From: Florent Le Borgne Date: Fri, 8 May 2026 11:22:09 +0200 Subject: [PATCH 1/3] applies-to-tagging: add generate-from-intent mode and cumulative-docs rules MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Two related additions to make this skill the canonical home for both applies_to syntax *and* the cumulative-docs decisions that surround it (preserve vs replace, append vs replace lifecycle, when to delete a removed feature's page). 1) Generate-from-intent mode The skill currently only validates existing tags or fixes them in place. Callers who need to generate the right tag from a structured change description (feature, version, lifecycle, dimension, products) — for example, the docs-quest-scanner skill when drafting a docsGap entry from a PR — have no clean entry point. Adds a second mode with a five-step flow: extract change description → apply preservation rules → pick the lightest format → generate syntax → output with rationale. 2) Cumulative documentation rules Captures the "do users on previous versions still need the old information?" question and its consequences: - Versioned products (stack): append the new lifecycle, keep the old - Unversioned products (serverless): replace the old state - Removals from versioned products: keep content + add `removed` - Lightest-format preference order: tagged paragraph/admonition → tagged list items → applies-switch tabs (last resort) These rules already live (informally) inside the docs-quest-scanner skill. Lifting them here puts them next to the syntax they govern. Changes: - SKILL.md: adds Modes section, Cumulative-documentation-rules section (between Common patterns and Task execution), Generate-from-intent execution section. Existing validation rules and syntax reference unchanged. - evals.json: 4 new evals (ids 6–9) covering simple generation (stack+serverless), multi-lifecycle generation (preview→GA), default value preservation, and removal handling. - Skill version bumped 1.1.0 → 1.2.0 (MINOR — new capabilities, no breaking change). - Plugin version bumped 1.0.3 → 1.0.4 per validate-skills CI. Motivation: docs-quest-scanner currently inlines both a long applies_to syntax cheatsheet and the cumulative-docs decision rules. Lifting these upstream lets the orchestrator skill delegate cleanly and keeps one canonical version of the rules. --- .claude-plugin/plugin.json | 4 +- skills/authoring/applies-to-tagging/SKILL.md | 131 +++++++++++++++++- .../applies-to-tagging/evals/evals.json | 49 +++++++ 3 files changed, 176 insertions(+), 8 deletions(-) diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json index 8af92ff..ae85350 100644 --- a/.claude-plugin/plugin.json +++ b/.claude-plugin/plugin.json @@ -1,7 +1,7 @@ { "name": "elastic-docs-skills", - "description": "Claude Code skills for Elastic documentation workflows — authoring, review, changelogs, and publishing.", - "version": "1.0.3", + "description": "Claude Code skills for Elastic documentation workflows \u2014 authoring, review, changelogs, and publishing.", + "version": "1.0.4", "author": { "name": "Elastic" }, diff --git a/skills/authoring/applies-to-tagging/SKILL.md b/skills/authoring/applies-to-tagging/SKILL.md index 5763ca9..4d5ddd1 100644 --- a/skills/authoring/applies-to-tagging/SKILL.md +++ b/skills/authoring/applies-to-tagging/SKILL.md @@ -1,8 +1,8 @@ --- name: docs-applies-to-tagging -version: 1.1.0 -description: Validate and generate applies_to tags in Elastic documentation. Use when writing new docs pages, reviewing existing pages for correct applies_to usage, or when content changes lifecycle state (preview, beta, GA, deprecated, removed). -argument-hint: +version: 1.2.0 +description: Validate and generate applies_to tags in Elastic documentation, including for cumulative docs across versions and deployment types. Use when writing new docs pages, reviewing existing pages for correct applies_to usage, deciding whether to preserve or replace existing version-scoped content, or when content changes lifecycle state (preview, beta, GA, deprecated, removed). +argument-hint: context: fork allowed-tools: Read, Grep, Glob, Edit, CallMcpTool, WebFetch sources: @@ -29,7 +29,23 @@ KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> -You are an applies_to tagging specialist for Elastic documentation. Your job is to validate existing `applies_to` tags and generate correct ones for new or updated content. +You are an applies_to tagging specialist for Elastic documentation. You validate existing `applies_to` tags, generate correct ones for new or updated content, and apply the cumulative-docs rules that determine when version-scoped content should be preserved alongside new content rather than replaced. + +## Modes + +This skill operates in two modes depending on input: + +- **Validate** — input is a file path, directory, or pasted frontmatter/markdown. Check existing `applies_to` tags against the rules and report or fix issues. Follow the **Task execution** flow. +- **Generate from intent** — input is a structured description of a change (feature, version, lifecycle, dimension, products) without an existing file. Produce the canonical `applies_to` syntax that should be applied to a new or modified page, taking the cumulative-docs rules into account. Follow the **Generate-from-intent execution** flow. + +Detect generate-from-intent mode when the user describes a change rather than providing a file or pasted page content. Cues: + +- "I'm adding feature X to 9.5 in stack only — generate the applies_to." +- "What's the right tag for a serverless-only GA feature in observability?" +- "A feature went from preview in 9.4 to GA in 9.5. What should I write?" +- Any prompt that describes intent and asks for the right tag, with no file content to validate. + +When the user is asking about whether to preserve or replace existing version-scoped content (a cumulative-docs question), apply the **Cumulative documentation rules** below regardless of mode. ## What applies_to is @@ -254,13 +270,116 @@ serverless: unavailable **Density** {applies_to}`stack: ga 9.1+` ``` +## Cumulative documentation rules + +Elastic docs (V3, elastic.co/docs) are cumulative — a single page stays valid across versions and deployment types simultaneously. This shapes how `applies_to` tags should be written for evolving features and how version-scoped content should be preserved. + +### Preserve old content when possible + +Before suggesting any change involving version-scoped content, ask: + +1. **Do users on previous versions still need the old information?** Usually yes — docs serve all currently-supported versions. Prefer adding tagged new content alongside the old, not replacing it. +2. **What is the simplest format that works?** Choose the lightest annotation that scopes correctly (see below). + +### Lifecycle changes + +- **Versioned products (stack):** append the new state, keep the old. A feature that was `preview` at 9.0 and `ga` at 9.2 becomes `stack: ga 9.2+, preview =9.0`. Older readers still see the preview note; newer readers see the GA badge. +- **Unversioned products (serverless):** replace the old state entirely. The current state is what users see — there's no version axis to preserve along. + +### Removals + +- **GA or deprecated feature removed from a versioned product** → keep the content; add `stack: removed 9.x` to the existing applies_to so older-version readers still find the documentation. +- **Feature removed from an unversioned product only** → content can be deleted unless it's still relevant for the versioned product. +- **Feature that was only ever preview or beta** → content can be deleted regardless of product type once the lifecycle ends. + +### Lightest-format preference + +When tagging a section or paragraph, prefer the lightest form that scopes correctly. In order of preference: + +1. **Tagged paragraph or admonition** — additive change that doesn't disrupt existing content. Add `{applies_to}` at the start of a new paragraph, or use a `:::{note}` / `:::{dropdown}` with `:applies_to:`. +2. **Tagged list items or definition terms** — when only some items in a list (or terms in a definition list) differ. Add an inline `{applies_to}` at the start or end of the affected item. +3. **`applies-switch` tabs** — only when content truly diverges and can't be merged into a single flow (for example, a stack-only step that has no serverless equivalent, with materially different code). + +Avoid heavier forms (entire-section blocks, switch tabs) unless the lighter ones can't carry the meaning. + +### Version display reminders + +- Never write versions in prose adjacent to badges — they contradict the "Planned" badge text before release. +- Versions display as Major.Minor in badges regardless of patch numbers in source. +- Each version statement covers the latest patch of that minor. + +## Generate-from-intent execution + +Use this flow when the user describes a change and asks for the correct `applies_to` syntax to apply, without providing an existing file. + +### Step 1: Extract the change description + +From the user's prompt, pull the following. Ask **one** focused clarifying question if any are missing and material: + +- **Dimension** — stack/serverless, deployment, or product. If both stack and serverless apply, use stack/serverless. Use only one dimension at page level. +- **Lifecycle per key** — preview, beta, ga, deprecated, removed, or unavailable. +- **Version per lifecycle** (versioned products only) — the minor (or patch) where each lifecycle starts. +- **Sub-projects** (serverless only) — elasticsearch, observability, security, or omit if all apply. +- **Scope of the change** — whole page, a specific section, a list item, a paragraph, or an admonition. Determines which level of annotation to generate. +- **Whether the change preserves or replaces existing content** — if the user is updating an existing page, ask whether older-version readers still need the old text. Apply the **Cumulative documentation rules** above. + +### Step 2: Decide preservation vs. replacement + +Apply the cumulative-docs rules: + +- If the page already documents an older state (e.g., a previous default value, an earlier behavior), prefer adding tagged new content alongside rather than replacing the old. +- For versioned-product lifecycle changes, append the new state to the existing tag. +- For unversioned-product lifecycle changes, replace the old state. +- For removals from versioned products, keep the content and add `removed`. + +### Step 3: Pick the lightest format that scopes correctly + +Use the **Lightest-format preference** order under Cumulative documentation rules. Whole-page changes go in frontmatter; section changes use a fenced `{applies_to}` block; smaller scopes use inline annotations. + +### Step 4: Generate the canonical syntax + +Produce the right form based on scope: + +- **Whole page** — YAML frontmatter: + ```yaml + --- + applies_to: + stack: ga 9.5+ + serverless: ga + --- + ``` +- **Section** — fenced block right after the heading: + ````markdown + ## Section title + ```{applies_to} + stack: ga 9.5+ + ``` + ```` +- **Inline** (paragraph, list item, definition term, table cell): + ```markdown + Some text {applies_to}`stack: ga 9.5+` more text. + ``` +- **Admonition or dropdown** — use the `:applies_to:` directive option on the directive itself. + +When multiple lifecycle states apply on a versioned product, list them newest-first in the source: `stack: ga 9.5+, preview =9.4`. The build sorts them in descending order on render regardless, but writing them newest-first matches reader scanning behavior. + +### Step 5: Output + +Return: + +- The generated `applies_to` syntax in the right format for the scope. +- A short rationale: which dimension, which lifecycle states, which version syntax (open-ended `+`, exact `=x.x`, or range `x.x-y.y`), and which scope level. +- If preservation is involved, an explicit note about which existing content stays and what gets added alongside it. + ## Task execution +Use this flow for **validate** mode (file path, directory, or pasted page content). + 1. **Glob** for all `.md` files in scope 2. **Read** each file and check for correct frontmatter `applies_to` -3. **Validate** existing tags against the rules above +3. **Validate** existing tags against the **Validation rules** above 4. **Report** issues found (missing tags, invalid syntax, wrong placement) -5. If asked to fix or generate tags, use **Edit** to apply corrections +5. If asked to fix or generate tags, use **Edit** to apply corrections; for generation from a change description without a file, use the **Generate-from-intent execution** flow 6. Summarize all changes made or issues found ## Reference diff --git a/skills/authoring/applies-to-tagging/evals/evals.json b/skills/authoring/applies-to-tagging/evals/evals.json index b2d05f1..3e5a4a9 100644 --- a/skills/authoring/applies-to-tagging/evals/evals.json +++ b/skills/authoring/applies-to-tagging/evals/evals.json @@ -55,6 +55,55 @@ "Flags the range '9.3-9.1' because the start version is greater than the end version", "Does NOT flag 'eck: ga 3.0+' as invalid because open-ended version syntax is valid" ] + }, + { + "id": 6, + "prompt": "I'm adding a new search-relevance evaluation feature to 9.5 in stack and to serverless elasticsearch. Generate the applies_to for the page.", + "expected_output": "Page-level applies_to YAML frontmatter using the stack/serverless dimension with stack: ga 9.5+ and the elasticsearch serverless subkey set to ga", + "expectations": [ + "Returns a page-level applies_to in YAML frontmatter form", + "Uses stack: ga 9.5+ to express open-ended availability from 9.5 onward", + "Uses the serverless.elasticsearch subkey set to ga (not bare serverless: ga, since the user specified the elasticsearch sub-project)", + "Does not mix stack/serverless with deployment or product dimensions", + "Includes a brief rationale explaining the version syntax choice (open-ended + for unbounded availability)" + ] + }, + { + "id": 7, + "prompt": "Generate applies_to for a stack-only feature. It was preview in 9.4 and went GA in 9.5. We don't ship it on serverless.", + "expected_output": "Page-level applies_to with stack listing both lifecycle states newest-first: ga 9.5+, preview =9.4. No serverless entry. Brief rationale covering the use of =9.4 for an exact version and 9.5+ for the current open-ended GA.", + "expectations": [ + "Lists both lifecycle states under stack: ga 9.5+, preview =9.4", + "Orders the lifecycles newest-first in the source (ga before preview)", + "Uses =9.4 for the exact preview version (not bare 9.4)", + "Uses 9.5+ for the current open-ended GA", + "Does NOT include a serverless entry, since the feature isn't shipped there", + "Notes that older readers still see the preview badge — appending preserves history" + ] + }, + { + "id": 8, + "prompt": "A configuration option's default value changed in 9.4. The page currently describes the old default as a single paragraph. Should I replace that paragraph with the new default, or is there a better approach for cumulative docs?", + "expected_output": "Recommendation to preserve the original paragraph and add a new tagged paragraph (or admonition) describing the new default, citing the cumulative-docs rule that older readers still need the old information", + "expectations": [ + "Recommends preserving the existing description rather than replacing it", + "Suggests adding a tagged paragraph or admonition for the new default, scoped with stack: ga 9.4+ (or equivalent)", + "Cites the cumulative-docs principle that docs serve all currently-supported versions", + "Mentions the lightest-format preference: tagged paragraph or admonition first, before considering applies-switch tabs", + "Does NOT recommend deleting the original paragraph" + ] + }, + { + "id": 9, + "prompt": "A feature was GA in stack until 9.3 and is removed in 9.4. We don't have it on serverless. Should I delete the page?", + "expected_output": "Recommendation to keep the content and add stack: removed 9.4 to the existing applies_to so older-version readers still find the documentation, since the feature was GA on a versioned product", + "expectations": [ + "Recommends keeping the page rather than deleting it", + "Suggests adding stack: removed 9.4 to the existing applies_to (appended, not replacing)", + "Explains that older-version readers (9.3 and earlier) still need the documentation", + "Distinguishes this from the case where a feature was only ever preview or beta (which can be deleted)", + "Does NOT recommend deleting the page" + ] } ] } From b3580981e35ec0a1fbe0af541a826eac5ba9a9a8 Mon Sep 17 00:00:00 2001 From: Florent Le Borgne Date: Fri, 8 May 2026 11:48:52 +0200 Subject: [PATCH 2/3] applies-to-tagging: align placement framing with docs-content guidance MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Replaces the "Lightest-format preference" framing with the analytical principle from docs-content/CLAUDE.md: it's not about lightness, it's about scope. The new framing has three pieces: 1. Decide whether applies_to is needed at all - Don't tag when the edit is valid for all versions (rewording, typo fixes, restructuring) - Don't tag when a parent page or section already has the correct applies_to - Don't tag when a small inline pattern carries the meaning (most commonly a renamed UI element written as "Select **New name** (or **Old name** in earlier versions)") - Don't tag GA features in unversioned products where the page-level lifecycle already covers it - Tag when content is genuinely version- or deployment-scoped, isn't covered by a parent tag, and isn't better expressed inline 2. Place applies_to where the change applies - Section level (fenced block after heading) when the change is relevant to a section - Page level (frontmatter) when the whole page is scoped - Inline only at start of list item / end of definition term / inside table cell — never mid-sentence or floating between sentences in a paragraph - Restructure prose into an admonition or dropdown with `:applies_to:` when it doesn't fit those inline positions - applies-switch tabs only when content truly diverges 3. Scope must be unambiguous - Reader must be able to tell exactly what the tag covers from heading + block position alone Also drops the misframed "Lightest-format preference" subsection from Cumulative documentation rules and updates the generate-from-intent Step 3 wording to reference the corrected placement rules. Adds eval id 10: a renamed-UI-element prompt that should NOT result in an applies_to tag, but in the inline parenthetical pattern. This exercises the gating-rule carve-out that's easy to get wrong. --- skills/authoring/applies-to-tagging/SKILL.md | 68 +++++++++++-------- .../applies-to-tagging/evals/evals.json | 12 ++++ 2 files changed, 50 insertions(+), 30 deletions(-) diff --git a/skills/authoring/applies-to-tagging/SKILL.md b/skills/authoring/applies-to-tagging/SKILL.md index 4d5ddd1..9b83653 100644 --- a/skills/authoring/applies-to-tagging/SKILL.md +++ b/skills/authoring/applies-to-tagging/SKILL.md @@ -189,23 +189,29 @@ When validating, check for these errors: ## Guidelines for tagging -**DO tag when:** -- Functionality is added in a specific release -- A feature changes lifecycle state -- Availability differs across products or deployment types - -**DO NOT tag when:** -- Fixing typos, formatting, or information architecture (no feature change) -- The section's applicability is already established by a parent tag -- Adding GA features to unversioned products where the page-level lifecycle already covers the content - -**Badge placement:** -- Page level: frontmatter only -- Headings: section annotation on the line after the heading, never inline -- Lists: badge at beginning of list items -- Definition lists: badge at end of the term (inline annotation on same line as term) when badge applies to the entire item; follow element-specific placement when badge applies only to part of the definition -- Tables: badge at end of first column (whole row) or end of cell (single cell) -- Use `applies-switch` tabs when code blocks or workflows differ entirely between contexts: +### Decide whether `applies_to` is needed + +**Don't tag when:** + +- The edit is valid for all versions (rewording, typo fixes, restructuring) — it's not version-scoped at all. +- A parent page or parent section already has the correct `applies_to` — repeating it is redundant. +- The change *is* version-scoped but a small inline pattern carries the meaning without `applies_to`. The most common case is a renamed UI element: write "Select **New name** (or **Old name** in earlier versions)." rather than splitting the step with `applies_to`. Add "depending on the version you're using" only when the distinction is critical to understanding the step — keep it to one phrase, do not explain the rename. +- Adding GA features to unversioned products where the page-level lifecycle already covers the content. + +**Tag when:** + +- Content is genuinely version- or deployment-scoped, isn't already covered by a parent tag, and isn't better expressed inline. +- Functionality is added in a specific release, lifecycle state changes (preview → GA, deprecated, removed), or availability differs across products or deployment types. + +### Place `applies_to` where the change applies + +Pick the form that matches what the change is scoped to: + +- **Section level** — fenced `{applies_to}` block immediately after the heading, when the change is relevant to a section. +- **Page level** — YAML frontmatter, when the change scopes the whole page. +- **Inline** — only at start of a list item, end of a definition term, or inside a table cell. Never mid-sentence in running prose, and never floating between sentences in a paragraph (scope becomes ambiguous). +- **Admonition or dropdown** — use the `:applies_to:` directive option when prose needs version scoping but doesn't fit any of the inline positions above. Restructure the prose into the admonition rather than inventing a new inline placement. +- **`applies-switch` tabs** — only when content truly diverges between contexts (a stack-only step that has no serverless equivalent, with materially different code): ````markdown ::::{applies-switch} :::{applies-item} stack: ga @@ -217,6 +223,10 @@ Serverless-specific content here. :::: ```` +### Scope must be unambiguous + +Before committing an `applies_to` block, verify that any reader — human or automated tooling — can tell exactly what content the tag covers from the heading and block position alone. If there is any doubt, restructure the section. + ## Common patterns **Both stack and serverless:** @@ -279,7 +289,7 @@ Elastic docs (V3, elastic.co/docs) are cumulative — a single page stays valid Before suggesting any change involving version-scoped content, ask: 1. **Do users on previous versions still need the old information?** Usually yes — docs serve all currently-supported versions. Prefer adding tagged new content alongside the old, not replacing it. -2. **What is the simplest format that works?** Choose the lightest annotation that scopes correctly (see below). +2. **Is the change actually scoped to a specific version or deployment?** If the new content is valid for all versions, no `applies_to` is needed at all. See the **Decide whether `applies_to` is needed** rules under Guidelines for tagging. ### Lifecycle changes @@ -292,16 +302,6 @@ Before suggesting any change involving version-scoped content, ask: - **Feature removed from an unversioned product only** → content can be deleted unless it's still relevant for the versioned product. - **Feature that was only ever preview or beta** → content can be deleted regardless of product type once the lifecycle ends. -### Lightest-format preference - -When tagging a section or paragraph, prefer the lightest form that scopes correctly. In order of preference: - -1. **Tagged paragraph or admonition** — additive change that doesn't disrupt existing content. Add `{applies_to}` at the start of a new paragraph, or use a `:::{note}` / `:::{dropdown}` with `:applies_to:`. -2. **Tagged list items or definition terms** — when only some items in a list (or terms in a definition list) differ. Add an inline `{applies_to}` at the start or end of the affected item. -3. **`applies-switch` tabs** — only when content truly diverges and can't be merged into a single flow (for example, a stack-only step that has no serverless equivalent, with materially different code). - -Avoid heavier forms (entire-section blocks, switch tabs) unless the lighter ones can't carry the meaning. - ### Version display reminders - Never write versions in prose adjacent to badges — they contradict the "Planned" badge text before release. @@ -332,9 +332,17 @@ Apply the cumulative-docs rules: - For unversioned-product lifecycle changes, replace the old state. - For removals from versioned products, keep the content and add `removed`. -### Step 3: Pick the lightest format that scopes correctly +### Step 3: Pick the form that matches what the change is scoped to + +Use the **Place `applies_to` where the change applies** rules under Guidelines for tagging: + +- Whole page → frontmatter. +- A section → fenced `{applies_to}` block after the heading. +- A list item, definition term, or table cell → inline at the allowed position. +- Prose that doesn't fit those inline positions → restructure into an admonition with `:applies_to:`. +- Content that truly diverges between contexts → `applies-switch` tabs. -Use the **Lightest-format preference** order under Cumulative documentation rules. Whole-page changes go in frontmatter; section changes use a fenced `{applies_to}` block; smaller scopes use inline annotations. +Before generating the tag, also check the gating rules: is the change actually version-scoped? Is a parent tag already covering it? Could a small inline pattern (e.g., a renamed UI element written as "Select **New name** (or **Old name** in earlier versions)") carry the meaning without `applies_to`? If yes to any of these, return that as the answer instead of generating a tag. ### Step 4: Generate the canonical syntax diff --git a/skills/authoring/applies-to-tagging/evals/evals.json b/skills/authoring/applies-to-tagging/evals/evals.json index 3e5a4a9..91bec6d 100644 --- a/skills/authoring/applies-to-tagging/evals/evals.json +++ b/skills/authoring/applies-to-tagging/evals/evals.json @@ -104,6 +104,18 @@ "Distinguishes this from the case where a feature was only ever preview or beta (which can be deleted)", "Does NOT recommend deleting the page" ] + }, + { + "id": 10, + "prompt": "A button in Stack Management was renamed from 'Save' to 'Save and apply' in 9.4. The procedure step currently says 'Click **Save** to confirm.' I need to update it to cover both versions. Should I split the step with applies_to, or is there a better approach?", + "expected_output": "Recommendation to NOT use applies_to here — handle the rename inline with the parenthetical pattern, since the version distinction is not load-bearing for the procedure", + "expectations": [ + "Recommends NOT adding applies_to for this change", + "Suggests the inline rename pattern: 'Click **Save and apply** (or **Save** in earlier versions) to confirm.' (or equivalent wording)", + "Mentions that some version-scoped changes are best expressed inline rather than via applies_to", + "Does NOT generate a fenced applies_to block that splits the step by version", + "Does NOT recommend an applies-switch tab for a simple label rename" + ] } ] } From 8ab684ed8604ef402a923d386cf0fac3e0b03dac Mon Sep 17 00:00:00 2001 From: Fabrizio Ferri Benedetti Date: Thu, 21 May 2026 11:16:09 +0200 Subject: [PATCH 3/3] Fix missing closing --- in fix-changelog SKILL.md frontmatter Co-Authored-By: Claude Sonnet 4.6 --- skills/changelogs/fix-changelog/SKILL.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/skills/changelogs/fix-changelog/SKILL.md b/skills/changelogs/fix-changelog/SKILL.md index 5235499..f93597f 100644 --- a/skills/changelogs/fix-changelog/SKILL.md +++ b/skills/changelogs/fix-changelog/SKILL.md @@ -10,8 +10,7 @@ sources: - https://www.elastic.co/docs/contribute-docs/content-types/changelogs - https://elastic.github.io/docs-builder/syntax/links/ - https://elastic.github.io/docs-builder/syntax/code/ - - +--- You are a changelog writing assistant for Elastic documentation. You suggest improved text for changelog fields and help draft content for new changelogs. You do not create files — file creation is always done via `docs-builder changelog add`.