Updating production with staging state

.ai/skills/igniteui-doc-topics/SKILL.md

@@ -73,12 +73,14 @@ Section → mode map (full contents in `house-style.md`):
 | Live Demo | demonstration (action) | prose/explanation |
 | Anatomy: visual + DOM tree / skeleton | orientation (reference) | opinion, install steps |
 | Getting Started, Usage | **how-to** | *why* explanations, exhaustive option lists |
+| Getting Started → Prerequisites and Version Compatibility | reference / how-to | unverified support claims, migration history |
 | Usage → Do/Don't | **explanation** | install steps, code, API detail |
 | Properties / Methods / Events | **reference** | instructions, opinion |
 | Styling (`### Sass Theming`, `### Tailwind`, …) | how-to (steps) + reference (tables) | conceptual essays |
 | Accessibility | reference (keyboard/ARIA/compliance tables) | tutorials, marketing, unverified conformance claims |
 | Troubleshooting | how-to (cause → fix) | background theory |
-| API References / Dependencies / Additional Resources | reference / navigation | new teaching |
+| Known Limitations | **reference** | troubleshooting fixes, tutorials, unverified claims |
+| API References / Dependencies / Additional Resources / Related Components / FAQ | reference / navigation | new teaching |
 
 Concrete mode-bleed to catch: a *why* paragraph inside **Usage** (→ move to Do/Don't or a concept
 topic, link back); "how to build X" prose inside **Properties** (→ move to Usage; keep the table
@@ -92,31 +94,50 @@ cheat-sheet's "two classic confusions" section explains the reasoning.
    for React/WC/Blazor using `{Platform}`/`{ProductName}` tokens and `<PlatformBlock for="…">`. Load
    the relevant details from `house-style.md`.
 3. **Follow the verification workflow** in `house-style.md` before writing technical content.
-   Existing snippets and old prose are clues, not authority.
+   Existing snippets and old prose are clues, not authority. For component topics, also inspect the
+   matching Indigo.Design component documentation under
+   `https://www.infragistics.com/products/indigo-design/help/components/` and use its component
+   structure as input for Usage subsection suggestions.
 4. **Write frontmatter first** — `title`, `description` (answer-shaped, ≤~160 chars), `keywords`,
    `license`, `llms.description`, `mentionedTypes` (xplat), and `relatedComponents` if the component
    has close siblings (this lets **Usage**'s final **Do/Don't** subsection name the specific
    sibling instead of speaking generically).
 5. **Lay out the canonical sections** in order for that topic type, required ones always present.
    Feature-specific content goes as sub-headings under **Usage**, never as new top-level sections.
 6. **Fill each section in its mode.** Lead every section with one plain, specific sentence. Put
-   reference in tables. In **Usage**, start with a basic declaration and then add property-focused
-   sub-sections so every public input is shown with a minimal snippet; group only tightly coupled
-   properties that form one behavior. End **Usage** with `### Do/Don't`, using inline **When to use:**
-   and **When not to use:** labels rather than nested headings. Embed exactly one top `<Sample>`, then
-   Usage samples only for distinct tasks (soft max 5/page). Phrase Do/Don't and Troubleshooting as
-   the reader's real questions.
+   reference in tables. In **Usage**, add property-focused sub-sections so every public input is
+   shown with a minimal snippet; group only tightly coupled properties that form one behavior. Keep
+   existing useful subsections, then compare against Indigo.Design's component sections by meaning,
+   not by exact heading name, to suggest or add any missing runtime-relevant Usage subsections.
+   End **Usage** with `### Do/Don't`, using inline **When to use:**
+   and **When not to use:** labels rather than nested headings, plus the matching guidance image
+   from the Indigo.Design documentation or a `{/* TODO */}` marker when the asset is not available.
+   Add a required `## Live Demo` section
+   with exactly one top `<Sample>`, then Usage samples only for distinct tasks (soft max 5/page).
+   Phrase Do/Don't and Troubleshooting as the reader's real questions. Include the required
+   `### Prerequisites and Version Compatibility` subsection under **Getting Started**, and the
+   required **Known Limitations**, **Related Components**, and **FAQ** sections in their canonical
+   positions.
+   For FAQ content, import and use the shared Astro `Faq` and `FaqItem` components. In slot mode,
+   set `indicatorPosition="end"` on every `FaqItem`, because the value on `Faq` does not flow into
+   slotted children. When auditing, flag plain FAQ headings or custom accordion markup and convert
+   each question/answer pair to an `FaqItem` while keeping the answer concise and component-specific.
 7. **Self-check against the rubric** before presenting — especially mode-bleed (C-checks) and
    metadata (D-checks). Fix, then deliver the `.mdx`.
 
 ## Audit workflow
 
 1. **Classify** the topic and identify its doc set (Angular vs xplat) and type.
 2. **Follow the verification workflow** in `house-style.md` before judging technical content.
-   Old snippets/prose are never the source of truth by themselves.
+   Old snippets/prose are never the source of truth by themselves. For component topics, inspect the
+   matching Indigo.Design component documentation and compare its structure to the topic's Usage
+   subsections by semantic content, not heading text, before making Usage-coverage suggestions.
 3. **Run every check** in `references/audit-rubric.md` — structure/order (A), naming (B), Diátaxis
    mode integrity (C), metadata/AI-readiness and correctness (D), samples/links (E), formatting and
    snippet currency (F). For mode integrity, run the compass on each section and flag drift.
+   For detailed frontmatter-only audits or normalization, use the companion
+   `igniteui-topic-frontmatter` skill; for full topic audits, apply only the basic metadata checks
+   here unless the user asks for frontmatter suggestions.
 4. **Report** in the rubric's exact format: Verdict → Summary → Findings (each with Where / Issue /
    Principle / Fix) → Quick wins. Order findings Error → Warning → Suggestion.
 5. Keep every **Fix** concrete and applyable (the corrected heading, the sentence to move, the table

.ai/skills/igniteui-doc-topics/references/audit-rubric.md

@@ -13,18 +13,24 @@ concrete rule below (structure, naming, Diátaxis mode, or metadata) and to a fi
 ## Checks
 
 ### A. Structure & order
-- A1 (Error) A required section is missing (Live Demo, Anatomy, Getting Started, Usage,
-  Properties, Accessibility, API References, Additional Resources on a component
-  topic).
+- A1 (Error) A required section or subsection is missing (`## Live Demo`, Anatomy, Getting Started
+  with `### Prerequisites and Version Compatibility`, Usage, Properties, Accessibility,
+  Known Limitations, API References, Dependencies, Additional Resources, Related Components, and
+  FAQ on a component topic. **Troubleshooting** is conditional and is required only when the topic
+  contains version-migration, deprecation, or legacy-setup notes.)
 - A2 (Warning) Sections are present but out of the canonical order.
 - A3 (Warning) A conditional section sits in the wrong slot.
 - A4 (Error) A feature-specific top-level `##` exists that should be a sub-heading under **Usage**,
-  including a top-level `## Do/Don't`.
-- A5 (Error) **Live Demo** is missing near the top of the topic or appears after **Anatomy**.
-- A6 (Suggestion) >10 live samples on one page (soft cap) — consider splitting. Up to 10 is fine;
+  including a top-level `## Do/Don't`; or a required canonical section has been omitted or replaced
+  by a non-standard heading.
+- A5 (Error) `## Live Demo` is missing near the top of the topic, appears after **Anatomy**, or the
+  top preview `<Sample>` is left as a bare block instead of living inside the `## Live Demo` section.
+- A6 (Suggestion) >5 live samples on one page (soft cap) — consider splitting. Up to 5 is fine;
   only flag when a page clearly sprawls past that.
-- A7 (Warning) **Usage** does not end with `### Do/Don't`, or **When to use:** / **When not to use:**
-  are written as nested headings instead of inline labels inside that subsection.
+- A7 (Warning) **Usage** does not end with `### Do/Don't`, **Do/Don't** is missing the
+  Indigo.Design guidance image or a `{/* TODO */}` marker for the not-yet-available asset, or
+  **When to use:** / **When not to use:** are written as nested headings instead of inline labels
+  inside that subsection.
 - A8 (Warning) **Anatomy** is incomplete: missing its opening screenshot/GIF (or a `{/* TODO */}`
   marker for a not-yet-available asset), or missing the verified DOM tree / skeleton.
 - A9 (Warning) **Accessibility** is missing one of its three required `###` sub-sections —
@@ -33,6 +39,11 @@ concrete rule below (structure, naming, Diátaxis mode, or metadata) and to a fi
 - A10 (Warning) **Usage**'s **Do/Don't** subsection contains install steps, code snippets, a property table, or other
   reference/how-to content that belongs in Getting Started, another Usage subsection, Properties, or Accessibility instead of do/don't
   guidance.
+- A11 (Warning) **FAQ** uses plain question headings or hand-written accordion markup instead of
+  the shared Astro `<Faq>` / `<FaqItem>` components, or does not keep each answer concise and
+  component-specific.
+- A12 (Warning) A slot-mode FAQ does not set `indicatorPosition="end"` on every `<FaqItem>`;
+  setting it only on `<Faq>` does not affect slotted children.
 
 ### B. Naming
 - B1 (Warning) A heading uses a drifted name with a standard equivalent (see reconciliation table).
@@ -56,12 +67,17 @@ Run the compass on each section; flag content that has drifted out of the sectio
 - C6 (Warning) **Styling content inside Usage** (CSS-var overrides, `color`/background
   snippets) — move to the **Styling** section; Styling should also open with a `<Sample>` of the result.
 - C7 (Warning) **Usage doesn't cover every public input** with a property-focused sub-section and
-  minimal snippet, omits `### Basic Declaration`, or documents each option in isolation instead of
+  minimal snippet, or documents each option in isolation instead of
   grouping tightly coupled properties and stating the behavioral relationship once (e.g. the
   content-type priority).
 - C8 (Warning) **Usage**'s **Do/Don't** drifts into another mode — install/code steps (belongs in Getting
   Started/Usage), an exhaustive option table (belongs in Properties), or conformance claims (belongs
   in Accessibility) instead of do/don't guidance.
+- C9 (Suggestion) **Usage subsection opportunities from Indigo.Design** — the matching
+  Indigo.Design component topic has a section whose meaning maps to a real Ignite UI API, slot,
+  state, layout pattern, or verified sample, but the topic does not cover it. Compare by semantic
+  content rather than heading text, and do not flag Figma-only structure that belongs in Anatomy or
+  Styling instead of Usage.
 
 ### D. Metadata & AI-readiness
 - D1 (Warning) `relatedComponents` is set but **Usage**'s **Do/Don't** guidance doesn't name the
@@ -87,10 +103,15 @@ Run the compass on each section; flag content that has drifted out of the sectio
   `https://www.infragistics.com/api/blazor`). Use typed source for implementation details not exposed
   by API docs, and official framework docs for framework/version behavior; if unverifiable, don't
   assert it. Existing topic snippets/prose are not sufficient proof.
-- D10 (Warning) **Voice/tone drift** — prose isn't imperative/second-person present tense, mixes
+- D10 (Error) A component topic is missing the required `last_updated` metadata, or is missing the
+  corresponding visible `**Last updated:** Month D, YYYY` line immediately after the lead paragraph,
+  uses a different placement or format, or duplicates the date elsewhere in the body. The visible
+  value must be generated from or match the `last_updated` metadata and must not be manually hard-coded
+  independently in the body.
+- D11 (Warning) **Voice/tone drift** — prose isn't imperative/second-person present tense, mixes
   first-person-plural narration ("we create") with how-to, or carries filler ("simply", "just") or
   marketing inside instructional prose.
-- D11 (Error) **Blanket or unverified accessibility-conformance claim** — "fully accessible" /
+- D12 (Error) **Blanket or unverified accessibility-conformance claim** — "fully accessible" /
   "WCAG compliant" prose, a conformance target (WCAG level, Section 508, EN 301 549) with no official
   source, a conformance-table row not traceable to behavior verified on the page or in source, an
   "N/A" filler row for an irrelevant criterion, or an invented testing/AT matrix or VPAT link.