## TL;DR
Close the tag or escape it as literal text. MDX treats anything shaped like an HTML tag as a component, so prose containing angle-bracket-looking text must be escaped or fenced.

## Error
```text
Error: MDX compilation failed: Expected corresponding JSX closing tag
```

## Steps
1. Read the MDX error; it names the file and line with the unclosed tag. Expected: the offending line located.
2. If the tag was meant as a component, add its closing tag. If it was prose (e.g. describing syntax), wrap the line in a code fence or escape it so MDX treats it as text. Expected: MDX no longer parses it as a component.
3. Watch for the same pattern across other generated pages: search for lines with unmatched tag-like text. Expected: no sibling pages with the same flaw.
4. Rebuild with `npm run build`. Expected: MDX compilation succeeds.

## When to use
- MDX compilation fails on an unclosed or unexpected tag
- A docs agent wrote prose containing tag-like text
- Code samples were pasted as prose instead of fenced blocks

## When not to use
- The tag is closed but the component is undefined (import it or remove it)
- The error is a duplicate route or sidebar problem
- Plain Markdown pages fail (not an MDX issue)

## Tool compatibility
Docusaurus 2.x and 3.x MDX handling. The rule is the same in both.

### Variant phrasings
### MDX error on a code sample showing HTML
Fence the sample as a code block; MDX never parses tag syntax inside fences.

### agent keeps generating unclosed tags
Add a lint step (e.g. an MDX check) to the agent's write loop before the build.

## Why it happens
MDX is Markdown plus JSX, so any tag-shaped text in prose becomes a component reference. Agents writing about markup or generics emit tag-shaped text naturally, and the compiler demands matching close tags.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_GEoPLAH-nJxz0pmyPLmA3w