First-class support for "Mantine Style" LLM output guideline ? (lint rules, post-tool hook based closed-loop, etc)

[sungpaks]

Hi, thanks for the amazing library, I love to use Mantine.
I'm using Mantine everyday, very effectively - especially lately, building a design system through the theme system, and having the LLM write or modify UI code within Mantine(or my Mantine-based design system).

What I'm struggling with

When using LLMs, to generate or modify Mantine UI code, the output often violates Mantine's styling guidelines/philosophy even if we explicitly instruct "follow Mantine guidelines" - even I give detailed context or using context7 mcp, etc.
The most common issues:

1. Overuse of inline styles ( style={{}} ) for things that are already covered by Mantine props (e.g. p, m, fz, fw, pos, top/left, radius, ...)
2. Re-implementing existing components: e.g. using Box + radius/border(inline style props) instead of Paper/Card , or Flex with custom gaps/directions instead of simply using Stack/Group
3. Inconsistent styling priority & patterns: human developers follow conventions, and know what props are possible in which components. But LLMs don't reliably know which props are avilable per component(and they differ slightly by component), which leads to style drift and non-idiomatic code.

We already trying to mitigate some of this with custom ESLint rules + PostToolUse claude hooks, etc.
But it would be extremely helpful if Mantine offered official, Mantine-aware tooling, as first-party.

Proposal

this proposals are just an example solutions. If anyone has better idea, I'll appreciate it.

A) Official ESLint Plugin / ruleset

• Prefer Mantine style props (p, m, ..) over inline style(styles={{}})
• Prefer idiomatic Mantine components: Paper, Card, Stack, .. layout components, etc.
• even styles api support?
• Component-prop awarness: e.g. which components can use radius props, or not.

I've seen that the Tailwind CSS providing a lint warning (I think it might have been a VSCode extension) saying, "You can use this instead".

B) LLM Closed-Loop integration hook(or skills, something)

• Provide an official hook point / integration guide (e.g. PostToolUse, post-generation step, ..)
  • reporting violations back to the model, and suggesting revisions

This would drastically reduce review time and ensure generated code remains consistent with Mantine’s philosophy.

---

I think this, something like automation tooling methods, could make Mantine + LLM integration even better.

Thanks again for the great work on Mantine and for maintaining such a thoughtful library.

I'm also happy to hear any other thoughts, feedback, or other ideas around improving Mantine + AI usage experiences and integrations. Thanks!

[Suomipoika]

Anthropic updated their skill-creator and I think mastering that would benefit greatly.
Like @sungpaks said skill that is definitely needed is one doing inline styling & desiciding when to use css modules.
Without always creating huge example suite myself, LLM's struggle quite definetly.

Anthropic updated their skill-creator and I think mastering that would benefit greatly.
There is now more ways to control when this skill should trigger and when not.
It can also sense when skill description is too generic and LLM thinks it knows the stuff and will not load the skill in use.
point of the skills is after all to be automatic not force you to explicity use them.
https://claude.com/blog/improving-skill-creator-test-measure-and-refine-agent-skills

[jimenez-alex]

Official ESLint Plugin / ruleset would be preferred, AI tools are nice, but the agents keep ignoring rules here and there

[sungpaks]

The point is not to prevent agents from ignoring the rules. The point is to provide immediate, automatic feedback when agents break the rules.
Like people (Andrej Karpathy, etc.) say about "closed feedback loop". ex: agents work -> sometimes ignore rules -> immediate feedback by tools like lint -> agent can know "ah, I have to fix it"