Skip to content

Fix "uses unknown component" (DS-S06)

reed check rejects a component name that is not in the catalog. Fix the spelling, set the dialect, or import it.

reed check or reed build stops with a line like this:

txt
✗ [DS-S06] content file "guides/setup.mdx" uses unknown component "Tooltips" (not a catalog member and not locally imported)
check failed.

The quoted name is the tag exactly as you wrote it. The page itself looked fine in your editor, and the same markup may have rendered on the platform you migrated from.

Reed ships a fixed catalog of 37 components, and every capitalized tag on a page must be one of them — or be imported by that page. Anything else is DS-S06, an error that fails both check and build. Reed refuses it deliberately: an unknown tag would otherwise publish as broken or empty markup.

Three things produce it:

  • A typo or wrong case. Tooltips, Codegroup, Accordian. Names are case-sensitive.
  • A component from another platform. Mintlify’s RequestExample or ResponseExample, for example, have no Reed equivalent and are unknown under every dialect.
  • An alias that only exists under a dialect. Fern’s Cards, StepGroup, TabGroup, Code, CodeBlocks and the StickyTable / SearchableTable / PaginatedTable family resolve to catalog components only when content.dialect is "fern". Under the default "reed" dialect — and under "mintlify" — they are unknown.

Lowercase tags such as <img> or <div> are treated as HTML and never reported by this check.

These are the only names Reed accepts without an import:

txt
Accordion AccordionGroup Aside Badge Banner Callout Card CardGroup Check
CodeBlock CodeGroup Columns Danger Error Expandable File Files Folder Frame
Icon Info Launch Note Panel ParamField ResponseField Step Steps Success
Tab Table Tabs Tiles Tip Tooltip Update Warning

If yours is a misspelling of one of these, correct it. The component reference documents each one’s props and children.

If the page came from Fern and uses Fern names, declare that in docs.json instead of renaming every tag:

json
{ "content": { "dialect": "fern" } }

The dialect is project-wide. Set the one your MDX was written in — see Content dialect. With a dialect set, a component the upstream platform has but Reed does not is reported with its own message instead of DS-S06:

txt
✗ [unsupported-upstream-component] content file "guides/setup.mdx" uses "Prompt", which is unsupported under content.dialect "fern": An AI-assistant chat-prompt widget with no reed equivalent; out of scope per design assumption 12

That one cannot be fixed with configuration. Replace the component.

Pick the nearest catalog component, or plain Markdown, and rewrite the markup. A Mintlify RequestExample wrapping a request, for instance, becomes a plain fenced block at the top level of the page:

mdx
```sh
curl https://api.example.com/v1/items
```

Content that should stay visible while the reader scrolls goes in an Aside. Several language variants of the same snippet go in a CodeGroup, one fence per tab — see Format code.

Names differ between platforms more often than capabilities do.

If you genuinely need something outside the catalog, a local import is the escape hatch. Check the catalog first. A page-local import exempts that name from the check:

mdx
import MadeUpWidget from './widget.astro';
<MadeUpWidget foo="bar" />

reed check only reads the imported name from the import statement. It does not confirm the file exists or compiles, so a broken import passes check and fails later, in reed build. An imported component also gets none of the catalog’s contract checks, so a missing prop on it is never reported. See MDX pitfalls for when to reach for it.

Run the check again and confirm no DS-S06 lines remain:

sh
reed check 2>&1 | grep -c 'DS-S06'

Expect 0. A clean project ends with check passed. If you fixed the name by setting a dialect, read the rest of the reed check output too: the dialect also changes how props on every other page are read, and a new DS-S03 or DS-D08 elsewhere is how that shows up.