O que o getdesign.md faz bem
É a maior coleção pública de arquivos DESIGN.md, a instalação é feita genuinamente com um único comando e publica um relatório State of DESIGN.md junto ao catálogo. Se você quer ver as diversas maneiras como as pessoas escrevem esses arquivos, ou se busca especificamente um brief derivado de um produto que admira, este é o lugar ideal. É mantido pela equipe do VoltAgent, que também gerencia a lista awesome-design-md.
A diferença estrutural
Ambos os produtos instalam um DESIGN.md. A pergunta pertinente é o que mais chega ao repositório, pois um brief de design é metade de um design system e os tokens são a outra metade.
| getdesign.md | Identity Forge | |
|---|---|---|
| O brief escrito | Sim: um DESIGN.md | Sim: um DESIGN.md |
| Design tokens semânticos de cor | Sem arquivo de tokens. Os valores aparecem no brief como texto | 28 funções, light e dark, escritas no seu tema |
| Onde os valores residem | No Markdown. Sua stylesheet permanece inalterada | Na sua stylesheet. O Markdown os referencia |
| Exportações de framework | Markdown | Variáveis CSS, @theme do Tailwind v3/v4, item de registro shadcn, JSON DTCG/W3C |
| Origem do design | Análise de padrões observáveis de um produto existente | Um kit original, ou gerado a partir do seu brief |
| Integração com agente | Instale o arquivo, o agente o lê | Ferramentas MCP: pesquisar, combinar uma paleta, ler o brief, aplicar o kit |
A segunda e a terceira linhas são as que determinam o que realmente acontece no seu codebase. Se os valores de cor existirem apenas dentro de um arquivo Markdown, o agente os lerá e os escreverá nos componentes como valores literais, pois não há mais nada para referenciar. Você acaba com um design documentado e um stylesheet não documentado, que é exatamente a situação que os design tokens existem para evitar.
Um brief com valores em prosa e sem um arquivo de tokens não oferece nada para o agente referenciar. Ele escreve literais, e o stylesheet não aprende nada.
Isso não é uma crítica ao formato. É uma consequência do que uma entrada de catálogo pode ser. Uma análise do produto de terceiros não pode entregar o arquivo de tokens deles, porque ela não o possui.
O que um brief derivado de marca pode e não pode carregar
As entradas do getdesign.md são análises de padrões publicamente observáveis, e suas páginas de marca dizem isso diretamente, com avisos de não afiliação. Esse enquadramento está correto e deve ser aceito como tal. A questão interessante é o que sobrevive à derivação.
| Transfere? | Por que | |
|---|---|---|
| Paleta e família tipográfica | Sim | Diretamente observável a partir de uma página renderizada |
| Valores de espaçamento e raio | Em grande parte | Observável, embora definir quais são sistemáticos e quais são pontuais seja uma questão de julgamento |
| O que o design se recusa a fazer | Raramente | Ausências são invisíveis à observação. Você não consegue ver uma sombra que nunca foi usada |
| Por que uma decisão foi tomada | Não | Uma densidade que atende a um power user o dia todo é a resposta errada para uma landing page, e o brief não tem como saber qual dos dois você é |
A terceira linha é a mais importante, e ela se aplica a qualquer brief derivado, independentemente de quem o produza. Amostramos 299 arquivos DESIGN.md publicados e descobrimos que 76% não contêm proibições de qualquer tipo: além de 86% especificarem cores como hex puro sem função semântica e 57% não nomearem nenhum motivo distintivo. As proibições são onde a identidade de um design realmente reside, e são precisamente aquilo a que uma análise externa tem menos acesso.
Esse é o limite honesto de copiar o visual de qualquer produto admirado, e cobrimos isso detalhadamente no teardown da Linear: a paleta é a parte menos distintiva do sistema, e as restrições que o fazem funcionar são a parte que não sobrevive à extração.
Um sistema gerado, ao vivo
É isto que "gerar um sistema completo" significa na prática: o kit gratuito ambient-sage, renderizado a partir de seus tokens e fontes reais, o mesmo payload que a CLI escreve no seu repo:
Ambient Sage
Live renderRendered from the kit's actual tokens, fonts, and treatments
Typography
Plus Jakarta Sans
Color system
28 semantic roles, light + dark
Agent outputs
DESIGN.md, CSS, Tailwind, shadcn
npx shadcn add https://identityforge.io/r/ambient-sage.jsonApós esse comando, seu globals.css conterá 28 funções nomeadas em light e dark, e o DESIGN.md referenciará essas funções pelo nome em vez de repetir os valores hex. Esse é o acoplamento que mantém o brief fiel: altere um token e o brief continuará preciso, porque ele nunca guardou uma cópia.
Qual você deve usar?
- Escolha o getdesign.md se quiser estudar como arquivos DESIGN.md são escritos em diversos produtos, ou se quiser especificamente um brief derivado de um design que você admira e se sente confortável em fornecer a camada de tokens por conta própria.
- Escolha o Identity Forge se quiser um sistema original instalado como tokens funcionais mais um brief correspondente, com entrega via MCP, CLI e shadcn, além de exportações para qualquer stack que você utilize.
- Eles não são excludentes. Ler entradas de catálogo é uma ótima maneira de calibrar o quão específico um brief deve ser. Apenas esteja ciente de que um brief sem tokens deixa o stylesheet inalterado, portanto, combine-o com uma camada de tokens real de qualquer maneira.
Independentemente da sua escolha, faça a mesma verificação depois: use grep para procurar valores hex literais fora do seu arquivo de tokens. Se o agente estiver escrevendo-os nos componentes, o brief não está conectado a nada e você tem uma documentação em vez de um sistema.
Novo no formato? Comece com o que é um DESIGN.md e como gerar um, depois escolha sua ferramenta no guia de pilares.
FAQ
Qual a diferença entre o Identity Forge e o getdesign.md?
O getdesign.md publica análises em DESIGN.md de produtos conhecidos, instaláveis via CLI, além de um starter LaunchKit. O Identity Forge gera um design system original (28 funções de cores semânticas para light e dark mode, fontes, regras de layout e motivos) e instala o brief junto com os tokens referenciados, via MCP, CLI ou um registro shadcn.
O getdesign.md me fornece design tokens?
Ele fornece um DESIGN.md descrevendo um design, com valores declarados no documento. Ele não escreve um arquivo de tokens semânticos na sua stylesheet, o que é uma consequência da natureza de uma entrada de catálogo: uma análise de outro produto não pode entregar o arquivo de tokens desse produto.
O Identity Forge é uma alternativa ao getdesign.md?
Para obter um design system instalável, sim. Para navegar por diversos exemplos práticos do formato DESIGN.md, o getdesign.md possui a maior coleção e ambos servem a propósitos diferentes. Muitas pessoas consultam um catálogo para calibração e instalam um sistema gerado para, de fato, desenvolverem sobre ele.
Posso usar um DESIGN.md derivado de uma marca que eu goste?
Pode, e é uma maneira razoável de ver o formato aplicado. Duas ressalvas: uma análise externa raramente captura o que um design se recusa a fazer — que é onde a identidade reside principalmente — e as decisões de um design dependem do seu público: a densidade adequada para uma ferramenta usada o dia todo é a resposta errada para uma página que alguém escaneia por quarenta segundos.
O Identity Forge é gratuito?
Kits gratuitos e o registro shadcn funcionam sem conta. Uma chave de API (em /account/api-keys) é necessária apenas para dados proprietários, cotas de API mais altas e kits Pro.