Using designtoken.md with Any Coding Agent
The universal workflow for giving any coding agent your full design system. Generate once, use everywhere. Every agent that reads project files can use your tokens.
Generate your token file
Head to the designtoken.md generator and configure your design system:
- Pick your brand colors and let the generator build full color scales
- Configure typography: font families, sizes, and weights
- Set spacing and border-radius values
- Switch to the designtoken.md tab in the output panel
- Copy the output or download the file
Drop it in your project root
Every major coding agent reads files in your project root as context. Place the file at the top level:
your-project/
├── designtoken.md ← place it here
├── src/
├── package.json
└── ...That's it. No configuration needed. The structured markdown format with consistent headings means any agent can parse it deterministically. No special plugins or integrations required.
Start building with tokens
Your coding agent discovers designtoken.md as part of your project context and applies the token values when writing UI code. You can reference it explicitly for stronger results:
"Build a settings page using the tokens from designtoken.md for all styling."
"Create a card component. Use the color, spacing, and radius tokens from designtoken.md."The agent reads the full file and applies your color scales, typography stack, spacing, radius, elevation, and component tokens consistently across every file it generates.
Agents that work with designtoken.md
Any coding agent that reads project context files will pick up your designtoken.md. Here are the ones with dedicated guides:
If your agent reads markdown files from your project, it works with designtoken.md.
Before & after
See the difference tokens make in what your agent outputs:
<button style="
background: blue;
color: white;
padding: 10px 20px;
">
Click me
</button><button style="
background: var(--color-primary-500);
color: #fff;
padding: var(--space-sm) var(--space-lg);
border-radius: var(--radius-md);
font-weight: 600;
">
Click me
</button>With tokens, every component your agent generates uses your actual design values instead of arbitrary defaults.
Best practices
- Keep your
designtoken.mdat the project root, since every agent looks there first - Regenerate when your design direction changes
- Reference it in agent-specific config files (
CLAUDE.md,.cursorrules,.windsurfrules,GEMINI.md) for persistent guidance - The visual reference section helps agents understand the intended aesthetic, not just the raw values
- Commit the file to version control so all team members and CI agents get the same tokens
- Use specific prompts like "apply the primary color scale from designtoken.md" for more precise output
When to go beyond static tokens
A static designtoken.md file works great for most projects. Consider moving beyond the file when you need:
- Runtime token resolution: your design system updates propagate across your app without regenerating files
- Brand guardrails: programmatic enforcement that prevents off-brand output at the API level
- Composition intelligence: tokens resolve dynamically based on context, component state, or user preferences
That's the graduation path from a static token file to runtime infrastructure.
For runtime token resolution and brand enforcement at production scale, explore Designless Studio. It reads the same token vocabulary and makes it available via API, so your design system updates across your app without regenerating files.
If you find yourself generating the same tokens across multiple projects, turn your tokens into a reusable design skill on skill.design so your agent installs your design preferences as a package.