Hi Stitch team,
DESIGN.md is great for aligning look (colors, type, spacing, radius). What’s still missing for design→code is component identity.
Stitch often generates HTML that looks like drawers, cards, menus, and buttons, but coding agents still have to guess which real library components those regions map to. If generation could be grounded in a known, themed kit (e.g. shadcn with a customizable theme), that gap gets much smaller.
Idea
Allow a Stitch agent (via tools / MCP-style hooks) to:
- Fetch an external component catalog from a themed library (components + theme tokens)
- Prefer those components when generating screens
- Annotate the output so each UI region has a stable component id (or equivalent marker) that points at the catalog entry — e.g.
shadcn:drawer,shadcn:card,shadcn:button/primary
Coding agents (Cursor, etc.) don’t need a full separate inventory export. HTML (or the design payload) with ids that resolve to known library components is enough to map design → code accurately.
Why this matters
- Theme alone = visual consistency
- Component ids = implementable consistency
- Agents can call
get_component(id)/ use the library docs instead of reverse-engineering Tailwind markup
Sketch of agent tools
list_components()/get_component(id)get_theme()- Generation constrained to catalog ids where possible
- Output markup/nodes tagged with those ids
Questions
- Is an agent-with-tools model on the roadmap for design generation?
- Would you support connecting an external themed component catalog (e.g. shadcn-style) as input beyond
DESIGN.md? - Can generated screens include stable component ids on nodes/regions so coding agents can resolve them to library components?