Gemini

1. Foundation Recommendation: Migrate to a "Source-Owned" Model

Recommendation: Abandon the monolithic dependency model for these 6 components.

Keeping Ant Design for just 6 complex components creates "split-brain" architecture. It forces your developers (and AI) to context-switch between two different styling systems (SCSS vs. whatever Ant uses), two different API patterns, and two different sets of design tokens.

Why migrate:

• AI Context Clarity: LLMs thrive on uniformity. If your library is entirely built using a single approach (e.g., Radix/Base UI + Tailwind), the AI only has one pattern to learn, leading to higher-quality, hallucination-free code generation.

• Direct Code Access: When the component code lives in your repo (or a centralized internal registry you control), AI tools like Cursor can "see" the implementation, not just an opaque black-box package.

2. Strategic Comparison

• Top Choice: NeetoUI as a custom component registry built on shadcn/ui.

  • Using the shadcn/ui model (copy-paste) allows Neeto to keep its visual brand (via Tailwind) while offloading complex accessibility (Radix/Base UI) to battle-tested primitives.

  • It makes your library "AI-native": Cursor/Claude can reference the specific component files because they are just standard JSX/TSX in your codebase.

3. What is "AI Searchable" and How to Get There?

"AI searchable" means your design system is discoverable and interpretable by LLMs without them needing to guess how your internal components work.

Concrete Steps:

1. llms.txt: Create a /llms.txt file at the root of your design system documentation. This is a compact, Markdown-based overview of your library, linking to individual component docs.

2. MCP Server: Build an MCP (Model Context Protocol) server for your design system. This allows an AI agent (in Cursor or Claude Desktop) to query your documentation or component metadata dynamically rather than relying on a static training cut-off.

   • Tools to expose: list_components, get_component_api(name), get_usage_example(name).

3. Standardized Schema: Adopt a strict metadata.json or config.json for every component file. This allows AI to programmatically understand which props are required, the variants available, and the intended design tokens.

4. Balancing Consistency, Risk, and AI Capabilities

To balance these needs, follow this three-phase migration strategy:

• Phase A (Governance): Stop adding new components to the "Ant Design" bucket. Standardize your design tokens (e.g., Tailwind config variables) so they are used by both the old and new implementations.

• Phase B (The "Shim" Layer): Create a "NeetoUI" package that re-exports your new shadcn-based components. If a product team is still using the old Table, you provide a wrapper that mimics the old API but uses the new, AI-friendly implementation under the hood.

• Phase C (AI Tooling Integration): * Create a custom .cursorrules or .windsurf/rules file for all Neeto products.

  • This file should instruct the AI: "When building UI, always use NeetoUI components from packages/neeto-ui/components. Prefer composition over complex props."

Summary Recommendation

You are currently in a transition from a Library Consumer to a Component Provider.

By moving to a "copy-paste" model using Radix/Base UI primitives, you remove the "black box" that currently limits your AI tooling's effectiveness. You gain full transparency, which is the single most important factor for AI-driven development.