roast-my-design-system
Um scanner determinístico que audita seu design system, pontua de 0 a 100 com base em 34 repositórios públicos e gera as regras de agente que mantêm a UI escrita por IA dentro do sistema. Roda localmente, gratuito, MIT.
Documentação
roast-my-design-system
Descubra onde seu agente de IA vai inventar UI.
Sua IA pode escrever a UI. Isso garante que ela escreva sua UI.
npx roast-my-design-system@latest
Execute na raiz de um repositório de UI. Um segundo depois, um relatório abre. Sem conta. Sem rede. Sem telemetria. Nada no seu repositório muda.
O histórico de versões está em CHANGELOG.md.
A ideia
Um agente copia o que encontra.
Ele inventa onde o repositório não tem resposta.
Testamos isso em 10 produtos open-source reais, em 355 sessões de agente, com e sem esta ferramenta.
Descobertas adicionadas em cada sessão, contadas pelas próprias regras desta ferramenta:
| Tarefa | Modelo | Quando | Sem roast | Roast MCP e regras instalados | Plugin Roast com seu hook de edição |
|---|---|---|---|---|---|
| Um novo gráfico e um novo componente, 4 produtos, 3 execuções cada | Sonnet 5 | Out 2026, roast 10.1 | 21 em 24 execuções | não executado | 7 em 24 execuções |
| Um novo gráfico e um novo componente, 4 produtos, 3 execuções cada | Haiku 4.5 | Out 2026, roast 10.1 | 72 em 24 execuções | não executado | 1 em 24 execuções |
| Adicionar um painel, montar um dashboard, ajustar uma lista (80 sessões) | Sonnet 5 | Set 2026 | 7 | 9 | não executado |
| Um tema de Natal, 10 produtos | Sonnet 5 | Set 2026 | 28 | 2 | não executado |
| Um novo gráfico, 4 produtos, 5 execuções cada | Sonnet 5 | Set 2026 | 10 em 20 execuções | não executado | 0 em 20 execuções |
| Um novo gráfico, 4 produtos | Haiku 4.5 | Set 2026 | 25 | 39 | 0 em 14 de 15 execuções |
| Gráfico, cor de status, estado vazio, novo componente | Haiku 4.5 | Set 2026 | 42 em 16 execuções | 49 em 16 execuções | 3 em 51 execuções |
O trabalho rotineiro permaneceu no sistema com ou sem a ferramenta. O trabalho que exigia algo novo não permaneceu.
Um agente nem sempre chama uma ferramenta quando deveria. Em outubro, o Sonnet chamou as ferramentas MCP em 7 de 24 sessões e o Haiku em 2 de 24. O hook de edição roda sem ser solicitado. Essa é a coluna com os números mais baixos.
Onde o agente inventou? Onde o repositório não tinha nada para copiar. O Dub não tem paleta de gráficos. Seus próprios gráficos codificam 17 cores. Ao pedir um gráfico, o Haiku codificou mais 9. Em outubro, 5 das 7 descobertas que o Sonnet deixou com o plugin ativo eram cores de gráficos no Dub. O agente as manteve e escreveu um comentário dizendo que o repositório não tem paleta de gráficos.
Então, a bagunça que um agente adiciona é um mapa das lacunas do seu sistema.
Esta ferramenta desenha o mapa.
Roast. Ensine. Proteja.
Roast o repositório para encontrar seu design system real, a bagunça nele e as lacunas.
Ensine o agente, por meio de regras geradas e um servidor MCP local.
Proteja cada edição, para que o agente não precise lembrar de perguntar.
ROAST o que está no repositório e o que está faltando
↓
ENSINE regras nos arquivos do agente, respostas via MCP
↓
PROTEJA cada edição verificada, o PR bloqueado
O que você obtém
Onde seu agente terá que adivinhar?
A primeira coisa que o relatório diz: os lugares onde o repositório ainda não tem resposta, ou "Nenhuma lacuna encontrada".
- a lacuna, em uma linha
- os arquivos que a comprovam
- a única ação que a fecha
Uma lacuna é conhecida com certeza hoje, porque as execuções a encontraram: gráficos codificando cores em um repositório sem paleta de gráficos. 43 de 126 repositórios públicos se parecem com isso. Uma lacuna entra na lista quando é medida.
Correções que você pode fazer agora para aumentar a pontuação de saúde
A bagunça que o agente copiará, classificada pelo valor de corrigi-la.
- o que foi encontrado
- onde, com o caminho do arquivo
- por que importa
- o que mudar
- um botão de copiar com o prompt de correção para seu agente
Corrija, reescaneie, pressione o próximo botão.
Uma pontuação que você pode defender em uma reunião
0 a 100. O mesmo número em cada execução.
Medida contra três critérios: as normas ideais de um design system, a mediana de 34 repositórios de produtos no núcleo de um benchmark de 119 repositórios, e 10 sistemas respeitáveis (Primer, Polaris, Carbon, shadcn/ui e outros).
Monorepos recebem uma pontuação por pacote. packages/ui em 80 deixa de esconder apps/web em 40.
Cada descoberta, com seu caminho de arquivo
- cada cor codificada e seu quase-gêmeo idêntico
- cada valor de espaçamento fora da escala
- cada componente duplicado
E mais 8 tipos, todos em O que ele mede. Um arquivo HTML. Abra, compartilhe no Slack, envie por e-mail.
A barra de uso de cores mostra de onde vem a cor do repositório: de cada 100 usos de cor, quantos leem uma cor do tema pelo nome, quantos usam a paleta do Tailwind e quantos são soltos escritos à mão. Ela segue variáveis CSS, temas Tailwind, variáveis Sass e Less e objetos de tema JavaScript para fazer a contagem.
O cabeçalho nomeia sobre o que o repositório é construído: shadcn/ui, um tema Tailwind, MUI, Mantine, Chakra ou Ant Design, e ambos os kits quando um repositório usa dois.
Regras para seu agente
Geradas do seu repositório, em design-system-rules.md:
componentes canônicos
o arquivo de tokens
duplicatas conhecidas a evitar
passos de espaçamento
tipografias
o vocabulário próprio do kit
--apply as escreve em cada arquivo de agente que você tem: Claude, Cursor, GitHub Copilot, Windsurf. Cada varredura também verifica as regras que você já tem para referências obsoletas.
Um script faz a contagem
Cada número vem de uma leitura determinística dos seus arquivos. Claude escreve a explicação, rotulada como escrita por IA e mantida separada dos números.
Como as execuções foram feitas
Claude Code, headless, em 10 produtos públicos fixados em um commit cada: cal.com, Dub, Metabase, Plausible, SigNoz, trigger.dev e mais quatro. 259 sessões em setembro de 2026 e 96 em outubro de 2026 no roast 10.1, com Sonnet 5 e Haiku 4.5. As sessões de outubro repetem as tarefas de gráfico e novo componente no Plausible, SigNoz, trigger.dev e Dub nos mesmos commits. Cada arquivo alterado foi julgado pelas regras desta ferramenta no final da sessão e no commit fixado. Uma descoberta conta apenas se a sessão a adicionou.
Nada foi renderizado. Zero descobertas significa que o código segue estas regras. Não significa que o design foi revisado. Método, tabelas e limites estão no relatório de pesquisa, que será publicado separadamente.
Exemplos ao vivo
Onze relatórios, hospedados exatamente como a ferramenta os escreve. Cada número determinístico, cada caminho real.
- npx shadcn create, novo (instalação de fábrica, todos os 61 componentes): lido como uma instalação nova, "a pontuação é do kit, não sua"; 13 cores, cada variável de tema no lugar, os 24 valores de colchetes do próprio shadcn nomeados e não contados. Sem pontuação.
- Unleash (MUI): 1.109 arquivos importam o kit e o tema é lido 6.166 vezes; 4 cores e 2 espaçamentos por 100 arquivos do kit são escritos nos componentes. Pontuação 60.
- Metabase (Mantine): seu próprio wrapper sobre o Mantine conta como o kit, então 2.679 arquivos são lidos em vez de 392; nada escrito nos componentes, 2 espaçamentos por 100 arquivos do kit. Pontuação 47.
- SigNoz (Ant Design): 2 cores e 7 espaçamentos por 100 arquivos do kit escritos em objetos de estilo onde existe um token. Pontuação 51.
- Apache Airflow (Chakra UI): nenhuma cor escrita nos componentes, 4 espaçamentos por 100 arquivos do kit como strings de pixel onde existe um passo de espaço. Pontuação 43.
- vercel/ai-chatbot (instalação shadcn): 71 valores como [13px] escritos fora da escala Tailwind, e 66 cores de paleta por 100 arquivos onde existe uma variável de tema; notas de Claude incorporadas. Pontuação 80.
- excalidraw/excalidraw: 78 valores de espaçamento fora da escala e 90 declarações !important. Pontuação 55.
- dubinc/dub: 642 valores arbitrários de colchetes, 21 componentes duplicados e a lacuna da paleta de gráficos nomeada. Pontuação 20.
- telekom/scale (Stencil): 95 componentes Stencil lidos por tag; 66 valores de espaçamento fora da escala onde cerca de 12 bastariam; notas de Claude incorporadas. Pontuação 55.
- magicuidesign/magicui (registry): contado nos componentes que publica, 52 cores fora do tema por 100 arquivos no código que envia, seu site de docs mantido fora e nomeado. Pontuação 78.
- adobe/spectrum-web-components (Lit): 740 tokens de cor com 8 cores codificadas ao lado, e 37 declarações !important. Pontuação 83.
O relatório completo para vercel/ai-chatbot. O veredito responde o que o agente aprenderá aqui, a seção de lacunas vem primeiro, depois "O que o repositório ensina ao agente", a leitura de Claude da varredura:

