Build with AI agents
GlassKit ships its own agent skill. Every scaffolded app comes with its agent pre-briefed on the platform contract (Claude Code, Cursor, Copilot, anything that reads AGENTS.md), plus llms.txt and an MCP server for the registry.
Most Display web apps get built with an AI assistant in the loop. The failure mode is never "couldn't find the component." It's procedural: an agent that assumes touch input, invents a dictation flow, or hand-writes a worse List. GlassKit ships the cure in three layers.
The skill (procedural knowledge)
Every npm create glasskit scaffold includes its agent skill, so the new app
arrives with its agent already briefed:
| File | Read by |
|---|---|
AGENTS.md | the cross-agent contract: platform truth, focus rules, build conventions |
CLAUDE.md | Claude Code (imports AGENTS.md) |
.claude/skills/glasskit-ui/SKILL.md | Claude Code / Agent SDK: the full build procedure, loaded on demand |
.cursor/rules/glasskit.mdc | Cursor (always applied) |
.github/copilot-instructions.md | GitHub Copilot |
Existing project? One command, never overwrites:
npx @glasskit-ui/cli agentsThe reference (knowledge)
glasskit.app/ui/llms.txt is the
LLM-facing reference: platform facts, SDK API, conventions, and all 44
components with descriptions. Generated from the registry, so it can't
drift. Paste it into any model's context.
The tools (hands)
The MCP server exposes the registry to agents as tools. List and search
components, read their source, pull a concise usage example
(get_component_example), and get a single batched install command for several
components at once (get_add_command):
npx @glasskit-ui/mcpWorks with Claude Code (claude mcp add glasskit -- npx @glasskit-ui/mcp),
Cursor, and any MCP client.
The skill encodes the same contracts the docs do: the conventions every component follows, the per-component "when to use" guidance, and the API stability freeze. So human-written and agent-written GlassKit apps converge on the same shape.