diff --git a/.ai/skills/igniteui-doc-topics/SKILL.md b/.ai/skills/igniteui-doc-topics/SKILL.md new file mode 100644 index 0000000000..92b2996b6d --- /dev/null +++ b/.ai/skills/igniteui-doc-topics/SKILL.md @@ -0,0 +1,142 @@ +--- +name: igniteui-doc-topics +description: >- + Author or audit Ignite UI documentation topics — component pages, how-to guides, conceptual + overviews, and category indexes — for both the Angular doc set and the cross-platform (React / + Web Components / Blazor) doc set. Applies the Diátaxis framework mapped onto Ignite UI's house + templates: canonical section order, fixed heading names, frontmatter (including `llms.description` + and the `relatedComponents` trigger), `.mdx` sample embeds, and per-framework token/PlatformBlock + mechanics. Use this whenever someone asks to write, draft, create, review, audit, fix, or + standardize a documentation topic, tutorial, guide, reference page, or concept overview for Ignite + UI — even if they just say "write docs for the X component" or "review this topic" without naming + Diátaxis or the templates. Also use it when deciding what *kind* of documentation a page should be, + or when a topic mixes tutorial / how-to / reference / explanation content that should be separated. +--- + +# Ignite UI doc topics + +Write and audit Ignite UI documentation topics so every page has the same predictable shape — easy +for developers to read and for AI assistants to answer from. The engine is **Diátaxis** (four +documentation modes) applied through **Ignite UI's house templates**. + +## Two modes of operation + +- **Create** — draft a new topic (component, concept/guide, or category/index) to the standard. +- **Audit** — review an existing topic against the standard and return an issues-and-fixes report. + +Detect which from the request ("write/draft/create" → Create; "review/audit/check/fix/standardize" → +Audit). If a topic file or content is supplied, default to Audit unless they ask for a rewrite. + +## Reference files — load what the task needs + +- `references/diataxis-cheatsheet.md` — the four modes + the compass. Load when classifying a topic + or diagnosing mode-bleed. +- `references/house-style.md` — sections, order, naming, frontmatter, sample/token mechanics, both + doc sets. Load for **every** create or audit. +- `references/audit-rubric.md` — the checkable rules + report format. Load for **every** audit. + +Read `house-style.md` before writing or judging any topic — it carries the mechanical details +(frontmatter fields, ``/`` syntax, Angular-vs-xplat differences) that aren't +in this file. + +## Step 0 — Classify with the compass (always first) + +Before writing or auditing, decide what *kind* of documentation the page is, using the compass from +the cheat-sheet: + +> **action or cognition?** × **acquisition (study) or application (work)?** +> → tutorial · how-to · reference · explanation + +- A **component page** is a *composite* (see below). +- A **concept / guide overview** is **explanation**. +- A **category / index overview** is **reference/navigation** (a map). +- A standalone **"How to …" article** is a **how-to guide** — keep it single-mode. + +If a request is ambiguous ("document X"), state which topic type you're producing and why, in one +line, before proceeding. + +## The composite-topic principle (the heart of this skill) + +Pure Diátaxis says keep the four modes in **separate** documents. Ignite UI **component topics +deliberately don't** — one page carries a live demo, a how-to (Getting Started/Usage), +decision guidance in Usage's final Do/Don't subsection, and reference tables +(Properties/Methods/Events). That is fine **because each *section* owns exactly one mode.** The rule +that makes it work: + +> **One section, one mode. No mode-bleed.** Each section stays in its assigned Diátaxis mode; when a +> second mode wants in, move it to the section that owns it and cross-link. + +Section → mode map (full contents in `house-style.md`): + +| Section | Mode | Stays out of | +|---|---|---| +| 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 | +| 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 | + +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 +descriptive); an exhaustive option list written out in **Usage** prose (→ move to the table). The +cheat-sheet's "two classic confusions" section explains the reasoning. + +## Create workflow + +1. **Classify** (Step 0). Name the topic type. +2. **Pick the doc set & framework.** Angular set = its own file, plain prose. xplat set = one file + for React/WC/Blazor using `{Platform}`/`{ProductName}` tokens and ``. 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. +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 ``, then + Usage samples only for distinct tasks (soft max 5/page). Phrase Do/Don't and Troubleshooting as + the reader's real questions. +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. +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. +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 + to add). If the topic is already clean, say so and note what it does well — don't invent problems. + +## Grounding notes + +- The live `vnext` repo is **pre-standardization**: expect drifted headings (`## Angular Rating + Example`, `## Configuration`) and a missing `relatedComponents` field. Author to the **target** + standard; audit against it while recognizing current reality. +- **Invent no verifiable identifier (zero-risk rule).** Never emit a guessed tag, class, package, + property, method, event, CSS part, or theming variable — a plausible-but-wrong name a reader copies is + worse than a visible gap. Use an identifier only when verified (typed API source, an existing topic, + or the user); otherwise write `‹VERIFY: …›`. For Properties/Methods/Events, emit the fixed column + headers plus a build-injection note and leave the rows to the generator. React/Blazor wrapper symbols + resolve to the `igc` core — prefer verified `igc` usage and mark unconfirmed wrapper names `‹VERIFY:…›`. + (Full detail in `house-style.md` → "Never fabricate API identifiers".) +- Prefer paraphrase and the standard section names over copying any existing topic's prose verbatim. +- **Write in one voice and verify every claim** (see house-style → *Voice & tone* and *Verify every + claim against the component*): instruct in the imperative/second person, and check every factual + statement — defaults, behavior, version support, DOM — against the MCP/API-doc source, the official + platform API docs, typed source when needed, or official framework docs before writing it or + recommending it as an edit. Don't "correct" prose into a plausible claim you haven't verified. diff --git a/.ai/skills/igniteui-doc-topics/references/audit-rubric.md b/.ai/skills/igniteui-doc-topics/references/audit-rubric.md new file mode 100644 index 0000000000..1d3d2dc93e --- /dev/null +++ b/.ai/skills/igniteui-doc-topics/references/audit-rubric.md @@ -0,0 +1,163 @@ +# Audit rubric + +The checkable rules for **audit mode**, and the report format to produce. Every finding maps to a +concrete rule below (structure, naming, Diátaxis mode, or metadata) and to a fix. Detail lives in +`house-style.md`; the *why* behind mode findings lives in `diataxis-cheatsheet.md`. + +## Severity + +- **Error** — breaks the standard or misleads readers/AI. Must fix. +- **Warning** — drift or a gap that degrades quality. Should fix. +- **Suggestion** — polish; author's judgment. + +## 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). +- 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; + 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. +- 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 — + **Keyboard Interaction**, **Screen Readers / ARIA**, **Accessibility Compliance** — or has them out + of order. +- 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. + +### B. Naming +- B1 (Warning) A heading uses a drifted name with a standard equivalent (see reconciliation table). + Report both: `"Configuration" → Properties`. +- B2 (Warning) Non-standard one-off heading (e.g. `## Angular Rating Example`) → map to standard. +- B3 (Suggestion) Singular/plural or casing mismatch (`API Reference` → `API References`). +- B4 (Warning) H1 carries a framework prefix or an "Overview" suffix → standard H1 is + `‹Component› Component` (e.g. `# Angular Avatar Component Overview` → `# Avatar Component`). +- B5 (Warning) A **Usage** sub-heading repeats the component name (`### Avatar Shape` → `### Shape`). + +### C. Diátaxis mode integrity (mode-bleed) +Run the compass on each section; flag content that has drifted out of the section's assigned mode. +- C1 (Warning) **Explanation inside Usage/Getting Started** outside the final **Do/Don't** subsection + ("The reason this works is…") — move to **Do/Don't** or a concept topic and link. +- C2 (Warning) **Instruction inside a reference section** (Properties/Methods/Events telling the + reader *how to* build something) — move to Usage; keep the table descriptive. +- C3 (Warning) **Reference dumped into Usage** (exhaustive option lists in prose) — move to the table. +- C4 (Warning) **Usage**'s **Do/Don't** only says when to *use* the component, never when *not* to — the + When-Not-to-Use redirect is the high-value half. +- C5 (Suggestion) Tutorial-style hand-holding in a how-to (or vice-versa) — match the audience. +- C6 (Warning) **Styling content inside Usage** (CSS-var overrides, `color`/background + snippets) — move to the **Styling** section; Styling should also open with a `` 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 + 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. + +### D. Metadata & AI-readiness +- D1 (Warning) `relatedComponents` is set but **Usage**'s **Do/Don't** guidance doesn't name the + specific sibling(s) by name and link them — or vice-versa, it names a sibling that isn't listed in + `relatedComponents`. +- D2 (Warning) Missing/weak `description` or `llms.description` (not answer-shaped, or >~160 chars). +- D3 (Warning) Section opens with no plain lead sentence, or with empty boilerplate. +- D4 (Warning) A section relies on "as mentioned above" / isn't self-contained. +- D5 (Warning) Properties/Methods/Events appear hand-written rather than from the typed source. +- D6 (Suggestion) Styling variables undocumented where the component is themeable. +- D7 (Warning) xplat: hard-coded framework name where a `{Platform}`/`{ProductName}` token belongs, or + framework-specific content not wrapped in ``. +- D8 (Error) An API identifier (tag, class, package, property, method, event, CSS part, theming + variable) appears to be fabricated/unverifiable, or an unresolved `‹VERIFY:…›` placeholder was left + in. Public API values must trace to the Ignite UI/API docs MCP source, or to the official platform + API docs when MCP is unavailable. +- D9 (Error) A **claim** contradicts or isn't verifiable against the component — a wrong default, + value range, precedence/fallback behavior, version-support statement, deprecation, or DOM + description. For public API facts, verify against the Ignite UI/API docs MCP source first; if MCP is + unavailable, use the official Infragistics API docs for the target platform (React + `https://www.infragistics.com/api/react/`, Web Components + `https://www.infragistics.com/api/webcomponents/`, Blazor + `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 + 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" / + "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. + Fix: criterion-level rows tied to observable behavior, or `‹VERIFY:…›`. + +### E. Samples & links +- E1 (Warning) `` missing an `alt`. +- E2 (Suggestion) Near-duplicate samples that teach the same task. +- E3 (Warning) Hand-written API URL instead of ``. +- E4 (Warning) `
` or `` placed directly before or after a ``, code fence, + or table (dividers separate prose only). +- E5 (Warning) A `` sets both `fitContent` and `height` — they are mutually exclusive. + `fitContent` sizes the iframe to the component, so remove `height`. +- E6 (Error) An `` whose `type` has no generated reference page — typically an abstract/base + class (e.g. `ButtonBase`): the link renders (e.g. `IgrButtonBase`) but points nowhere. Verify the + `type` appears as an `` target elsewhere in the doc set; link base-class members through + the concrete component (`type="Button" member="href"`) instead. + +### F. Formatting & altitude +- F1 (Suggestion) A `ul`/`ol` with a single item that should be a paragraph. +- F2 (Warning) A deprecated/legacy setup (e.g. NgModule) shown **above** the current recommended + approach (standalone) — reorder so current is first, legacy after and marked as such. +- F3 (Suggestion) The **Styling** section doesn't open with a `` of the styled result, or its + first subsection isn't `### Sass Theming`. +- F4 (Suggestion) **Getting Started** repeats the generic install boilerplate (the `ng add` command + with the "install the library first / read getting started" prose that is identical on every page) + instead of compressing it to a **one-line prerequisite link** and leading with the component-specific + import. +- F5 (Warning) An inline Properties/Styling-Variables table has rows not verified from source, or is + presented as generated when the repo has no generator (curated + `` is the current rule). +- F6 (Warning) A version-migration note lives inside a code-fence comment, or legacy/alternative setup + (e.g. NgModule) is scattered outside **Troubleshooting** → move it into Troubleshooting as + question → cause → fix; keep Getting Started and samples on the current path only. +- F7 (Warning) An **inline** fenced code snippet uses a deprecated API or outdated framework idiom + (e.g. `standalone: true`, `*ngIf`/`*ngFor`, an old import path) → modernize it. Scope is authored + snippets only; **live `` embeds are out of scope** (fix those in the sample project), and + legacy snippets deliberately kept in **Troubleshooting** are exempt. +- F8 (Warning) The Styling section has **per-theme variable tables** (the legacy + `.theme-switcher-wrapper` / `.theme-table` tabbed markup) or a **default-value column** in the + Styling Variables table. Every theme extends the same base schema — the variable *set* is identical + across themes, only the default values differ — so per-theme tabs document a difference that doesn't + exist, and defaults are per-theme data for the generated API reference. Fix: collapse to **one + two-column table (variable · what it changes)**. + +## Report format + +Produce this exact shape: + +``` +# Audit: ( · ) + +**Verdict:** +**Summary:** <2–3 sentences: biggest issues and the through-line.> + +## Findings +### · · +- **Where:**
+- **Issue:** +- **Principle:** +- **Fix:** + + + +## Quick wins + +``` + +Keep every **Fix** concrete and applyable — the corrected heading text, the exact sentence to move and +where, the table columns to add. Group findings by severity, most severe first. If the topic is clean, +say so plainly and note what it does well rather than inventing problems. diff --git a/.ai/skills/igniteui-doc-topics/references/diataxis-cheatsheet.md b/.ai/skills/igniteui-doc-topics/references/diataxis-cheatsheet.md new file mode 100644 index 0000000000..2ef9bceeac --- /dev/null +++ b/.ai/skills/igniteui-doc-topics/references/diataxis-cheatsheet.md @@ -0,0 +1,72 @@ +# Diátaxis cheat-sheet + +Condensed from https://diataxis.fr (tutorials, how-to, reference, explanation, compass). +This is the *reasoning layer*. For how the four modes attach to Ignite UI sections, see +`house-style.md`. Read this whenever you're unsure what kind of content a topic — or a single +section — should be. + +## The compass (use this first, every time) + +Two questions decide the mode. Ask them of the *content in front of you* or the *user need*: + +| If the content… | …and serves the user's… | …then it is… | +| ----------------- | ----------------------- | ------------ | +| informs **action** | **acquisition** of skill (study) | a **tutorial** | +| informs **action** | **application** of skill (work) | a **how-to guide** | +| informs **cognition** | **application** of skill (work) | **reference** | +| informs **cognition** | **acquisition** of skill (study) | **explanation** | + +- *action* = doing, practical steps. *cognition* = thinking, propositional knowledge. +- *acquisition* = study/learning. *application* = getting real work done. + +Apply the compass at any zoom level: a whole topic, a section, even a sentence. When a section +"feels off," run the compass on it — usually it has drifted into a second mode. + +## The four modes at a glance + +| Mode | Serves | Question it answers | Cardinal rule | Voice | +|------|--------|---------------------|---------------|-------| +| **Tutorial** | learning by doing | "Teach me, hold my hand" | Ruthlessly minimise explanation; guarantee success | "In this tutorial *we* will…" | +| **How-to guide** | a competent user's task | "Help me get X done" | Action only; no teaching, no digression | "To achieve X, do Y." | +| **Reference** | look-up during work | "What exactly is X / its options?" | Describe and *only* describe; be austere | "The `value` property accepts a number 0–5." | +| **Explanation** | understanding a topic | "Tell me about X / why?" | Discuss, connect, weigh alternatives; stay bounded | "X exists because… An alternative is…" | + +### Tutorial — learning-oriented +A lesson. The learner learns *by doing*, under guidance, toward a meaningful, guaranteed-to-succeed +result. Show where they'll end up; deliver visible results early and often; keep a narrative of the +expected ("after a moment you'll see…"); ignore options and alternatives; minimise explanation (link +out instead). Reliability is sacred — it must work for every reader, every time. + +### How-to guide — task/goal-oriented +Directions that guide an already-competent user through a real-world problem. Defined by the *user's +goal*, not by the machinery ("How to validate a reactive form," not "The validation API"). A sequence +with flow. Omit the unnecessary; usability beats completeness. Title says exactly what it shows +("How to…"). This is a recipe, not a cooking lesson. + +### Reference — information-oriented +Neutral, authoritative technical description of the machinery — properties, methods, events, options. +Structured to mirror the code. Austere: you *consult* it, you don't read it. No instruction, no +opinion, no explanation — link out for those. Tables and examples are ideal. Best when +auto-generated from the typed source so it never drifts. + +### Explanation — understanding-oriented +Discursive treatment of a topic that permits reflection. Higher, wider view than the other three. +Answers "Can you tell me about…?" and "Why…?". Make connections, give context and history, weigh +alternatives and admit opinion. Name it with an implicit *"About …"* in front of the title. Keep it +bounded — it tends to absorb instruction and reference that belong elsewhere. + +## The two classic confusions (where writers go wrong) + +1. **Tutorial vs how-to.** Same steps, different need. A tutorial *teaches* a beginner (success + guaranteed, no choices, minimal why). A how-to serves a competent user getting a *specific job* + done (adaptable, may fork, assumes background). Don't merge them. +2. **Reference vs explanation.** Reference *describes* (cognition + work): austere, neutral, complete. + Explanation *illuminates* (cognition + study): discursive, contextual, opinionated. A properties + table is reference; "why the component works this way" is explanation. Keep them in separate + sections and link between them. + +## The golden rule + +Each unit of documentation should serve **one** need in **one** mode. When two modes want to live in +the same section, split them and cross-link. In Ignite UI topics this happens at the *section* level — +see the composite-topic principle in `SKILL.md`. diff --git a/.ai/skills/igniteui-doc-topics/references/house-style.md b/.ai/skills/igniteui-doc-topics/references/house-style.md new file mode 100644 index 0000000000..6dcdbdabf6 --- /dev/null +++ b/.ai/skills/igniteui-doc-topics/references/house-style.md @@ -0,0 +1,361 @@ +# Ignite UI house style + +The Ignite UI documentation conventions an authored or audited topic must follow. Pair this with +`diataxis-cheatsheet.md` (the *why*) and the section→mode map in `SKILL.md`. + +> **Current vs target state.** The live `vnext` repo is *pre-standardization* — many topics use +> drifted headings (e.g. `## Angular Rating Example`, `## Configuration`). This file describes the +> **target** standard (revision-2 blueprint). When **authoring**, write to the target. When +> **auditing**, measure against the target and report the gap. + +## Two doc sets + +| Doc set | Frameworks | Path (vnext) | Layout | One topic = | +|---|---|---|---|---| +| **Angular** | Angular only | `docs/angular/src/content/en/components/` | flat `*.mdx` | one framework | +| **xplat** | React · Web Components · Blazor | `docs/xplat/src/content/en/components//` | categorized `*.mdx` | **one file, all three frameworks** | + +The **same section list, order, and names apply to both sets.** Differences are mechanical only (see +Per-framework mechanics), never the shape of the page. **Dependencies** appears in both sets — it +covers modules to import (Angular) or supporting components/themes required to render or function +(xplat); currently seen as `## Theming Dependencies`. + +## File format & frontmatter + +Topics are **Astro `.mdx`**. Frontmatter is YAML. Observed + target fields: + +```yaml +--- +title: "Angular Star Rating Component – Ignite UI for Angular - MIT license" # SEO title +description: "…" # <=~160 chars, shaped as an answer ("X is a … that …") +keywords: "…" # comma-separated +license: MIT +mentionedTypes: ["Rating"] # xplat: API types referenced on the page +llms: + description: "…" # AI-facing one-liner; the exact text an assistant uses to summarize +relatedComponents: [Toast, Banner] # TARGET field — drives the Usage Do/Don't trigger (see below) +--- +``` + +- **`llms.description`** already exists in both sets and is high-value — write it as a crisp, + self-contained answer sentence. It is *not* optional filler. +- **`relatedComponents`** is the revision-2 trigger and is **not yet in the repo**. When authoring to + target, set it. When auditing, treat a missing-but-warranted value as a finding, and a set value + with no **Usage** → **Do/Don't** guidance as a hard error. + +### MDX imports (declare what you use) + +```mdx +import Sample from 'igniteui-astro-components/components/mdx/Sample.astro'; +import ApiLink from 'igniteui-astro-components/components/mdx/ApiLink.astro'; +import DocsAside from 'igniteui-astro-components/components/mdx/DocsAside.astro'; +import PlatformBlock from 'igniteui-astro-components/components/mdx/PlatformBlock.astro'; # xplat only +``` + +## Per-framework mechanics + +- **Prefixes differ by framework/library — don't assume one for all:** + - **Angular** → native **`igniteui-angular`**, **`igx-`** tags / **`Igx…Component`** classes. The + Angular doc set documents this library. + - **Web Components** → **`igniteui-webcomponents`**, **`igc-`** tags / **`Igc…Component`** classes. + - **React** → **`igniteui-react`**, a **wrapper around the `igc`** web components. + - **Blazor** → **`igniteui-blazor`**, a **wrapper around the `igc`** web components. +- **Net effect:** the **xplat doc set (React / WC / Blazor) is entirely `igc`-based** — WC is `igc` + directly; React and Blazor wrap it. The **Angular doc set is `igx`**. +- **Exception — WC-first components in the Angular docs.** Some newer components are built as web + components and surfaced in the Angular docs via the `igc` element rather than a native `igx` one + (verified: the Angular **Rating** topic installs `igniteui-webcomponents`, registers + `IgcRatingComponent`, and renders ``). So **don't assume `igx` for every Angular topic** — + verify the tag/class per component. +- **Angular set:** plain prose, no platform tokens. Registers and renders whichever the component is + (`igx-…` native, or the `igc-…` WC for the exceptions above). +- **xplat set:** the *same file* serves React / WC / Blazor via: + - **Tokens** the build resolves: `{Platform}`, `{ProductName}`, `{PackageWebComponents}`, + `{PackageReact}`, `{PackageBlazor}`, etc. Use them in title/description/keywords/headings and prose + — never hard-code "React" where a token belongs. + - **`…`** to wrap framework-specific content + (install commands, imports, snippets). `for` values: `WebComponents`, `React`, `Blazor`. +- **Live samples** embed the same way in both sets: + `` +- **API links** use `` rather than hand-written URLs so they resolve per framework. + +## Never fabricate API identifiers (zero-risk rule) + +The skill's job is structure and prose, **not** to invent the API surface. Do **not** emit a guessed +tag, class, package name, property, method, event, CSS part, or theming variable. A plausible-but-wrong +name that a reader copies is worse than an obvious gap. + +- Use an identifier **only** when it is verified — from the component's typed API source, an existing + topic, or the user. The naming patterns are known (Angular `igx-` / `IgxComponent`; WC and + its React/Blazor wrappers `igc-` / `IgcComponent`), but the pattern is not a licence to + guess — confirm the exact prefix *and* `` per component (some Angular topics are `igc` — see the + exception above). +- When you must reference an unverified identifier, write a visible placeholder instead of a guess: + `‹VERIFY: exact export name›`. For a table, emit the fixed column headers and a single injection note + — invent no rows. +- This applies equally to React/Blazor wrapper symbols: they resolve to the `igc` core, so prefer the + verified `igc` usage and mark any wrapper-specific class you can't confirm with `‹VERIFY:…›`. +- **`` targets are identifiers too.** A `type` that exists in the source is not enough — it + must have a generated reference page, and the only reliable check is an existing `` with that + `type` elsewhere in the doc set. Abstract/base classes in particular (e.g. `ButtonBase`) may appear in + `mentionedTypes` yet have no page — the rendered link (e.g. `IgrButtonBase`) points nowhere. Link base-class + members through the concrete component instead (`type="Button" member="href"`), and list only the concrete + component under **API References**. + +## Verification workflow + +Use this checklist when creating technical content or auditing an existing topic. Audit mode reports +verification gaps; it does not edit the topic. Existing topic prose and snippets are evidence to check, +not a source of truth. + +1. **Identify the target platform.** Angular/native `igx`, Web Components `igc`, React, or Blazor. +2. **Verify public API facts through MCP first.** Use the Ignite UI/API docs MCP source for component + types, properties, methods, events, and API-link targets. +3. **If MCP is unavailable, use the official platform API docs.** + - React: `https://www.infragistics.com/api/react/` + - Web Components: `https://www.infragistics.com/api/webcomponents/` + - Blazor: `https://www.infragistics.com/api/blazor` +4. **Use typed source only for details the API docs do not expose.** Examples: rendered DOM, slots, + parts, key handlers, theme `.scss` `@param` comments, precedence rules, and deprecation markers. +5. **Use official framework docs for framework behavior.** Examples: Angular standalone defaults, + control-flow syntax, React conventions, and Blazor conventions. +6. **Mark unresolved facts visibly.** Use `‹VERIFY: exact fact/source needed›` or flag the issue in the + audit report; never replace uncertainty with a plausible claim. + +Authored fenced code snippets follow the same verification order. Live `` embeds are separate: +verify `src`, `alt`, and display props in the topic, but report sample-code problems as upstream sample +project work. + +## Component topic — canonical section order + +Required = every component topic, always this order. Conditional = only when relevant, but always in +this slot. **These names are the only allowed H2s.** Anything feature-specific becomes a sub-heading +under **Usage**, never a new top-level section. + +| # | Section (`##`) | Required? | Diátaxis mode | Contents | +|---|---|---|---|---| +| 1 | *Title + one-line definition* (`#` + lead ¶) | required | orient / reference | H1 is **`‹Component› Component`** — **no** framework prefix, **no** "Overview" suffix (the framework lives in the SEO `title`). Follow with one plain sentence: what it is, what problem it solves. Mirror `llms.description`. | +| 2 | *Live Demo* | required | demonstration (action) | `` of the simplest useful state near the top of the page, before **Anatomy**. | +| 3 | **Anatomy** | required for component topics | orientation (reference) | Opens with a screenshot/GIF of the component's parts or the behavior being shown, then the **DOM tree / skeleton** (rendered elements, parts, slots). If the visual asset doesn't exist yet, leave a `{/* TODO */}` marker rather than a broken image, but still include the section and verified skeleton. | +| 4 | **Getting Started** | required | how-to | **Lead with the component-specific import/registration** — the page-unique, high-value part. Compress the generic library install to a **single prerequisite line linking the general getting-started topic** (an inline `ng add igniteui-angular` as a parenthetical is fine); **don't** repeat the multi-sentence install boilerplate that is identical on every component page. Show the **current** registration (standalone import) first; put legacy NgModule **after**, marked as legacy. | +| 5 | **Usage** | required | how-to + explanation | Start with `### Basic Declaration`, showing the smallest valid component markup for each platform. Then add property-focused sub-sections that showcase every public input with a minimal snippet and, when a verified demo exists and adds visual value, a ``. Give standalone properties their own sub-section (`Shape`, not `Avatar Shape`); group only tightly coupled properties that form one behavior (for example, content-source priority such as `src`, `alt`, `initials`, and default slot content). The final Usage subsection must be `### Do/Don't`; it uses inline **When to use:** and **When not to use:** labels, not nested headings. Styling content belongs in **Styling**, not here. | +| 6 | **Properties** | required | reference | Table: name · type · default · description. (Replaces "Configuration".) | +| 7 | **Methods** | conditional | reference | Table of callable actions. | +| 8 | **Events** | conditional | reference | Table of emitted events. | +| 9 | **Styling** | required when applicable | how-to + reference | **Open with a `` of the styled result** + one intro line, then the **Styling Variables table** (**one table** — variable · what it changes; **no default-value column, no per-theme tabs**) and styleable-parts table. Subsections cover each approach — **first `### Sass Theming`** (the primary Sass theme workflow), then others (e.g. `### Tailwind`, `### Custom sizing`). All styling content lives here, not under Usage. | +| 10 | **Accessibility** | required | reference | Three sub-sections, in order: **Keyboard Interaction** (key→action table), **Screen Readers / ARIA**, **Accessibility Compliance** (conformance evidence — see the sub-structure spec below). | +| 11 | **Troubleshooting** | conditional (required when version-migration or legacy-setup notes exist) | how-to | Gotchas phrased as the reader's real question; answer as cause → fix. **Collect version-migration notes, deprecations, and legacy/alternative approaches here** — not buried in code-fence comments or scattered asides. | +| 12 | **API References** | required | reference | `` out to the full generated reference; don't duplicate it. | +| 13 | **Dependencies** | conditional | reference | Themes, styles, or supporting components the component relies on to render or function — modules to import (Angular) or supporting components/themes (xplat). (Currently "Theming Dependencies".) | +| 14 | **Additional Resources** | required | navigation | Forums, GitHub, related topics. | + +**When Not to Use trigger:** every component topic ends **Usage** with `### Do/Don't`. This subsection +must include inline **When to use:** and **When not to use:** labels, not nested headings. When +`relatedComponents` is non-empty, **When not to use:** must name the specific better-fit sibling(s) +by name and link them; when it's empty (standalone primitives like Badge/Divider), **When not to +use:** states the boundary without inventing a sibling. + +**Reference-table contract:** Properties / Methods / Events tables are **generated from the same typed +API source** as the full reference — not hand-typed. Inline tables = the core knobs for fast scanning; +**API References** links to the complete set. One source, so nothing drifts. **When authoring, do not +hand-write or invent rows:** emit the fixed column headers (`name · type · default · description`) and a +single build-injection note, and leave the row values to the generator. Inventing a plausible property +or event name is exactly the failure this contract exists to prevent. + +**Usage coverage contract:** begin with `### Basic Declaration`, then use property-focused +sub-sections to demonstrate every public input. Prefer one sub-section per standalone property; group +properties only when they are inseparable in real use or define a shared precedence/behavior. Each +sub-section should include a minimal, copyable snippet for every platform it affects. Add a +`` only when the demo path is verified and the visual result teaches something the snippet +alone does not. + +**Live-sample contract:** exactly one top preview; add Usage samples only for distinct, +user-facing tasks or property-focused behaviors (selection, editing, sorting, validation, +templating, styling, shape, content, sizing). Soft max **10 samples/page**; up to 10 is fine, and +only clear sprawl past that warrants splitting into focused topics. + +### `` configuration — pick the props deliberately + +`` renders a live demo (iframe + source-code tabs + live-edit buttons). **`src` is required and must +point at a real demo path** — treat it like any other identifier under the zero-risk rule: never invent or +guess a `src`, an `lob`/`dv`/`crm` base, or a path; use one only when it's verified from the sample project +or an existing topic, else leave a `‹VERIFY: demo path›` marker. Never hand-edit the demo's code — that lives +in the separate sample project. + +Choose the display config from **what the sample is showing**, not by habit: + +| Prop | Default | Use it when… | +|---|---|---| +| `src` | — (required) | Always. Relative demo path. | +| `alt` | — | **Always** — the iframe title for accessibility. A missing `alt` is an audit finding (E1). Describe the demo, e.g. `alt="Angular Calendar range selection"`. | +| `height` | `400` | The demo's natural height isn't ~400px. Match the content. **Mutually exclusive with `fitContent`** — set one or the other, never both. | +| `fitContent` | off | The component is small or variable-height (badge, chip, avatar, icon, switch), **or a compact standalone sub-view** (e.g. a calendar days/months/years view), and a fixed frame would waste or clip space. The iframe grows to the component's own height, so **do not also set `height`** — drop it entirely. Ignores `resizable`. | +| `iframeOnly` | off | The **result** is the point and the source isn't instructive — purely visual demos, or a Styling preview whose styling is applied upstream (not in copyable code). Drops the code tabs/footer. Keep the tabs when the code *is* the lesson (e.g. a Sass `calendar-theme` snippet). | +| `fullscreenBtn` | off | Paired with `iframeOnly` for large/complex visual demos that benefit from full-screen. | +| `resizable` | off | Responsiveness is the lesson (grids, layout, splitter, dock manager) — lets the reader drag the width. Ignored with `fitContent`. | +| `position` | — | A small component would otherwise sit in the top-left; align it (`center`, etc.). | +| `spacing` | — | The demo needs breathing room around the iframe (`sm`/`md`/`lg` = 8/16/32px). | +| `noBorder` | off | The default border competes with the demo visually. Cosmetic — use sparingly. | +| `lob` / `dv` / `crm` | default base | The demo lives in the LOB, Data-Viz, or CRM demos app rather than the default — **verify before setting**. | + +Defaults are right for most Usage samples: ``. Reach for the extra props +only when the component type calls for it — the top preview and standard task demos keep the code tabs (no +`iframeOnly`); the **Styling** section still opens with a styled-result ``, using `iframeOnly` only +when its styling isn't shown as copyable code. + +### Accessibility — required sub-structure + +`## Accessibility` always carries three `###` sub-sections, in this order. All three are **reference** +mode: statements of fact in tables and short lists — no steps, no marketing. + +1. **`### Keyboard Interaction`** — one key → action table, verified against the component's key + handlers. Note how the component is reached (Tab) and any condition that removes it from the tab + order. +2. **`### Screen Readers / ARIA`** — the roles, `aria-*` attributes, and announcements the component + provides (from source), plus what the reader must supply (e.g. `aria-label` when the visible + content doesn't describe the action). +3. **`### Accessibility Compliance`** — the conformance evidence, in this shape: + - **Lead sentence** naming the conformance target (WCAG version + level; Section 508 / EN 301 549 + where applicable). This is a product-level claim — state it only from an official Infragistics + statement; otherwise write `‹VERIFY: conformance target›`. + - **Conformance table** — two columns: **Criterion · How the component complies**. List only the + WCAG success criteria *relevant to this component*, each row grounded in behavior already + verified on this page (the keyboard table, the ARIA facts, the typed source). Link each + criterion to its WCAG Understanding page. Common criteria to pick from: + 1.3.1 Info and Relationships (roles/structure) · 1.4.1 Use of Color (states not conveyed by + color alone) · 1.4.3 Contrast (Minimum) (default themes) · 1.4.11 Non-text Contrast · + 2.1.1 Keyboard + 2.1.2 No Keyboard Trap (full keyboard operability) · 2.4.3 Focus Order · + 2.4.7 Focus Visible (focus ring) · 2.5.7 Dragging Movements (every drag interaction needs a + keyboard/single-pointer alternative — splitter, slider, dock manager) · 2.5.8 Target Size + (Minimum) · 4.1.2 Name, Role, Value · 4.1.3 Status Messages (components that announce — toast, + snackbar, progress). Omit irrelevant criteria entirely — no "N/A" filler rows. + - **Your responsibilities** — a short list of what the app author must still do for the page to + conform: provide the accessible name, keep sufficient contrast when overriding themes, preserve + a logical focus order in the surrounding layout, keep minimum target sizes when custom-sizing. + Cross-link the Usage/Styling sections that show *how* — don't repeat the steps here. This split + (what the component guarantees vs what the reader owes) is the highest-value content of the + sub-section for both humans and AI assistants. + - **Known exceptions** *(only when real)* — criteria the component doesn't fully meet, each with + its workaround or tracking link. An honest, specific gap beats a silent one. + - **Validation & resources** *(optional, verified only)* — the screen reader / AT combinations the + component is tested with, and links to the product accessibility statement / VPAT and the + matching [WAI-ARIA Authoring Practices](https://www.w3.org/WAI/ARIA/apg/patterns/) pattern. + Omit when unverified — never invent a testing matrix. + + Compliance claims are the highest-risk statements on the page — they carry legal weight, and a + wrong one is copied into the reader's own conformance report. The zero-risk rule applies at full + strength: no blanket "fully accessible" / "WCAG compliant" sentence, ever; every table row traces + to observable, verified behavior; product-level claims come only from an official source. + +## Overview topics + +**5a. Concept / guide overview** (Diátaxis: *explanation*) — e.g. "Theming concepts": +Title + intro → **Overview** → **Before You Start** → **Next Steps** → **Available Tools** → +**Common Workflows** → **Troubleshooting** → **Additional Resources** → optional **FAQ**. Use an +accordion for FAQ content when a compact question-and-answer block is useful. + +**5b. Category / index overview** (Diátaxis: *reference/navigation* — a map) — e.g. "Charts overview": +Title + intro → **Key Features** → **Types** (identical micro-structure per entry: one-line def + link + small +``) → **Next Steps** → **API References / Additional Resources**. + +Guardrails: cap each section at ~3 short paragraphs (else add sub-sections); isolate marketing copy in +a single "Why {ProductName}" section — never thread it through instructional content. + +## Naming reconciliation (drift → standard) + +| Seen in the wild | Standard name | +|---|---| +| "Angular X Component Overview"; "X Component Overview"; "{Platform} X Component Overview" (H1) | **`X Component`** (H1 — drop framework + "Overview") | +| Setup; "Getting Started with…"; "Getting Started with Ignite UI for Angular X" | **Getting Started** | +| Code Snippet; Examples; "Using the … Component"; "{Platform} X Example"; "Angular X Example" | **Usage** | +| "Avatar Shape"; "‹Component› ‹Feature›" (Usage sub-heading) | **`‹Feature›`** (drop the component name) | +| Configuration | **Properties** | +| "X vs Y"; "Choosing Between X and Y"; Behavior; Feature Integration | **Do/Don't** (as the final `###` under **Usage**) | +| top-level `## When to Use` / `## When Not to Use`; `### When to Use` / `### When Not to Use`; **When to Use / When Not to Use nested under `## Anatomy`** | Inline **When to use:** / **When not to use:** labels inside the final **Usage** subsection, `### Do/Don't` | +| Summary (as lead-in) | intro ¶ or **Overview** | +| Keyboard Navigation | **Accessibility** | +| WAI-ARIA Support; Compliance; Section 508; Accessibility Statement | **`### Accessibility Compliance`** (under **Accessibility**) | +| Best Practices; Do's and Don'ts; Guidelines; Recommendations | **Do/Don't** (as the final `###` under **Usage**) | +| Theming (H2) | **Styling** (H2); the Sass approach becomes `### Sass Theming` under it | +| Known Limitations; Known Issues and Limitations; Limitations | **Troubleshooting** | +| API; API Reference (singular) | **API References** | +| Theming Dependencies | **Dependencies** | + +## Write-for-both-audiences rules (people + AI assistants) + +1. **One job per section** — self-contained; no "as mentioned above." A section must make sense landed-on cold. +2. **Lead each section with one plain, specific sentence** before any table/code — skip empty boilerplate. +3. **Use the standard section names everywhere** — "Accessibility" always means the same thing. +4. **Phrase guidance/troubleshooting as real questions** — When-Not-to-Use is the highest-value content for answer accuracy; name the sibling explicitly. +5. **Reference lives in tables**, generated from the typed source. +6. **Strong `description` / `llms.description`** — <~160 chars, answer-shaped. +7. **Document theming variables** — variable · what it changes, in **one table for all themes**. No default-value column: defaults are per-theme values that live in the generated API reference, not the topic. + +## Formatting & altitude + +- **No divider hugging a block.** Never place `
` or `` directly before or after a + ``, code fence, or table — those blocks carry their own separation. Dividers separate + *prose* sections only; in practice a topic rarely needs them at all. +- **Single item ⇒ paragraph.** A `ul`/`ol` with one item is a paragraph. Use a list only for two or + more parallel items. +- **Current API first, legacy after.** Show the current/recommended approach first (e.g. the + standalone component import); place deprecated/legacy approaches (NgModule) *below* it, explicitly + marked as legacy — never above the current one. +- **Don't repeat the generic install boilerplate.** The `ng add igniteui-angular` + "read the getting + started topic" prose is identical on every component page — collapse it to a **one-line prerequisite + link** and lead Getting Started with the component-specific import instead. This mirrors how the major + component libraries (Angular Material, MUI, Ant Design, PrimeNG) work: install lives in one central + page; each component page shows only its own import. Keep the prerequisite as a single linked line + (optionally with an inline `ng add` token) so a cold-landing reader or AI still has the pointer — just + not the repeated paragraph. +- **Styling leads with the result.** The Styling section opens with a `` of the styled + outcome, then the tables; its first subsection is `### Sass Theming` (the Sass theme workflow), then + the other approaches (`### Tailwind`, `### Custom sizing`, …). +- **One styling table — never per-theme tabs, never default values.** In the `theming` repo every + theme schema `extend`s the same base schema and only overrides *values* (e.g. `$material-switch`, + `$fluent-switch`, `$indigo-switch` all extend `$light-switch`; `$bootstrap-switch` extends + `$fluent-switch`), so **every theme exposes the identical variable set** — only the defaults differ. + Per-theme tabbed tables (the legacy `.theme-switcher-wrapper` / `.theme-table` markup) therefore + document a difference that doesn't exist; replace them with **one two-column table: + variable · what it changes**. Don't add a defaults column either — defaults vary per theme and + belong to the generated API reference, and the durable content is the variable's name and effect. +- **Audit & modernize inline code snippets — not the samples.** Fenced code blocks (` ```… ``` + `) are authored in the topic, so verify and update them: no deprecated APIs or outdated framework + idioms (drop `standalone: true`; prefer Angular's built-in control flow `@if`/`@for` over + `*ngIf`/`*ngFor`; use verified imports, selectors, and tags). The live **``** embeds render + from the separate sample project — **never hand-edit their code**; fix those upstream. The only + intentionally "old" snippets are the legacy ones quarantined in **Troubleshooting**. +- **Omit `standalone: true` (Angular).** Components are standalone by default since Angular v19 + (igniteui-angular targets far newer), so it's redundant in examples — don't write it. Show + `standalone: false` only when illustrating the legacy NgModule path (in Troubleshooting). +- **Version & legacy notes live in Troubleshooting.** Don't bury "prior to vX use…" migration notes + in code-fence comments, and don't scatter legacy/alternative setup (e.g. NgModule) across the page. + Collect them in **Troubleshooting**, each phrased as question → cause → fix. Getting Started and + code samples show only the current, recommended path. +- **Curated (not generated) reference tables — for now.** No build-time generator injects inline + Properties/Styling-Variables tables yet (only the full API reference is generated, reached via + ``). Until one exists, hand-author a **small core** table whose every row is **verified + from source** (typed component for props; the `@param` doc-comments in the component's + `_…-theme.scss` for styling vars) and link `` for the complete set. The zero-risk rule + still applies: no unverified rows. + +## Voice & tone + +Write instructions the same way across every topic so readers (and assistants) get one predictable voice. + +- **Imperative, second person, present tense.** "Set the `shape` attribute…", "Import the component…" — not "we create…" or "the developer should…". Address the reader as *you* only when needed for clarity. +- **One voice per topic.** Don't mix imperative how-to with first-person-plural narration ("we create") or tutorial hand-holding. Reference sections (Properties/Styling tables, Accessibility) stay descriptive. +- **Specific over vague; cut filler.** Name the exact attribute, value, or behavior. Drop "simply", "just", "in order to", "as you can see", and empty lead-ins. +- **No marketing in instructional prose.** Keep promotion out of how-to/reference; overview topics isolate it in a single "Why {ProductName}" slot. +- **Name features by their real Ignite UI identifier** (e.g. `igx-icon`, not "material icon") and cross-link the topic. + +## Verify every claim against the component + +The zero-risk rule is not limited to identifiers — **every statement of fact must be verified against the actual component before it ships or is recommended as an edit.** This includes defaults, value ranges, precedence/fallback behavior, version support ("since vX"), deprecations, emitted events, and rendered DOM. + +- **Source of truth:** follow the **Verification workflow** above. Public API facts come from MCP + first, then the official platform API docs. Typed source is for implementation details the API docs + do not expose. Existing docs and snippets are never sufficient proof by themselves. +- **When recommending edits, verify first.** Never "correct" prose into a plausible-sounding claim you haven't checked — a confident wrong statement is worse than the original. +- **If you can't verify it, don't assert it.** Write `‹VERIFY: …›` or leave the existing text and flag it — never guess a default, a version, or a behavior. +- Behavioral claims that read fine but contradict the source (e.g. "the image falls back to initials on load error" when the code only sets precedence) are exactly what this rule catches. diff --git a/.claude/skills/igniteui-doc-topics/SKILL.md b/.claude/skills/igniteui-doc-topics/SKILL.md new file mode 100644 index 0000000000..479d47443e --- /dev/null +++ b/.claude/skills/igniteui-doc-topics/SKILL.md @@ -0,0 +1,26 @@ +--- +name: igniteui-doc-topics +description: >- + Author or audit Ignite UI documentation topics: component pages, how-to guides, conceptual + overviews, and category indexes for both the Angular doc set and the cross-platform React / Web + Components / Blazor doc set. Use this whenever someone asks to write, draft, create, review, audit, + fix, or standardize a documentation topic, tutorial, guide, reference page, or concept overview for + Ignite UI. +--- + +# Ignite UI doc topics adapter + +This is a Claude adapter for the canonical repo-local skill. + +Before doing any task actions, read and follow the canonical skill at: + +`../../../.ai/skills/igniteui-doc-topics/SKILL.md` + +Resolve every canonical reference path relative to that canonical skill directory: + +- `../../../.ai/skills/igniteui-doc-topics/references/diataxis-cheatsheet.md` +- `../../../.ai/skills/igniteui-doc-topics/references/house-style.md` +- `../../../.ai/skills/igniteui-doc-topics/references/audit-rubric.md` + +Do not treat this adapter as a separate source of rules. If this adapter conflicts with the canonical +skill, the canonical `.ai` skill wins. diff --git a/.codex/skills/igniteui-doc-topics/SKILL.md b/.codex/skills/igniteui-doc-topics/SKILL.md new file mode 100644 index 0000000000..f55d37c3fd --- /dev/null +++ b/.codex/skills/igniteui-doc-topics/SKILL.md @@ -0,0 +1,26 @@ +--- +name: igniteui-doc-topics +description: >- + Author or audit Ignite UI documentation topics: component pages, how-to guides, conceptual + overviews, and category indexes for both the Angular doc set and the cross-platform React / Web + Components / Blazor doc set. Use this whenever someone asks to write, draft, create, review, audit, + fix, or standardize a documentation topic, tutorial, guide, reference page, or concept overview for + Ignite UI. +--- + +# Ignite UI doc topics adapter + +This is a Codex adapter for the canonical repo-local skill. + +Before doing any task actions, read and follow the canonical skill at: + +`../../../.ai/skills/igniteui-doc-topics/SKILL.md` + +Resolve every canonical reference path relative to that canonical skill directory: + +- `../../../.ai/skills/igniteui-doc-topics/references/diataxis-cheatsheet.md` +- `../../../.ai/skills/igniteui-doc-topics/references/house-style.md` +- `../../../.ai/skills/igniteui-doc-topics/references/audit-rubric.md` + +Do not treat this adapter as a separate source of rules. If this adapter conflicts with the canonical +skill, the canonical `.ai` skill wins.