Quando soube do padrão DESIGN.md que o Google Stitch introduziu, a primeira coisa que pensei foi no Vibe Styles. Eu já tinha um projeto com mais de 400 estilos de UI/UX, cada um com prompt estruturado, paleta de cores, tipografia, especificações técnicas. Tudo documentado.
A conta era simples: eu já tinha a matéria prima. Gerar um DESIGN.md para cada estilo era questão de transformação de dados. E se eu ia gerar 400+ arquivos, fazia sentido ter um lugar para hospedar e distribuir isso.
Pra quem não conhece o problema que DESIGN.md resolve: agentes de IA se complicam em persistir contexto visual entre prompts. Você pede um componente, fica bonito. Pede outro, fica bonito também. Mas os dois juntos parecem de apps diferentes. DESIGN.md é um arquivo Markdown na raiz do projeto que define o design system inteiro. O agente lê antes de gerar qualquer coisa. Cores, tipografia, espaçamento, componentes, restrições. Tudo num formato que LLMs entendem bem.
Poderia estar no AGENTS.md? Sim, mas como um é referenciado no outro, o DESIGN.md é lido só sob demanda e, na teoria, economiza contexto.
Antes do designmd.app existir, eu já mantinha outro projeto: o Vibe Styles. Uma coleção de estilos de UI/UX com demonstração visual e prompt copiável para IA generativa.
Clique abaixo para ver os detalhes de como eu o criei e o que aprendi.
É uma referência aberta de arquivos DESIGN.md documentados. Você entra, escolhe um estilo por vertical ou categoria visual, copia o DESIGN.md e cola na raiz do seu projeto. O agente de IA lê e aplica.
Não é um gerador. Não é um SaaS. Você entra, escolhe um estilo, copia o arquivo e cola na raiz do seu projeto. Cada DESIGN.md tem paleta de cores com nomes semânticos, tipografia com valores concretos, espaçamento com escala nomeada, padrões de componentes com estados, e uma seção de Do’s and Don’ts que LLMs seguem surpreendentemente bem.
O site também serve como vitrine das skills de agente de IA que eu desenvolvo e distribuo em skill.dev.br.
Escolhi Astro v6. O site é quase todo conteúdo estático, Markdown é o formato principal, e eu queria performance e SEO sem complicação.
Os 423 estilos vivem num JSON unico (library.json) que alimenta o Content Layer do Astro via file loader. Não tem .md individual para cada estilo. O campo designmd dentro do JSON contém o markdown completo, renderizado no build com marked e shiki para syntax highlight.
O download do DESIGN.md acontece no browser. Um Blob com o conteúdo markdown, sem arquivos pre-gerados no servidor. O botão de copiar usa navigator.clipboard. Nenhum dos dois precisa de framework JavaScript.
A unica interatividade de verdade é o filtro da biblioteca, uma island React (LibraryFilter) com client:idle. O resto do site é HTML puro. A home carrega menos de 5KB de JS.
Tailwind CSS v4 via plugin Vite. Sitemap, RSS, i18n (PT-BR + EN), MDX para o blog.
Usei o Antigravity, Kiro e Claude Code na execução.
Os dados vêm do repositório Vibe Styles no GitHub, prevendo que, se eu atualizar lá, fica fácil atualizar aqui também. O script bash faz o sync:
git clone(oupull) do repo para.source/vibe-styles/transform-json.mjstransforma o JSON original (estrutura aninhada do app) num JSON flat com slugs SEOCopia os 423 PNGs de screenshot para
public/images/library/
O script é idempotente. Roda antes de cada deploy. O diretório .source/ fica no .gitignore.
A transformação achata a estrutura aninhada do JSON original, gera slugs a partir do nome do estilo (com sufixo -{id} para os 2 casos de duplicata), converte keywords de string comma-separated para array, e exclui campos genéricos de instrução de prompt que não são conteúdo do estilo.
Output estático. Quase tudo é pre-renderizado. Se precisar de endpoint dinâmico no futuro, o Astro suporta modo hybrid sem mudar nada.
Markdown para o DESIGN.md, não JSON. LLMs entendem Markdown com mais fidelidade. Design tokens em JSON definem valores, mas não regras. Não tem como expressar “use primary apenas para a ação principal” num tokens.json. DESIGN.md combina valores e semântica no mesmo arquivo.
Deploy estático na minha VPS com Coolify.
Um DESIGN.md tem 6 seções. A ordem importa porque o LLM processa de cima para baixo: Overview (descrição do produto em 2-3 frases), Colors (hex + nome semântico + regra de uso), Typography (famílias, pesos, escala com valores concretos), Spacing (base unit e escala nomeada), Components (padrões visuais com estados) e Do’s and Don’ts (restrições explícitas).
Essa ultima seção é a que mais gente ignora, e a que mais diferença faz. LLMs respondem bem quando você diz o que não fazer. “Não misture cantos arredondados e retos no mesmo componente” funciona melhor do que você imagina.
Cada agente tem seu jeito de ler o arquivo. No Claude Code, você referencia no CLAUDE.md com @DESIGN.md. No Cursor, cria uma regra em .cursor/rules/. No Kiro, copia para .kiro/steering/DESIGN.md e ele inclui automaticamente. No Windsurf, vai no .windsurfrules. No Google Stitch, o import é nativo pela UI.
O arquivo fica na raiz do projeto. A configuração só diz ao agente para ler.
Retro-alimentei o Vibe Styles, criando uma aba com a possibilidade de baixar o DESIGN.md por lá também. 2 updates de uma vez.
O site: designmd.app O projeto original: github.com/fabricioctelles/vibe-styles Skills de agente: skill.dev.br
Nenhuma publicação
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.