O mesmo relatório no modo claro (um arquivo, alternância embutida):

Por que os números se sustentam
- Determinístico. Um script Node sem dependências lê cada arquivo e retorna os mesmos números em cada execução. Cerca de um segundo em um repositório normal.
- Somente leitura. Sem rede. Sem telemetria. A suíte de testes falha se package.json declarar qualquer dependência. Cada versão executa 461 verificações contra 29 repositórios de amostra antes de ser marcada; os fixtures e seus snapshots vivem em
tests/, um arquivo JSON cada. - Lacunas honestas. O que a varredura não pode ler diz "não medido" e sai da pontuação.
- Exclusões honestas. Testes, histórias, sites de docs, arte e modelos de e-mail são deixados de fora. Suas próprias exclusões são impressas no cabeçalho do relatório com contagens de arquivos.
- Um benchmark real. 119 repositórios públicos. Uma frota central de 34 repositórios React define as medianas; o resto alimenta os grupos de kits e web components, então um repositório shadcn é comparado com repositórios shadcn e um sistema Lit com sistemas Lit e Stencil. O construtor está em
tools/benchmark/. - Pontuação importável.
scoreHarvest(harvest)retorna a pontuação e métricas como dados simples. O relatório e uma verificação de CI obtêm os mesmos números.
A versão longa, com escopo de varredura e o que o plugin executa na sua máquina, está em docs/reference.md.
Funciona com
Frameworks
React, Next.js, Remix, Vite Stencil, Lit, custom elements
Kits e estilos
Tailwind, shadcn/ui, MUI, Mantine, Chakra UI, Ant Design CSS Modules, Sass, Less, Emotion, styled-components, vanilla-extract, CVA, Stitches
Cada repositório é comparado com repositórios construídos da mesma forma: uma instalação shadcn com instalações shadcn, um produto em MUI, Mantine, Chakra ou Ant Design com produtos nesse kit, um tema Tailwind com temas Tailwind, um sistema Lit ou Stencil com outros sistemas de web components, e um registry shadcn com o grupo shadcn. Um repositório que usa dois kits é informado disso, e suas regras nomeiam ambos.
Reconhecidos, ainda não medidos
Vue, Angular, Svelte: nomeados no cabeçalho, cores e espaçamentos contados, componentes não medidos. O relatório diz isso. HeroUI, NextUI, Radix Themes, Fluent UI, React Bootstrap, Grommet: nomeados no cabeçalho, sem regras de kit.
Cada comando
Uma varredura alimenta tudo; as flags decidem o que vai para o disco. Combine livremente.
Execute você mesmo
| Comando | O que você obtém |
|---|---|
npx roast-my-design-system@latest | A varredura e o design-system-roast.html, abertos no seu navegador |
... <caminho> | Varre um repositório diferente do diretório atual |
... --apply | As regras de agente geradas, injetadas em cada arquivo de agente que você tem: CLAUDE.md, AGENTS.md, .cursorrules, .cursor/rules/, .windsurfrules e .github/copilot-instructions.md, dentro de um bloco marcado. Reexecutar substitui apenas esse bloco, nunca o seu próprio texto. |
... --rules | As mesmas regras gravadas em design-system-rules.md em vez disso, para colar manualmente |
... --card | roast-card.svg: um cartão compartilhável de 1200x630 com a pontuação e os piores achados. SVG puro, incorporável em um README |
... --sarif | design-system-roast.sarif para varredura de código do GitHub: envie-o no CI e os achados aparecem na aba Segurança, anotados nos arquivos |
... --check | Os arquivos alterados da árvore de trabalho verificados contra o design system, no terminal. Sai com código 1 em caso de achados, então se encaixa em scripts |
/roast-my-design-system:review (no Claude Code) | A mesma verificação no chat, a partir da segunda skill do plugin: os achados de cada arquivo alterado com a correção nomeada, depois as correções aplicadas e a verificação reexecutada |
... --exclude lab/ | Deixa uma pasta fora da varredura (repita a flag ou separe por vírgulas). Ou liste pastas em um arquivo .roastignore na raiz do repositório. De qualquer forma, o relatório diz isso no cabeçalho |
... --json | O resumo da varredura como JSON na saída padrão, para scripts e pipelines. Inclui schemaVersion, o benchmark usado, e cada métrica como número, para que duas varreduras possam ser comparadas |
... --by "Dwayne Hicks" | Coloca um nome no cabeçalho do relatório, para quando você executou para outra pessoa |
... --theme light / --out <arquivo> / --no-open / --open | Relatório claro, caminho de relatório personalizado, nunca abrir o navegador, sempre abrir |
Para o seu agente
| Comando | O que você obtém |
|---|---|
... --notes <arquivo.md> | A leitura do agente sobre esta varredura, incorporada no relatório como "O que o repositório ensina ao agente": quais achados importam, quais bons números são acidentes, o que corrigir primeiro. Rotulado como escrito por IA e mantido separado dos números medidos. A skill do Claude Code escreve e passa automaticamente; a flag está aqui para que qualquer agente possa usar |
... --section "Título" <arquivo.md> | Um capítulo adicional escrito pelo agente após as notas, mesma estilização, mesmo rótulo, subtítulos permitidos. Repetível |
... --hook | A verificação que o plugin do Claude Code executa após cada edição, para instalações manuais: lê o evento de hook no stdin, verifica o arquivo alterado, imprime apenas os achados que a edição adicionou como JSON. Sempre sai com código 0 |
... --stop-hook | A revisão que o plugin do Claude Code executa quando o agente termina sua vez, para instalações manuais: lê o evento Stop no stdin e, quando os arquivos alterados na sessão trazem novos problemas, responde com um bloco que envia o agente de volta uma vez. --session-start anota o trabalho que já estava não commitado. ROAST_STOP_REVIEW=off desativa isso. Sempre sai com código 0 |
... --mcp | A varredura como um servidor MCP local: 5 ferramentas que seu agente chama enquanto escreve UI, mais o prompt roast-fix que serve a principal correção de uma varredura recente. Veja Respostas ao vivo via MCP |
/roast-my-design-system (no Claude Code) | A experiência completa: o roast no chat e incorporado no relatório como "O que o repositório ensina ao agente", a oferta de regras e o loop de correção com Claude nos seus próprios números |
"Por que isso importa" é genérico, vem com a ferramenta e lê o mesmo em todo relatório. "O que o repositório ensina ao agente" é a leitura do seu agente sobre o seu repositório, e só aparece quando um agente o passou.
Respostas ao vivo via MCP
O relatório e o arquivo de regras descrevem o repositório como estava no momento da varredura. --mcp mantém o mesmo motor rodando enquanto seu agente trabalha, para que perguntas sejam respondidas a partir do código como está agora, e erros sejam pegos antes de chegarem ao ar.
| Ferramenta | A pergunta que ela responde |
|---|---|
roast_get_context | O que devo saber antes de tocar na UI aqui? Roteado pela pasta que está sendo editada |
roast_find_component | Já existe um componente para isso, e qual é o canônico? Com um exemplo de uso real. Quando dois candidatos empatam, diz isso e nomeia ambos |
roast_find_token | Tenho #111111 / 13px em mãos. O que eu deveria ter usado? |
roast_validate | Estou prestes a salvar isso. Isso quebra o sistema? |
roast_review | Revise meus arquivos alterados. Lê o próprio git diff, então nenhum código é colado de volta |
O loop: contexto antes de construir, encontrar enquanto constrói, validar antes de salvar, revisar antes de terminar.
Uma troca real, contra Unleash, um produto MUI em 60/100. O agente tem um cinza em mãos e um padding em mente:
roast_find_token #6b7280
→ Nearest token: #607d8b, 11 channel steps from #6b7280. Unless the difference is a deliberate decision, use the token.
roast_validate (first draft)
→ ✕ L5 Colour #6b7280 written onto an MUI component, and the theme has no such colour.
Fix: Add it to the theme once (frontend/src/themes/dark-theme.ts), then read it there: color: 'text.secondary' in sx.
✕ L5 Pixel size p: 12px on an MUI component.
Fix: 12px is between steps 1 (8px) and 2 (16px). Keep it with a comment, or use the nearest step in sx.
roast_validate (second draft: color: 'text.secondary', p: 1.5)
→ No measured violations found. Checked: hardcoded colours vs the token set, near-identical colour twins, off-scale spacing …
Quatro chamadas, menos de 800 tokens, e o novo componente lê o tema em vez de adicionar o número de cor 44.
Gráficos têm sua própria regra, porque um gráfico precisa de várias cores que diferem entre si e a maioria dos design systems nunca as nomeia. Onde um repositório mantém uma paleta de gráficos, uma cor escrita à mão em um arquivo de gráfico é um achado que nomeia a paleta. Onde um repositório tem gráficos mas sem paleta, um novo gráfico que pinta à mão recebe um aviso que nomeia o gráfico existente fazendo o mesmo e pede a paleta uma vez. Esse aviso é o relatório de lacunas, ao vivo.
O servidor lê o repositório da mesma forma que o relatório. Em um produto construído em MUI, Mantine, Chakra UI ou Ant Design, o contexto nomeia o arquivo de tema e a forma própria do kit de lê-lo, roast_find_token responde em passos de espaçamento, e as verificações sinalizam uma cor ou um tamanho de pixel escrito em um componente do kit onde o tema tem um valor. Em um tema Tailwind ou um repositório shadcn, eles sinalizam uma classe de paleta como text-gray-500 onde o tema nomeia uma cor desse tipo. O valor bruto de um token colado em um componente é sinalizado com o nome do token, e um botão construído do zero onde o repositório já tem um Button bem usado recebe um aviso que nomeia a linha de importação a usar.
O prompt roast-fix serve a principal ação "Por onde começar" de uma varredura recente, byte idêntico aos botões de copiar do relatório. No Claude Code, digite /mcp__roast__roast-fix, adicione um número para pular a fila. Corrija, pergunte de novo, e a próxima ação subiu para o topo: a varredura é a barra de progresso.
Instalou o plugin do Claude Code? O servidor já está lá. Caso contrário:
claude mcp add roast -- npx roast-my-design-system@latest --mcp
Verificado no Claude Code, Cursor e Windsurf (agora Devin Desktop). Cada um foi testado de ponta a ponta: servidor conectado, todas as 5 ferramentas listadas, respostas reais no chat do próprio editor. Local, somente leitura, uma varredura na inicialização, sem porta, sem conta.
Cursor: coloque isso em .cursor/mcp.json dentro do projeto (o projeto, para que a varredura veja um repositório, não todo o seu disco), depois habilite roast em Configurações → Ferramentas e MCP na primeira vez:
{ "mcpServers": { "roast": { "command": "npx", "args": ["roast-my-design-system", "--mcp"] } } }
Windsurf (Devin Desktop): sua configuração MCP é global (~/.codeium/windsurf/mcp_config.json), então nomeie a pasta do projeto para manter a varredura limitada a um repositório:
{ "mcpServers": { "roast": { "command": "npx", "args": ["roast-my-design-system", "--mcp", "/path/to/your/repo"] } } }
Qualquer outro cliente MCP pode registrar o mesmo comando stdio.
No CI
O scanner fala SARIF, então conectá-lo à varredura de código do GitHub são 6 linhas. Os achados aparecem na aba Segurança, anotados nos próprios arquivos:
- uses: actions/checkout@v5
- run: npx roast-my-design-system@latest . --sarif --no-open
- uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: design-system-roast.sarif
Para falhar um pull request apenas em nova bagunça, use guard-my-design-system.
Instalação
Sem instalação, sem Claude necessário:
npx roast-my-design-system@latest
Claude Code (recomendado):
/plugin marketplace add gregkozakiewicz/roast-my-design-system
/plugin install roast-my-design-system@roast-my-design-system
O que instala: duas skills, um servidor MCP local e duas verificações que rodam sozinhas, nada mais. roast (/roast-my-design-system, ou "roast my design system") varre o repositório inteiro, escreve o relatório com a leitura de Claude dos números dentro dele, depois caminha pelas correções com você. review (/roast-my-design-system:review, ou "review my UI changes") verifica apenas o que mudou, em cerca de um segundo. A verificação de edição roda após cada arquivo que o agente edita e devolve os achados que essa edição adicionou; um arquivo sem nada novo não recebe mensagem. A revisão de fim de turno roda quando o agente diz que terminou: se os arquivos alterados nesta sessão ainda carregam problemas que ele adicionou, o agente é enviado de volta uma vez para corrigi-los antes de terminar. Avisos apenas de recomendação nunca o enviam de volta, um problema é enviado de volta uma vez por sessão, e trabalho que não estava commitado antes do início da sessão é deixado em paz. Para desativar a revisão, defina ROAST_STOP_REVIEW=off nas suas configurações do Claude Code ("env": { "ROAST_STOP_REVIEW": "off" }).
Se esses comandos derem erro, seu Claude Code é mais antigo que o marketplace de plugins. Atualize-o, ou use o caminho manual:
git clone https://github.com/gregkozakiewicz/roast-my-design-system.git
cp -r roast-my-design-system/skills/roast-my-design-system roast-my-design-system/skills/review ~/.claude/skills/
(Use .claude/skills/ dentro de um repositório para compartilhar com sua equipe. A skill review precisa da pasta roast-my-design-system ao lado dela.)
OpenAI Codex CLI (mesmo SKILL.md, mesma pasta):
git clone https://github.com/gregkozakiewicz/roast-my-design-system.git
cp -r roast-my-design-system/skills/roast-my-design-system ~/.codex/skills/
Invoque com $roast-my-design-system. Use .codex/skills/ dentro de um repositório para compartilhar com sua equipe.
npx skills: npx skills add gregkozakiewicz/roast-my-design-system funciona para agentes que leem ~/.agents/skills/. Claude Code lê ~/.claude/skills/, então prefira uma das rotas acima.
Requer Node 18+.
Uso
Abra o Claude Code no repositório que você quer roastar e digite:
/roast-my-design-system
Quando você tiver um design system que vale a pena proteger, a segunda skill verifica apenas o que você mudou:
/roast-my-design-system:review
Ela roda a mesma verificação que --check nos arquivos do seu git diff e lista cada achado com sua correção, no vocabulário próprio do kit em um repositório MUI, Mantine, Chakra, Ant Design ou Tailwind-theme. Sem pontuação, sem relatório: a verificação pequena para tardes de terça-feira. Claude também capta isso de palavras simples como "review my UI changes" ou "did I break the design system".
Você recebe o roast no chat mais design-system-roast.html na raiz do seu repositório, uma página autocontida com:
- uma pontuação de saúde calculada a partir de como seus números se posicionam contra o ideal
- "O que o repositório ensina ao agente": a leitura de Claude da sua varredura, incorporada no arquivo que você encaminhará, rotulada como escrita por Claude e mantida separada dos números medidos. A pontuação sozinha pode lisonjear; esta seção mantém um 85/100 compartilhado honesto
- blocos de estatísticas comparando você a todos os 3 benchmarks
- um alternador de tema claro/escuro em um arquivo
- a barra de paleta ponderada por uso, a rampa de cinzas, os recibos de espaçamento fora da escala, os recibos de componentes duplicados com caminhos de arquivo clicáveis e o registro dos piores infratores
- uma lista Correções que você pode fazer agora para aumentar a pontuação de saúde: até 3 ações derivadas dos números do seu próprio repositório, cada uma com um recibo de caminho de arquivo
- Onde seu agente terá que adivinhar? abre o relatório: as lacunas onde o repositório ainda não tem resposta, com os arquivos que provam cada uma e a ação que a fecha, ou "Nenhuma lacuna encontrada"
- Dê as respostas ao agente:
design-system-rules.mdembrulhado dentro do relatório como um presente. Desembrulhe, depois copie ou baixe as regras de agente geradas a partir da sua varredura Após o roast, a skill oferece escreverdesign-system-rules.mdno disco e mesclá-lo no seu CLAUDE.md,.cursor/rulesou AGENTS.md.
Quatro prompts para experimentar
Roast my design system.
How bad is my CSS? Scan this repo and show me the receipts.
Com o servidor MCP conectado:
Is there already a Button component in this repo, and which one should I use?
E o do dia a dia, depois de você ter alterado alguma UI:
Review my UI changes against the design system.
Solução de problemas
- "Comando não encontrado" ou o plugin não instala. Atualize o Claude Code; o marketplace de plugins precisa de uma versão recente. A instalação manual funciona em qualquer versão.
- "Nada para roast" ou um relatório quase vazio. A varredura encontrou quase nenhuma cor ou espaçamento. O estilo provavelmente vive em outro repositório, um CDN ou um pacote instalado. Execute a partir do repositório que contém os estilos.
- Uma pontuação que parece errada. Verifique o cabeçalho do relatório: ele indica como o repositório foi lido (produto, biblioteca, shadcn, um kit, um tema Tailwind) e todas as pastas que foram deixadas de fora. Escopar a varredura com
.roastignoreou--excludese um playground ou um app antigo estiver distorcendo os números. - O relatório não abriu. Ele é gravado em
design-system-roast.htmlna raiz do repositório. Abra-o em qualquer navegador; ele não precisa de servidor e não faz requisições. - O servidor MCP não aparece. Reinicie o cliente após adicioná-lo. No Claude Code,
claude mcp listmostra se ele conectou. Ele precisa do Node 18 ou mais recente.
Suporte
Bugs e dúvidas vão para GitHub Issues. Todo o resto chega ao Greg pelo gregkozakiewicz.com. Problemas de segurança: veja SECURITY.md.
Privacidade
A ferramenta lê o repositório que você aponta e grava a saída ao lado dele. Ela não faz requisições de rede, não coleta dados e não tem telemetria. O servidor MCP responde a partir da mesma varredura local. Nada sobre seu código, seus prompts ou sua conversa é enviado a ninguém, incluindo o autor.
O que ela mede
| Métrica | Design System Ideal | Mediana da frota principal de 34 repositórios | Mediana de 10 sistemas respeitáveis |
|---|---|---|---|
| Cores distintas | ~24 | 119 | 14 |
| Tons de cinza | até 13 | 28 | 4 |
| Valores de espaçamento fora da escala | ~12 | 24 | 5 |
| Tipografias | 2 a 3 | 3 | 1 |
| Raios de borda fora da escala | até 10 | 14 | 0 |
| Componentes duplicados | 0 | 16 | 9 |
| Blocos de estilo inline | 0 | 51 | 12 |
| Valores arbitrários de Tailwind | ~20 | 56 | 0 |
| Pares de cores quase idênticos | 0 | 7 | 1 |
| Declarações !important | 0 | 5 | 3 |
| Componentes nunca importados | 0 | 0 | 0 |
Benchmark reconstruído em 3 de outubro de 2026 (versão 10.0.0), contado pela própria colheita da varredura.
Sim, o repositório mediano já é uma bagunça. É exatamente esse o ponto. Um agente que chega nele copiará a bagunça fielmente e, onde a bagunça acabar, adicionará um pouco da sua.
Sua IA pode escrever a UI. Isso garante que ela escreva a sua UI.
Licença
MIT. O código é seu para fazer fork, modificar e redistribuir; o aviso de direitos autorais viaja junto.
Construindo seu próprio relatório, resumo ou auditoria a partir das pontuações, contagens ou comparações de benchmark desta ferramenta? Mantenha uma linha nele: Construído com roast-my-design-system por Greg Kozakiewicz. A skill pede o mesmo a um agente de IA que escreve tal documento a partir da varredura.
roast-my-design-system™ e a marca GK são marcas registradas de Greg Kozakiewicz. Fazer fork é bem-vindo; republicar sob este nome não é: veja marca e atribuição.
Construído e projetado por 