`, `| ` tags with tab indentation.
-
-## Code Snippets in KB Articles
-
-Always embed code samples directly in the article using fenced code blocks. Do **not** reference external code files with `{{source=...}}` includes — that syntax is reserved for main documentation articles that pull from maintained sample projects. KB articles are self-contained; all code must be inline so the article remains portable and readable without external dependencies.
-
-## Pre-Return Self-Check (KB Articles)
-
-Before returning the file, verify:
-
-1. YAML front matter opens with `---` and closes with `---`; `res_type: kb` is present.
-2. `type` is set to `how-to` or `troubleshooting` for non-security articles; omitted for security articles.
-3. `slug` is kebab-case, unique, and meaningful for the article.
-4. **No `#` (H1) heading** exists in the article body.
-5. `## Environment` section with HTML table is present for how-to and troubleshooting articles.
-6. `## Description` section is present and states the user's goal or problem.
-7. `## Solution` section is present and provides actionable guidance.
-8. `## See Also` is the last section when present; links use the `slug:` form for internal targets.
-9. All internal links use `slug:` form; API links use `/api/...`; no raw `docs.telerik.com/reporting` URLs.
-10. Images reference `images/...` relative paths; alt text is descriptive.
-11. No emojis anywhere in the article.
-12. Language tags present on every fenced code block.
-13. US English spelling throughout.
-14. No main-article-only keys (`position`, `reportingArea`) in front matter.
-15. Code samples are embedded inline in fenced code blocks; no `{{source=...}}` references.
-
----
-
-# Part 3 — Shared Conventions
-
-The following conventions apply to **both** main documentation and KB articles.
-
-## Heading Hierarchy
-
-- `#` — used exactly once in main articles (the title); **never used** in KB articles.
-- `##` — major sections.
-- `###` — sub-sections within a major section.
-- `####` — reserved for figure captions or code-sample sub-headers (including the tabstrip pattern); avoid for regular prose.
-
-## Liquid / Jekyll Extensions
-
-### Alert Blockquotes
-
-Place at the start of a line; one kind per blockquote; may span multiple sentences on the same line.
-
-```markdown
-> tip Use the [Telerik Reporting MCP Server](slug:ai-mcp-server) when authoring reports with AI assistants.
-
-> note The `PageNumberingStyle` property controls page-number formatting.
-
-> important Conflicting `BorderStyle` and `BorderWidth` values produce unexpected results.
-
-> warning Always review AI-generated code before applying it to production reports.
-
-> caution The `Page Settings` button is disabled when viewing a Report Book.
-```
-
-### Fenced Code Blocks
-
-Use language tags. Common tags: `CSharp`, `VB.NET`, `HTML`, `XML`, `JSON`, `TypeScript`, `JavaScript`, `SQL`, `XAML`, `CSS`, `Bash`, `TEXT`.
-
-````markdown
-```CSharp
-using Telerik.Reporting;
-var report = new Report();
-```
-````
-
-### Multi-Language Code Tabstrip
-
-Use when showing the same sample in C# and VB.NET. Each language needs its own `#### __[...]__` header and a `{{region Name}} ... {{endregion}}` pair.
-
-```markdown
-#### **[C#]**
-
-{{region MyFeature_CSharp}}
-public void Configure()
-{
-// C# sample
-}
-{{endregion}}
-
-#### **[VB.NET]**
-
-{{region MyFeature_VB}}
-Public Sub Configure()
-' VB.NET sample
-End Sub
-{{endregion}}
-```
-
-## Link Conventions
-
-- **Internal docs links**: `[link text](slug:)`. Never link to `https://docs.telerik.com/reporting/...` for an internal target.
-- **API reference links**: `[Member](/api/Telerik.Reporting.TypeName#Telerik_Reporting_TypeName_Member)` or `[Type](/api/Telerik.Reporting.TypeName)`.
- - **Inside alert blockquotes (`> note`, `> tip`, `> important`, `> warning`, `> caution`), do not wrap the link text of an `/api/...` link in backticks.** The renderer fails to resolve such links inside blockquotes and the link silently breaks. Inside a note, write `[RadialGaugeNeedle](/api/telerik.reporting.radialgaugeneedle)`, **never** `` [`RadialGaugeNeedle`](/api/telerik.reporting.radialgaugeneedle) ``. Outside blockquotes (running prose, lists, tables) the backticked form is allowed and is the prevailing house style.
- - When revising or improving existing articles, apply the same rule: if you encounter an `/api/...` link whose label is wrapped in backticks **inside an alert blockquote**, remove the backticks; leave such links untouched everywhere else.
-- **External links**: standard markdown with full `https://` URL.
-- Every link must have descriptive text; no "click here", no bare URLs.
-- If a target slug is unknown, insert `TODO(author): confirm slug` next to the link instead of guessing.
-
-## Images
-
-```markdown
-
-
-```
-
-- Main articles: store under an `images/` subfolder sibling to the article.
-- KB articles: store under `knowledge-base/images/` (referenced as `images/FileName.png`).
-- Alt text describes the content for accessibility; it is not the file name.
-- PNG preferred; use relative paths, never absolute URLs.
-- If an image has not been produced yet, reference the intended filename and add `TODO(author): add image` above the line.
-
-## Text Formatting
-
-- `**Bold**` — UI labels, menu paths, button names, window titles (e.g. **File > New Project**, **Create**).
-- Backticks — property names, method names, types, CLI commands, file names (e.g. `CanGrow`, `InitializeComponent()`, `appsettings.json`).
-- Italics — sparingly, for emphasis only.
-- US English (color, organize, behavior).
-- Product name: "Telerik Reporting" in running text; "Progress® Telerik® Reporting" only in the KB Environment table and formal/legal contexts.
-
-## Voice & Tone
-
-- Second person, present tense, imperative for steps ("Click **Create**.", "Select the **TextBox** item.").
-- Concise; short paragraphs (2-4 sentences).
-- Professional and accessible; avoid slang and emojis entirely.
-- KB `## Description` sections may use the user's perspective ("I need to...", "How can I...") to mirror support ticket language. All other sections use standard documentation voice.
-- Preferred phrasing:
- - "To achieve this, ..."
- - "For more information, refer to ..."
- - "As a result, ..."
- - "This article explains how to ..."
-
-## Do NOT
-
-- Do not mix main-article and KB front matter keys in the same article.
-- Do not edit or read from `_`-prefixed directories.
-- Do not modify existing articles' YAML front matter.
-- Do not invent API members, property names, or slugs — flag with `TODO(author):` instead.
-- Do not use emojis in documentation output.
-- Do not produce multiple articles in a single session unless explicitly requested.
-
-## Required Skill — Progress DevTools Style Guide
-
-Always load the [progress-style-guide](../skills/progress-style-guide/SKILL.md) skill before drafting or revising any article. It encodes the Progress DevTools Style Guide rules (tone and voice, active voice, imperative mood, title capitalization, list parallelism, metadata, captions, prepositions, element formatting, screenshots, tables, notes, cross-references) that every article must satisfy.
-
-When the skill conflicts with this agent file, the agent file wins for repository-specific mechanics (slug conventions, `page_title` instead of `meta_title`, allowed front-matter keys, Liquid tag syntax, KB HTML Environment table, no H1 heading in KB articles). The skill wins for all writing conventions (grammar, tone, capitalization, list rules, modal verbs, contractions, captions, screenshots).
-
-Run the skill's **Pre-Publish Self-Check** in addition to the appropriate Pre-Return Self-Check above.
-
-## Reference Exemplars
-
-Before drafting, open and skim the relevant files to calibrate tone, structure, and front matter.
-
-### Main Article Exemplars
-
-- [getting-started/first-steps-designing.md](../../getting-started/first-steps-designing.md) — tutorial with numbered steps.
-- [report-items/textbox.md](../../report-items/textbox.md) — reference article with multiple feature sections.
-- [designing-reports/overview.md](../../designing-reports/overview.md) — folder-entry overview article.
-- [designing-reports/design-considerations.md](../../designing-reports/design-considerations.md) — article with alert blockquotes.
-
-### KB Article Exemplars
-
-- [knowledge-base/change-row-color-based-on-value.md](../../knowledge-base/change-row-color-based-on-value.md) — how-to article with conditional formatting steps.
-- [knowledge-base/cannot-access-the-reporting-rest-service.md](../../knowledge-base/cannot-access-the-reporting-rest-service.md) — troubleshooting article with error message and cause analysis.
-- [knowledge-base/command-injection-cve-2024-7840.md](../../knowledge-base/command-injection-cve-2024-7840.md) — security/CVE advisory article.
-- [knowledge-base/rendering-markdown-in-telerik-reporting-templates.md](../../knowledge-base/rendering-markdown-in-telerik-reporting-templates.md) — how-to article with code samples and See Also section.
-
-## Output Contract
-
-At the end of the session, deliver:
-
-1. A single new `.md` file written to disk at the correct path that passes the appropriate Pre-Return Self-Check.
-2. A short chat summary containing:
- - The file path.
- - The final `slug`.
- - Any `TODO(author):` markers that require human follow-up (missing slugs, pending images, unverified API members).
diff --git a/.github/skills/docs-build-toolkit/SKILL.md b/.github/skills/docs-build-toolkit/SKILL.md
deleted file mode 100644
index f3099ec79..000000000
--- a/.github/skills/docs-build-toolkit/SKILL.md
+++ /dev/null
@@ -1,290 +0,0 @@
----
-name: docs-build-toolkit
-description: "Build and serve the Telerik Reporting documentation site locally. Covers dev builds, production builds, metadata generation, and troubleshooting. Use when: docs build, dev build, production build, serve docs, docfx metadata, API reference, clean cache, docs-builder."
----
-
-# Docs Build Toolkit
-
-Procedures for building and serving the Telerik Reporting documentation site locally using docs-builder.
-
-## Repository Layout
-
-The following repos must be cloned as siblings:
-
-```
-/
-├── reporting/ # Product repo (needed for code snippets & API metadata)
-├── reporting-docs/ # Documentation content (this repo)
-└── docs-builder/ # Gatsby-based build engine
-```
-
-Default assumed layout — all repos are siblings in the same parent directory. All paths below are **relative to reporting-docs** (this repo):
-
-- **docs-builder**: `../docs-builder`
-- **reporting**: `../reporting`
-
-## Prerequisites
-
-Before any build, verify:
-
-1. **docs-builder** repo is cloned and has node modules installed. If not:
- ```
- cd ../docs-builder
- npm ci
- ```
-2. For production builds: **docfx** is installed (`dotnet tool install -g docfx`).
-3. For production builds: Reporting assemblies (DLLs) exist in `_assetsApi/Bin/`. See [Downloading Assemblies](#downloading-assemblies-for-metadata).
-
----
-
-## Dev Build (No Metadata Required)
-
-A dev build starts Gatsby in development mode with hot reload. No API reference metadata is needed.
-
-### Steps
-
-1. Open a terminal in the **reporting-docs** directory.
-2. Navigate to the docs-builder directory:
- ```
- cd ../docs-builder
- ```
-3. Run the develop command:
- ```
- npm run develop --docsPath=../reporting-docs
- ```
-4. The site will be available at **http://localhost:8000**.
-
-### Notes
-
-- Changes to markdown files in reporting-docs are reflected immediately (hot reload).
-- The site will NOT have API Reference pages — expect `/api/` link errors in the output. This is normal.
-- If content renders correctly in dev mode, it will look the same in production.
-- To stop the server, press `Ctrl+C` in the terminal.
-
----
-
-## Production Build (Requires Metadata)
-
-A production build generates the full site including API Reference. It requires docfx metadata.
-
-> **Metadata reuse:** Before generating metadata, check if `_assetsApi/metadata/` already exists and contains `.yml` files. If it does, **skip metadata generation and reuse it**. Only regenerate when the user explicitly asks to download new assemblies or regenerate metadata.
-
-### Downloading Assemblies for Metadata
-
-Assemblies are downloaded from a GitHub release in the `telerik/reporting` repo using the `gh` CLI.
-
-1. Ensure `gh` is installed and authenticated (`gh auth status`).
-2. Download the assets zip from a specific release tag:
- ```
- gh release download --repo telerik/reporting --pattern "Telerik_Reporting_*_Assets.zip" --dir _assetsApi
- ```
- If no tag is specified, use the latest release:
- ```
- gh release download --repo telerik/reporting --pattern "Telerik_Reporting_*_Assets.zip" --dir _assetsApi
- ```
-3. Extract the zip and keep only the `Bin` folder:
- ```powershell
- Expand-Archive -Path _assetsApi/Telerik_Reporting_*_Assets.zip -DestinationPath _assetsApi/_temp_extract -Force
- Move-Item _assetsApi/_temp_extract/Bin _assetsApi/Bin -Force
- Remove-Item _assetsApi/_temp_extract -Recurse -Force
- ```
-4. Remove `.pdb` files and the downloaded zip:
- ```powershell
- Remove-Item -Force _assetsApi/Bin/*.pdb -ErrorAction SilentlyContinue
- Remove-Item -Force _assetsApi/Telerik_Reporting_*_Assets.zip
- ```
-
-### Step 1 — Generate API Metadata
-
-> Skip this step if `_assetsApi/metadata/` already exists and the user did not ask to regenerate.
-
-1. Ensure Reporting assemblies (DLLs) are in `_assetsApi/Bin/`.
- - If not present, follow [Downloading Assemblies](#downloading-assemblies-for-metadata) above.
-2. Navigate to the `_assetsApi` directory:
- ```
- cd _assetsApi
- ```
-3. (Optional) To include code snippets, verify `codeSourceBasePath` in `docfx.json` points to the reporting repo. When running from `_assetsApi`, it should be `../../reporting` or an absolute path.
-4. Run docfx to generate metadata:
- ```
- docfx metadata
- ```
- This creates a `metadata/` folder with `.yml` files.
-5. (Optional) Run the VB snippet fixer:
- ```powershell
- .\fix-vb-snippets.ps1 -MetadataPath ".\metadata" -BinPath ".\Bin" -SnippetBasePath "../../reporting"
- ```
-
-Expected structure after metadata generation:
-
-```
-_assetsApi/
-├── Bin/ # Reporting DLLs
-├── metadata/ # Generated YML files
-├── docfx.json
-└── filterConfig.yml
-```
-
-### Step 2 — Run the Production Build
-
-1. Navigate to docs-builder:
- ```
- cd ../docs-builder
- ```
- (or `cd ../../docs-builder` if you're still in `_assetsApi`)
-2. Run the build:
- ```
- npm run build --docsPath=../reporting-docs --docFxFilesPath=../reporting-docs/_assetsApi/metadata
- ```
-3. Serve the built site:
- ```
- npm run serve
- ```
-4. The site is available at **http://localhost:9000/products/reporting/documentation/introduction**.
-
-Alternative — use `dev-build` which builds AND serves in one step:
-
-```
-npm run dev-build --docsPath=../reporting-docs --docFxFilesPath=../reporting-docs/_assetsApi/metadata
-```
-
----
-
-## Clean Cache
-
-If the build behaves unexpectedly or you get stale data:
-
-```
-cd ../docs-builder
-npx clean
-```
-
-Then re-run the desired build command.
-
----
-
-## Troubleshooting
-
-### Common Build Errors
-
-| Error | Cause | Fix |
-| ------------------------------- | --------------------------------------------- | ---------------------------------------------------------------------------------------- |
-| Incorrect slug errors | Wrong `slug` or `previous_url` in frontmatter | Fix the referenced markdown file |
-| `/api/` link errors in dev mode | No metadata loaded | Expected in dev builds — ignore |
-| `docfx metadata` fails | Missing DLLs in Bin | Download assemblies — see [Downloading Assemblies](#downloading-assemblies-for-metadata) |
-| Build hangs or OOM | Large site, insufficient memory | docs-builder sets `--max-old-space-size=8192` automatically |
-
-### Tips
-
-- Use double curly braces only for Liquid syntax (version variables like `{{ suiteversion }}`).
-- Escape literal double curly braces: `\{\{ text \}\}`.
-- Use relative paths when referencing images.
-- If many slug errors appear, fix and rebuild iteratively — not all errors show in the first build.
-
----
-
-## CLI Reference
-
-All commands are run from the **docs-builder** directory.
-
-| Command | Purpose |
-| ----------------------------------------------------------------------------- | ----------------------------------------- |
-| `npm run develop --docsPath=../reporting-docs` | Dev server with hot reload (port 8000) |
-| `npm run build --docsPath=../reporting-docs --docFxFilesPath=` | Production static build |
-| `npm run dev-build --docsPath=../reporting-docs` | Build + serve locally (port 9000) |
-| `npm run serve` | Serve a previously built site (port 9000) |
-| `npx clean` | Clean Gatsby cache |
-
-### CLI Parameters
-
-| Parameter | Required | Description |
-| ------------------ | -------- | ---------------------------------------------- |
-| `--docsPath` | Yes | Path to the reporting-docs repo |
-| `--docFxFilesPath` | No | Path to API metadata `.yml` files |
-| `--configFile` | No | Config file name (default: `docs-builder.yml`) |
-| `--pathPrefix` | No | Override URL path prefix |
-| `--outputPath` | No | Change output folder |
-
----
-
-## PDF Generation
-
-Generate a PDF of the entire documentation site. This requires a **production build** first (the PDF is generated from the built static site).
-
-### Overview
-
-The PDF pipeline has three stages:
-
-1. **Build** — production build of the site using the default `docs-builder.yml` config
-2. **Export** — Puppeteer converts each page to an individual PDF
-3. **Merge** — individual PDFs are combined into a single file with cover page, bookmarks, page numbers, and fixed internal links
-
-### Step 1 — Build the Site for PDF
-
-The PDF is generated from the production build output. Use the default config file (`docs-builder.yml`).
-
-```
-cd ../docs-builder
-npm run dev-build --docsPath=../reporting-docs --docFxFilesPath=../reporting-docs/_assetsApi/metadata
-```
-
-> If metadata does not exist in `_assetsApi/metadata/`, follow the [metadata generation steps](#step-1--generate-api-metadata) first. Alternatively, for a PDF without API reference, omit `--docFxFilesPath`.
-
-Wait for the build to complete. The built site will be in `docs-builder/public/`.
-
-After the build finishes, **stop the server** (Ctrl+C or kill the terminal) — the PDF generation starts its own server.
-
-### Step 2 — Export Pages to Individual PDFs
-
-This uses Puppeteer to render each page and export it as a PDF. The tool starts its own Express server on port 4300.
-
-**Prerequisites:** The PDF tool expects a `main.js` file at the docs-builder root to start its server. If it doesn't exist, create it:
-
-```javascript
-// main.js (at docs-builder root)
-import { createServer } from "./server/server.js";
-createServer({ port: process.env.PORT || 4300, publicFolder: "./public" });
-```
-
-On a local machine, run with a single agent:
-
-```
-cd ../docs-builder
-npx pdf-generate --serverPath=. --agentIndex=0 --maxAgents=1
-```
-
-This reads `public/pdf-toc.json` (generated during the build), starts a local server on port 4300, and exports each page to `pdf-out/`.
-
-> This step takes a long time (processes all ~1400+ documentation pages). For faster execution, you can parallelize with multiple terminal sessions using different `agentIndex` values (0 to maxAgents-1).
-
-### Step 3 — Merge PDFs into Final Document
-
-After all pages are exported, merge them into a single PDF:
-
-```
-cd ../docs-builder
-npx pdf-merge --serverPath=. --pdfsPath=./pdf-out --productName="Telerik Reporting" --productVersion=""
-```
-
-Replace `` with the product version string (e.g., `2026 Q1`). If the user doesn't specify a version, read it from the `suiteversion` liquid variable in `docs-builder.yml`.
-
-The final PDF is output to: `docs-builder/pdf-out/Telerik_Reporting_.pdf`
-
-The merge step:
-
-- Adds a cover page using `pdf-cover.png`
-- Adds footer images and page numbers
-- Generates PDF bookmarks from the TOC
-- Fixes internal links to point within the PDF
-
-### PDF CLI Parameters
-
-| Parameter | Required | Description |
-| ------------------ | -------- | ----------------------------------------------- |
-| `--serverPath` | Yes | Path to the docs-builder root (e.g., `.`) |
-| `--agentIndex` | No | Agent index for parallel execution (default: 0) |
-| `--maxAgents` | No | Total parallel agents (default: 1) |
-| `--pdfsPath` | Yes\* | Path to exported PDFs (merge step only) |
-| `--productName` | Yes\* | Product name for cover page (merge step only) |
-| `--productVersion` | Yes\* | Version for cover page (merge step only) |
-| `--maxPages` | No | Max pages to include, 0 = all (merge step only) |
diff --git a/.github/skills/progress-style-guide/SKILL.md b/.github/skills/progress-style-guide/SKILL.md
deleted file mode 100644
index 605eb313e..000000000
--- a/.github/skills/progress-style-guide/SKILL.md
+++ /dev/null
@@ -1,269 +0,0 @@
----
-name: progress-style-guide
-description: Progress DevTools Style Guide rules for Telerik/Kendo UI end-user documentation. Load when authoring, reviewing, or editing markdown documentation articles to enforce tone and voice, grammar, titles and headings, lists, tables, notes, cross-references, metadata, captions, screenshots, and formatting conventions. Source — https://www.telerik.com/documentation/style-guide/introduction.
----
-
-# Progress DevTools Style Guide
-
-Condensed, enforceable rules for Progress DevTools (Telerik Reporting, Kendo UI, etc.) end-user documentation. Apply every rule below when writing or editing markdown articles. When this skill conflicts with the Microsoft Style Guide, follow this skill. When this skill is silent, fall back to the [Microsoft Style Guide](https://learn.microsoft.com/en-us/style-guide).
-
-Canonical source: https://www.telerik.com/documentation/style-guide/introduction (cheat sheet: https://www.telerik.com/documentation/style-guide/cheat-sheet).
-
-## Tone and Voice
-
-### Basic things to avoid
-- Do not denigrate or insult any group of people.
-- Do not use jokes at the expense of the users.
-- Do not use "simply", "It's that simple", or "It's easy".
-- Do not use "let's …" constructions.
-- Do not use "please", "please note", or "at this time".
-- Do not use third-person singular gendered pronouns ("he", "she"). Use "they" instead.
-- Do not use metaphors, slang, jargon, humor, sarcasm, colloquialisms, idioms, emoticons, or emojis.
-- Do not use Latin abbreviations such as "e.g." or "i.e." — write "for example" or "that is".
-- Do not use culture-specific references (holidays, currencies, phone/address formats).
-- Do not use qualifiers such as "good", "best", "worst".
-- Do not create new terms.
-- Do not use generic "there is" / "there are" openers.
-- Do not use symbols in place of words in running text.
-
-### Writing for global audiences
-- Use simple, objective, non-ambiguous language.
-- Keep sentences and paragraphs short. Split anything too long.
-- Prefer common en-US vocabulary and very specific words.
-
-## General Writing Rules
-
-### American English
-Use en-US spelling. Examples: behavior, color, organize, license, center, canceled.
-
-### Active voice
-- Prefer active voice; reserve passive voice for cases where the agent is unknown or irrelevant.
-- If you must use passive voice, use it consistently within the sentence.
-- Avoid: "the results that are returned by the query" → Prefer: "the results that the query returns".
-
-### Directly address the user
-- Use the imperative mood: "Click **Save**.", "Select the **Inspectors** tab."
-- Drop "please". Drop "please note".
-- Avoid: "After reading this tutorial, the roadmap should be created." → Prefer: "After reading this tutorial, create the roadmap."
-- Avoid: "If you want to enable filtering, you can set `filterable` to `true`." → Prefer: "To enable filtering, set `filterable` to `true`."
-
-### Gender-neutral language
-- Use they / their / theirs instead of he/she/his/her.
-- If "their" does not fit, rephrase to eliminate the pronoun.
-- Avoid unnecessarily gendered nouns ("man-hours" → "person-hours").
-
-### Avoid gerunds and -ing forms in running text
-- Minimize gerunds and "-ing" forms in body text.
-- Rewrite "-ing" adjectives that follow a noun: "a server running on …" → "a server that is running on …".
-- Eliminate dangling "-ing" phrases: "When using a hot spot, …" → "When you use a hot spot, …".
-- Exception: "-ing" forms are **encouraged** in titles and headings that describe a process ("Installing the Plugin", "Getting Started").
-
-### Simple tenses
-- Prefer the present simple tense.
-- Avoid "would" where "will" fits; avoid perfect tenses where past simple fits.
-- Avoid: "…which would be rendered as the popup header." → Prefer: "…which is rendered as the popup header."
-
-### Simple language
-- Use specific, concrete words. Prefer short words and short phrases.
-- Avoid generalizations and vague phrases.
-- Avoid space-saving symbols in running prose.
-
-### Short sentences and paragraphs
-- Keep sentences up to ~25 words.
-- Two to four sentences per paragraph.
-- Keep a paragraph up to six lines.
-- Split long compound sentences into two or more short sentences.
-
-### Modal verbs — should, could, would, must, have to, need to
-- Use "have to", "has to", "need to", or "must" for obligation.
-- Avoid "should" (ambiguous).
-- Replace "could"/"would" with "can"/"will" where possible.
-- For recommendations, use the imperative mood directly.
-- Avoid: "the + indicates that you should add one or more arguments" → Prefer: "…you have to add one or more arguments".
-
-### Logic, precision, verbs and actions
-- Use nouns as nouns and verbs as verbs. Do not verbify nouns or acronyms.
-- Keep phrasal verbs together: "Turn off the zoom tool…" not "Turn the zoom tool off…".
-- Use simple verb phrases; prefer action-centered writing.
-
-### Noun phrases
-- Avoid noun phrases longer than two words. Rephrase with prepositions or relative clauses.
-- Avoid: "the default column pointer location" → Prefer: "the default location of the column pointer".
-
-### Prepositional phrases
-- Place each prepositional phrase next to what it modifies.
-- Move prepositional phrases that modify the whole sentence to the start: "On a standard tape label, only 17 characters are available for the table name."
-
-### Pronouns
-- Make every pronoun's antecedent unambiguous.
-- Do not use "this", "that", "these", "those" as bare pronouns — pair them with the noun they refer to.
-- Avoid: "Apply all manual adjustments. These are listed on the Rules tab." → Prefer: "Apply all manual adjustments that are listed on the Rules tab."
-
-### Modifiers
-- Place "only" and "not" as close as possible to what they modify.
-- Hyphenate "-ing" adjectives and nouns in compound modifiers ("load-sharing facility", not "load sharing facility").
-
-### Prefixes
-- Check Merriam-Webster for the established spelling of prefixed words.
-- Do not hyphenate if the established form is closed ("noncritical", not "non-critical").
-- Hyphenate only when needed to avoid ambiguity ("re-create" vs. "recreate").
-
-### Contractions
-- Avoid contractions in documentation. Spell out "do not", "cannot", "will not", "it is", "you are".
-- Use the uncontracted form for emphasis.
-
-## Words for User Interaction
-- Desktop: click, double-click, right-click, press, select, deselect.
-- Mobile: tap, double-tap, swipe, tap and hold, spread, pinch, drag; for Apple 3D Touch use "touch".
-- Mixed devices: select, double-tap, or double-click.
-
-## Titles, Headings, and Subheadings
-
-### Structure
-- The article's `#` (level-one) heading matches the `title` and appears exactly once.
-- The `meta_title` / `page_title` may differ from the `#` heading for SEO (and may omit the product name).
-- Use `##` and `###` for sections and subsections. Use `####`+ only when necessary.
-- If a section has subheadings, include at least two; do not create a single lone subheading.
-- Place introductory text between a heading and its first subheading.
-
-### Capitalization (Title Case for titles and headings)
-Always capitalize:
-- First and last words.
-- Nouns, pronouns, verbs (including "Is"), adjectives, adverbs.
-- Subordinating conjunctions ("If", "Because", "That").
-- All words in phrasal verbs ("Take Off", "Turn Up").
-- Prepositions used as UI element names ("The On Button").
-- First and last word of a hyphenated expression ("How-To Guide", "Out-of-the-Box").
-
-Never capitalize:
-- Coordinating conjunctions ("and", "but", "or").
-- Articles ("a", "an", "the") — except when first or last.
-- Prepositions in general usage ("at", "on", "between").
-- "to" in an infinitive ("Widgets to Beautify Your App").
-
-### -ing forms
-- Use "-ing" forms in titles and headings for processes ("Getting Started", "Configuring the Grid", "Handing Off Projects to Developers").
-
-### Style
-- Make same-level headings grammatically parallel.
-- Do not repeat the parent heading's wording in subheadings ("Local Data Binding" → "Binding to Local Arrays").
-- Drop articles where the meaning stays clear ("Preserving the State in Cookies").
-- Do not use metaphors in headings ("The Right Way to…" → "Proper Approaches to…").
-- Do not cite object types, methods, or events in headings (except API articles). Describe the user's goal.
-- No ending punctuation in headings. No exclamation marks.
-- Preserve original capitalization inside quoted fragments in a heading.
-
-## Lists
-- Numbered lists for procedures; bulleted lists for same-priority items.
-- Introduce every list with a sentence ending in a colon.
-- Move repeating wording from the bullets into the introductory sentence.
-- Start each list item with a capital letter.
-- End each list item with a period only if it is a complete sentence. If any one item needs a period, give all items periods.
-- Avoid starting list items with "a", "an", "the".
-- Do not create single-item lists.
-- Keep list items grammatically parallel (all imperatives, all nouns, all full sentences).
-- Nest no deeper than three levels; restructure instead.
-- Place longer explanations in a separate paragraph aligned with the parent list item.
-
-## Metadata (YAML Front Matter)
-Always include, at minimum: `title`, `meta_title` (or `page_title` in earlier versions), `description`, and `slug`. The `slug` prevents 404s when the article moves.
-
-Example:
-
-```yaml
----
-title: Data Binding
-position: 1
-meta_title: Data Binding | {Component or Suite Name}
-description: "Bind the Kendo UI Grid to a local array or a remote data source."
-slug: data-binding-autocomplete
-previous_url: /data-management/grid/introduction
----
-```
-
-Repository-specific overrides (for example, Telerik Reporting uses `page_title` instead of `meta_title`, a `telerikreporting/` slug prefix, and fields like `tags`, `published`, `reportingArea`) take precedence over this generic shape.
-
-## Notes — Alert Blockquotes
-Use the repository's alert prefix convention (`>note`, `>tip`, `>important`, `>caution`, `>warning`) to convey:
-- **note** — neutral or positive supplementary information; memory limits, equipment configs, version-specific details.
-- **tip** — alternative methods and benefits; not essential to understanding the main text.
-- **important** (`caution` prefix in some repos) — essential information for task completion; must not be skipped.
-- **warning** — risk of data loss, security issues, or irreversible actions.
-
-Keep each note short and focused. One alert per idea.
-
-## Cross-References
-- Cross-link related articles generously.
-- Use descriptive anchor text. Never "click here", "go here", or "this link".
-- Make the link text clearly identify the linked content ("refer to the article on [binding the Scheduler to data](…)").
-- When quoting an external resource, cite its exact name and author.
-- Always include a `See Also`, `Suggested Links`, or `Next Steps` section near the end of the article for navigation.
-- Use `Next Steps` in tutorials and in feature areas that span multiple articles.
-
-## Prepositions (Common Phrases)
-- **in** — a command mode, a dialog box, a pane, a window, a class, a code snippet, a container, a file, a filename, a property, a method, an object, the example.
-- **on** — a page, the desktop, a worksheet, a control, the screen.
-- **at** — a command line, a prompt.
-
-## Comments in Code Snippets
-- Write comments in English.
-- Keep each comment line up to 80 characters so it fits the viewport.
-- Do not over-comment self-explanatory code.
-
-## Captions for Figures, Tables, and Code Snippets
-- Introduce every table, figure, screenshot, code snippet, or demo with either a descriptive sentence or a bold caption.
- - Descriptive sentence example: "The following table lists the configuration options of the TreeList."
- - Caption example: "**Available Configuration Options of the TreeList**".
-- Place the caption before the element.
-- Render captions in bold.
-- No ending punctuation unless the caption is a complete sentence.
-- Do not number captions manually.
-
-## Screenshots and Images
-- Use the product's default appearance. Avoid 3D effects.
-- Use arrows to point to the element being explained.
-- Minimize empty space; crop tightly.
-- Maximum width ~1000 px.
-- For labels, use Arial 16 pt.
-- Alt text is a descriptive sentence, not the file name.
-
-## Tables
-
-### Headers
-- Sentence case for the table title and column headings.
-- No ending punctuation in headers.
-- Unformatted text only — no bold, italic, or code formatting in headers.
-
-### Content
-- Follow general capitalization and semantic-marking rules in body cells.
-- Every cell has content. If data does not apply, write "N/A", "Not applicable", or "None" — never a dash.
-
-## Element Formatting
-- **Bold** — UI labels, menu items, buttons, dialog box names, window titles. Example: "To submit the form, click **Save**."
-- `Code formatting` — HTML tags, methods, events, variables, class names, CLI commands, file names, property names. Example: "To trigger the `save` event, click **Save**."
-- `Code formatting` — keyboard keys and shortcuts. Example: "To save the form, press `Ctrl+S`."
-- *Italics* — sparingly, for genuine emphasis or the first appearance of a new term.
-
-## Company and Product Brand Names
-- Follow the official [Progress trademark list](https://www.progress.com/legal/trademarks) and the [Progress brand guidelines](http://brand.progress.com/).
-- Use "Telerik Reporting", "KendoReact", "Kendo UI for Angular", "Telerik UI for Blazor" exactly as branded.
-- Use "Progress® Telerik® Reporting" only in formal or legal contexts; "Telerik Reporting" in running prose.
-- Respect third-party trademarks when referenced.
-
-## Pre-Publish Self-Check
-Before submitting an article, verify:
-1. American English spelling throughout.
-2. Active voice used wherever practical; no bare "is/are …ed" passives where the agent is known.
-3. Imperative mood in instructions; no "please", no "let's".
-4. No contractions.
-5. No "should"; modal verbs chosen intentionally.
-6. Sentences ≤ 25 words; paragraphs ≤ 6 lines.
-7. Every heading uses Title Case with correct capitalization rules; no ending punctuation.
-8. Same-level headings are parallel; no single-item lists; no lone subheadings.
-9. Every list has a colon-ending introductory sentence and parallel items.
-10. YAML front matter includes `title`, `meta_title`/`page_title`, `description`, `slug`.
-11. Every table, figure, and code block has a caption or introductory sentence.
-12. Every cross-reference has descriptive anchor text.
-13. A `See Also` or `Next Steps` section exists near the end.
-14. Alt text is a sentence, not a file name.
-15. No emojis, culture-specific references, Latin abbreviations, or gendered pronouns.
|