Por que o site de documentação não funciona
O instinto é direcionar o agente para o site do design system. Isso raramente ajuda, por quatro razões estruturais que não têm nada a ver com a qualidade do site.
| Site de documentação | O que um agente precisa | |
|---|---|---|
| Padrão de acesso | Navegado — você vai até a página que precisa | Tudo o que é relevante no contexto, antes da primeira decisão |
| Organização | Por componente: Button, Input, Card | Por decisão: funções de cores, densidade, elevação, o que é proibido |
| Voz | Descreve a intenção — "nossos botões transmitem confiança e acessibilidade" | Declara restrições — "font-weight 500, radius 6px, nunca use gradiente" |
| Completude | Cobre o que existe | Deve cobrir também o que não deve existir |
A linha de organização é a que as pessoas ignoram. Um site organizado por componente é perfeito para alguém que já sabe que precisa de um Button. Um agente prestes a construir uma tela ainda não decidiu quais componentes usar — suas primeiras decisões são sobre densidade, hierarquia e layout, e isso é exatamente o que um site organizado por componentes nunca cobre.
A linha de completude é a mais consequente. A documentação descreve o que existe porque é para isso que a documentação serve. Mas a diferença entre a sua interface e uma genérica é, principalmente, um conjunto de coisas que você nunca faz, e nenhuma página de componente jamais mencionará isso.
O que arquivos reais realmente contêm
Amostramos 299 arquivos DESIGN.md publicados em repositórios e diretórios públicos — arquivos escritos deliberadamente para dar orientações de design a agentes de IA — e medimos seus conteúdos. 72 eram especificamente arquivos de visual design. O padrão é consistente o suficiente para ser usado como um checklist do que evitar.
| Proporção de arquivos | |
|---|---|
| Cores como hex puro, sem papel semântico | 86% |
| Nenhuma proibição de qualquer tipo | 76% |
| Sem definição de dark mode | 69% |
| Sem motivos distintivos | 57% |
| Pelo menos um adjetivo vago assumindo a função | 54% |
| Nenhum valor de tamanho concreto em lugar nenhum | 44% |
| Mencionam tipografia | 83% |
Compare as duas últimas linhas. A tipografia é mencionada em 83% dos arquivos, mas 44% não contêm nenhum valor de tamanho concreto. Essa lacuna resume todo o problema em uma única estatística: os arquivos falam de tipografia sem nunca dizer o tamanho de nada.
O dado sobre adjetivos é a outra metade. "Clean" aparece em 39% desses arquivos, "modern" em 36%. Ambas são palavras que um modelo satisfaz produzindo o centro de sua distribuição de treinamento, que é precisamente o visual genérico que o arquivo foi escrito para evitar.
Um modelo a quem se pede algo "clean and modern" produz a média de tudo o que já viu. O mesmo acontece com o modelo de qualquer outra pessoa ao receber o mesmo pedido.
As sete mudanças
Cada uma delas corresponde a uma falha medida acima. Aplicadas em conjunto, transformam uma descrição em algo executável.
- 1
Atribua um papel a cada cor, não apenas um valor
#6b7280é um valor que um modelo usará para texto de corpo, bordas, ícones, placeholders e estados desativados indiscriminadamente.--text-muted, descrito apenas como texto secundário e de apoio, tem uma única função. Cinco papéis superam um hex, e permitem que você altere as bordas posteriormente sem alterar as legendas.--text-muted: #6b7280 /* secondary and supporting text only */ --border-subtle: #e5e7eb /* structural edges, dividers */ --text-disabled: #9ca3af /* disabled controls only */ - 2
Substitua cada adjetivo por um número ou uma regra
"Espaçamento generoso" torna-se "gap de seção 64px, padding de card 24px". "Tipografia clean" torna-se uma escala. Se uma frase não puder ser verificada em uma tela renderizada, ela é apenas decoração.
- 3
Escreva as proibições
A seção de maior impacto individual, e a que 76% dos arquivos omitem completamente. Cinco linhas são suficientes para começar.
## Never - No gradients - No drop shadows — elevation is a surface step plus a 1px border - No font-weight above 600 - No colour value outside the token set - No border-radius above 12px - 4
Defina o dark mode, não deixe que ele seja derivado
Se deixado indefinido, o modelo inverte o light mode, e o resultado falha previsivelmente: as sombras param de funcionar, cinzas médios perdem contraste em ambas as extremidades e um destaque saturado que parecia confiante no branco causa glare no quase-preto. Um segundo conjunto de tokens custa uma hora de trabalho e elimina toda uma categoria de retrabalho.
- 5
Declare a decisão de densidade explicitamente
Saber se esta é uma ferramenta densa ou uma superfície de marketing espaçosa altera cada escolha subsequente, e esta é a decisão que a maioria dos arquivos nunca toma. Se seu produto possui ambos os tipos de superfície, isso requer dois arquivos, e não um único arquivo ambíguo.
- 6
Nomeie pelo menos dois motivos
Os elementos específicos e recorrentes que tornam o design único: uma linha de destaque de 2px à esquerda dos cabeçalhos de seção, colunas numéricas sempre tabulares e alinhadas à direita, uma maneira particular de desenhar estados vazios. 57% dos arquivos não possuem nenhum, e é por isso que a saída deles é correta, porém sem personalidade.
- 7
Aponte para o arquivo de tokens; nunca o repita
Assim que um valor hex existe tanto no arquivo de design quanto no arquivo de tokens, um será atualizado e o outro não, e o modelo usará confiantemente o valor desatualizado. Faça referência, não copie.
Se você for fazer apenas uma dessas mudanças, faça a terceira. Uma lista de proibições exige quinze minutos de trabalho e altera a saída gerada mais do que as outras seis combinadas, pois ela restringe o enorme espaço de decisões que suas permissões deixaram aberto.
O que as sete mudanças produzem, ao final, é um arquivo cujos valores um agente consegue resolver sem inventar nada. Esta é a mesma informação renderizada em vez de escrita — útil aqui como um checklist do que seu próprio arquivo deve ser capaz de responder:
Token specimen · real values
Sage & Slate Editorial
Live renderSage & Slate Editorial's actual tokens — the same values its exports use.
Color tokens
Sage & Slate Editorial
Core
background
H 70 · C1, 0, 5, 7
foreground
H 84 · C7, 0, 17, 88
card
H 60 · C0, 0, 2, 4
muted
H 70 · C1, 0, 5, 10
border
H 69 · C1, 0, 6, 16
Brand
primary
H 119 · C45, 0, 46, 47
primary-fg
H 0 · C0, 0, 0, 100
secondary
H 213 · C59, 33, 0, 33
accent
H 49 · C0, 7, 39, 20
ring
H 119 · C45, 0, 46, 47
Semantic
destructive
H 0 · C0, 68, 68, 21
destructive-fg
H 0 · C0, 0, 0, 0
success
H 119 · C45, 0, 46, 47
warning
H 41 · C0, 22, 68, 31
muted-fg
H 80 · C4, 0, 13, 64
Charts
chart-1
H 119 · C45, 0, 46, 47
chart-2
H 213 · C59, 33, 0, 33
chart-3
H 49 · C0, 7, 39, 20
chart-4
H 120 · C27, 0, 27, 34
chart-5
H 71 · C8, 0, 41, 74
Typography
Sage & Slate Editorial
Scale: major-third
Density: relaxed
Heading · Plus Jakarta Sans · 2.5rem
Sample headline
Subheading · Plus Jakarta Sans · 1.875rem
A warm organic editorial UI kit on a sage-green canvas with generous rounded cards, eyebrow accent chips, and a soft photography-forward layout.
Body · DM Sans · 1rem
A warm editorial system built on a sage-green page background with floating off-white cards that carry large border-radius and soft shadows. Bold geometric headings open with inline eyebrow accent chips, and generous whitespace defines the rhythm. The palette draws from nature: forest greens, dusty blues, and warm wheats, applied as accents on a near-neutral sage canvas. Ideal for photography, lifestyle, wellness, and editorial content surfaces.
Mono · Space Mono · 0.8125rem
npx shadcn add sageslateeditorial.json
Aa
Plus Jakarta Sans · Heading
Aa
DM Sans · Body
ABCDEFGHIJKLM NOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz
0123456789 & @ # % →
Tokens
Sage & Slate Editorial primitives
Radius scale
Component radius
Elevation
Spacing · base 1rem
Como escrever uma proibição que funcione
Nem todas as proibições funcionam da mesma forma. Três propriedades separam aquelas que alteram a saída daquelas que são ignoradas.
| Fraco | Forte | Por que | |
|---|---|---|---|
| Especificidade | "Evite estilizações excessivamente decorativas" | "Sem gradientes, sem sombras projetadas, sem bordas decorativas" | Um modelo não consegue avaliar o que é "excessivamente" |
| Verificabilidade | "Mantenha a tipografia contida" | "Nunca use font-weight acima de 600" | Um pode ser localizado via grep; o outro não |
| Alternativa fornecida | "Não use box-shadow" | "Sem box-shadow — a elevação é um degrau de superfície mais uma borda de 1px" | Proibir sem substituir deixa o modelo livre para inventar um substituto |
A terceira linha é a que costuma ser ignorada. Uma proibição sem alternativa cria uma lacuna que o modelo precisa preencher, e ele a preenche com a mesma distribuição de treinamento da qual você estava tentando escapar. Todo "nunca X" deve ser seguido por "em vez disso, Y".
Estrutura e extensão
O arquivo precisa caber no contexto junto com a tarefa real, o que impõe um limite concreto. Cerca de 400 linhas é uma meta viável; além disso, regras individuais começam a perder a atenção para a tarefa.
A ordem também importa. Coloque a intenção e as proibições logo no início. Um modelo que lê de cima para baixo encontra a regra geral antes do caso especial, que é a mesma ordenação que a Stripe usa em sua Appearance API — primeiro o tema, depois as variáveis e, então, as regras específicas.
# DESIGN.md
## Intent <- who reads this product, and what it is for
## Never <- the prohibitions, early and unmissable
## Colour <- roles for light and dark, referencing tokens
## Type <- scale with real numbers, weight band, tracking
## Spacing & density <- the scale, and which surface uses which step
## Elevation <- the strategy, stated once
## Composition <- how components sit together
## Motifs <- what makes this design specifically oursSe o seu produto tem superfícies genuinamente diferentes — um site de marketing e um dashboard denso — não escreva um único arquivo com ressalvas. "Espaçamento generoso, embora tabelas possam ser mais densas" são duas regras fingindo ser uma, e o modelo terá que escolher. Escreva um arquivo raiz com o que nunca muda e arquivos por superfície com o que muda.
O que deve ficar em um servidor
Nem tudo deve estar no arquivo, e tentar encaixar tudo é o que o torna extenso demais para ser útil. A linha divisória é se o agente precisa da informação antes de decidir ou apenas sob demanda.
| Onde | Por que | |
|---|---|---|
| APIs de componentes, props, variantes | Servidor | Extenso, muda com frequência, necessário apenas após a escolha de um componente |
| Catálogo de ícones | Servidor | Centenas de nomes, necessários um por vez |
| Papéis de cores, escalas, densidade | Arquivo | Necessário antes da primeira decisão, todas as vezes |
| Proibições | Arquivo | Um agente nunca pensa em perguntar o que é proibido — ele já precisa saber |
O servidor MCP do Carbon da IBM é um bom modelo para a primeira coluna: ele expõe a busca de documentação, exemplos de código de componentes, gráficos e componentes experimentais como ferramentas. Notavelmente, nada disso são proibições — porque uma ferramenta de recuperação apenas traz o que o agente pensou em consultar. Mais sobre a divisão.
Testando se funciona
Escrever o arquivo e assumir que funcionou é como as equipes descobrem o problema três semanas depois. Quatro verificações, em ordem crescente de esforço.
- 1
Use grep para buscar valores de cores literais
Se o agente estiver seguindo as funções semânticas, não deve haver nenhum hex fora do seu arquivo de tokens.
grep -rn --include='*.tsx' --include='*.css' -E '#[0-9a-fA-F]{3,8}\b' src \ | grep -v 'tokens\|globals.css' - 2
Use grep para buscar os pesos que você proibiu
O peso é onde a hierarquia silenciosamente retorna ao padrão, e é o sinal mais rápido de que uma proibição não está sendo aplicada.
grep -rn --include='*.tsx' -E 'font-(bold|extrabold|black)' src | head -30 - 3
Peça a mesma tela duas vezes, em sessões separadas
A consistência entre sessões é o teste real. Se duas execuções diferirem significativamente em espaçamento, raio ou hierarquia, o arquivo não está restringindo o que deveria — e o diff dirá exatamente qual seção está faltando.
- 4
Construa primeiro uma tela em dark mode
Se o dark mode foi derivado em vez de definido, é aqui que isso aparece. É muito mais barato descobrir na tela um do que na tela vinte.
As duas primeiras etapas devem estar no CI. Uma verificação que reprova um pull request contendo um valor hex bruto faz mais pela consistência a longo prazo do que qualquer documentação, que é a conclusão a que a Salesforce chegou com o linter do SLDS e a Stripe chegou ao remover a funcionalidade inteiramente.
Os design kits do Identity Forge já vêm com essa estrutura pré-montada: 28 funções de cores semânticas para light e dark, escalas de tipografia e espaçamento, elevação, motivos e diretrizes explícitas de 'faça' e 'não faça', serializadas em um DESIGN.md. Explore os kits ou leia como gerar um DESIGN.md.
Posso apenas apontar meu agente de IA para o meu site de documentação do design system?
Raramente funciona. Um site é navegado página por página, organizado por componente, e descreve a intenção em prosa. Um agente precisa das decisões no contexto antes de escolher qualquer componente, organizadas por decisão em vez de por componente, com restrições declaradas como regras verificáveis. Um arquivo no repositório atende a isso; um site não.
Qual deve ser o tamanho de um DESIGN.md?
Cerca de 400 linhas é um teto viável. Ele precisa compartilhar o contexto com a tarefa real e, após esse ponto, as regras individuais começam a perder a atenção. Se ele estiver crescendo, isso geralmente significa que está cobrindo várias superfícies ao mesmo tempo e deve ser dividido em um arquivo raiz e arquivos por superfície.
Qual é a seção mais importante?
As proibições. 76% dos arquivos de design publicados não contêm nenhuma, e a diferença entre a sua interface e uma genérica é, principalmente, um conjunto de coisas que você nunca faz. Quinze minutos escrevendo uma seção de "Nunca" alteram a entrega mais do que qualquer outra seção de comprimento comparável.
Devo colocar os valores dos meus tokens no arquivo de design?
Não — faça referência a eles. Uma vez que um valor existe em dois lugares, um será atualizado e o outro não, e o modelo usará a cópia obsoleta com confiança. Declare a função e onde ela se aplica; deixe que o arquivo de tokens guarde o valor.
Ainda preciso de um site de documentação se eu tiver um DESIGN.md?
Sim, para humanos e para os detalhes da API do componente que são grandes demais para um arquivo. Os dois não competem: o site documenta o que existe em profundidade, o arquivo estabelece as decisões que um agente precisa antes de começar. Catálogos de componentes extensos são melhor atendidos por um servidor MCP do que por qualquer um dos dois.