[docs] Add agent skills for styling, theming, Next.js, and Tailwind CSS integrations

[mapache-salvaje]

This PR adds a batch of 4 agent skills to the repo based on some of the most common issues that users face:

• styling: when to choose sx prop vs global styles vs theme
• theming and design tokens
• Next.js integration
• Tailwind CSS integration

The style and structure mirrors that of Vercel's collection of agent skills, but I'm not married to those particulars.

I tested these by creating a spec for a full-fledged internal dashboard with requirements that would lead an LLM to face issues if they don't have context about the list items above. I gave the spec to multiple agents, with and without access to the skill files, and had them build out MVPs. Those without the skill files frequently got stuck on common expected issues and took significantly longer to get an app running than those with the skill files, which were able to avoid those pitfalls entirely. When the skill-less LLMs were given the skills after the fact, they confirmed that the additional context would have been useful.

In one instance, an LLM tripped over the Next.js integration as it relates to Suspense, so I had it suggest improvements we could make to the Next.js integration page so others might avoid that issue. I've included that in this PR as well.

[mui-bot]

Netlify deploy preview

• docs/data/material/integrations/nextjs/nextjs.md

Bundle size report

Bundle	Parsed size	Gzip size
@mui/material	0B(0.00%)	0B(0.00%)
@mui/lab	0B(0.00%)	0B(0.00%)
@mui/system	0B(0.00%)	0B(0.00%)
@mui/utils	0B(0.00%)	0B(0.00%)

Details of bundle changes

Generated by 🚫 dangerJS against 634f180

[siriwatknp]

Suggested change

	That wraps MUI output in `@layer mui` so anonymous layers can override as intended. See [Next.js integration—Using other styling solutions](https://mui.com/material-ui/integrations/nextjs/#using-other-styling-solutions) and [MDN—@layer](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/At-rules/@layer).
	That wraps MUI output in `@layer mui` so anonymous layers can override as intended. See [Next.js integration—Using other styling solutions](https://mui.com/material-ui/integrations/nextjs.md#using-other-styling-solutions) and [MDN—@layer](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/At-rules/@layer).

I recommend using .md directly when refering to our docs. Here is why (regardless of how the model get the data, .md is very much better):

Compared fetching the same MUI docs section via two URL forms:

1. https://mui.com/material-ui/integrations/nextjs.md#using-other-styling-solutions
2. https://mui.com/material-ui/integrations/nextjs/#using-other-styling-solutions

Raw fetch (curl)

Metric	.md	HTML	Ratio
HTTP	200	200 (redirect)	—
Bytes	13,630	319,506	23.4× larger
Words	1,472	13,879	9.4× larger
Fetch time	0.51s	1.31s	2.6× slower
Content-Type	text/markdown	text/html	—

HTML bulk = framework markup, scripts, nav chrome. Not content.

WebFetch (HTML→MD→small model)

Same section extracted via WebFetch with identical prompt.

Aspect	.md	HTML
Output chars	621	681
Code fence lang (js)	preserved ✅	dropped ❌
Prose paragraphs	clean ✅	wrapped in "…" ❌
Heading	✅	✅
Code snippet	✅	✅
MDN link	✅	✅
Fidelity artifacts	0	2

Fidelity

• .md: 100% — verbatim, renders correctly
• HTML: ~90% — semantically intact, formatting corrupted (spurious quotes + lost js breaks downstream syntax highlighting)

Verdict

Prefer .md URLs. Wins on:

• Size — 4% of HTML payload
• Speed — 40% of HTML latency
• Fidelity — no formatting artifacts even through WebFetch's small-model pipeline
• Cost — fewer tokens if piped to another LLM

HTML route strictly worse for LLM consumption.