菜单
Reference guide for adding, fixing, and auditing ApiLink components in xplat MDX using the generated api-docs registry. Covers clean ApiLink props, pkg/kind disambiguation, member checks, PlatformBlock use, and registry reports.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
基于 SOC 职业分类
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/IgniteUI/igniteui-documentation --skill xplat-docs-api-links命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| name | xplat-docs-api-links |
| description | Reference guide for adding, fixing, and auditing ApiLink components in xplat MDX using the generated api-docs registry. Covers clean ApiLink props, pkg/kind disambiguation, member checks, PlatformBlock use, and registry reports. |
| user-invocable | true |
Use unprefixed TypeDoc names and let the registry resolve package, kind, prefix, suffix, URL, and member anchors:
<ApiLink type="Grid" />
<ApiLink type="Grid" member="rowSelection" />
<ApiLink type="CategoryChart" />
type: required unprefixed symbol name.member: optional member/property/method/enum value.label: optional display text.pkg: disambiguation only. Add it when check-mdx-links reports that the same symbol exists in multiple packages.kind: use for Sass (kind="sass") or when the registry report proves a TypeDoc symbol needs narrowing.Do not add exclude, excludePrefixFor, or excludeSuffixFor.
Avoid adding prefixed={false} or suffix={false} in new MDX. Those are legacy
fallback overrides, not the normal registry-based workflow.
Use PlatformBlock only when the visible content or actual API symbol differs by
platform:
<PlatformBlock for="Angular">
<ApiLink type="IGridState" />
</PlatformBlock>
<PlatformBlock for="React,WebComponents,Blazor">
<ApiLink type="GridState" />
</PlatformBlock>
Do not use PlatformBlock just to work around prefix/suffix/package URL rules.
Those should be handled by the registry or by pkg disambiguation.
Run registry checks before making manual API-link assumptions:
npm run check-mdx-links:broken:angular
npm run check-mdx-links:broken:react
npm run check-mdx-links:broken:wc
npm run check-mdx-links:broken:blazor
Interpret common statuses:
missing: the symbol was not found in the latest platform registry.member-missing: the symbol exists, but the requested member was not found.ambiguous: the symbol exists in multiple packages; add pkg.dynamic: the link uses a template value such as {ComponentName} and cannot be resolved statically.sass: Sass links are intentionally outside the TypeDoc registry.For member-missing, inspect the registry before editing. Some APIs expose
platform-specific member names, for example React dataSource versus older
source prose that says itemsSource.
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. For frontmatter-only audits or metadata normalization, use
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. For frontmatter-only audits or metadata normalization, use
Audit and normalize YAML frontmatter metadata for Ignite UI MDX documentation topics. Use when a task mentions frontmatter, SEO titles, meta descriptions, llms.description, keywords, canonical links, relatedComponents, mentionedTypes, license, metadata uniformity, or AI-readable page identity in Ignite UI Angular or xplat documentation topics. This skill is strictly frontmatter-only: audit first and provide suggestions for the user to choose from before changing anything; never edit topic body content, headings, prose, samples, code snippets, links, tables, or section structure. For anything touching body content, structure, headings, prose, or samples, use the companion igniteui-doc-topics skill instead.