A Skill de 79 Mil Estrelas Criada para Combater Sites Genéricos
Ela não muda o modelo. Coloca 1.206 linhas de decisões entre o seu pedido e o código.
79.159 estrelas no GitHub. 5.407 cópias feitas por outras pessoas. 152 alterações salvas no histórico. E nenhuma versão publicada como oficial.
Repositório criado em 19 de fevereiro deste ano. Números atualizados em 22 de agosto.
E o produto principal é um arquivo de texto.
Já deixo claro, porque vale pra toda a leitura: estrela no GitHub é gente clicando em "salvar pra depois". Não é prova de conversão, não é prova de qualidade visual, não é dado de comparação. É atenção. Eu não rodei teste próprio com e sem a skill, e repito isso no final.
Mas um arquivo de instruções juntar 79 mil estrelas em seis meses é sinal pra abrir e contar.
Eu abri. Contei. A skill principal tem 1.206 linhas na versão principal do projeto, que no GitHub se chama main.
Mil duzentas e seis linhas de regra. Antes de qualquer código.
O nome é Taste Skill: tasteskill.dev. O posicionamento oficial: "The Anti-Slop Frontend Framework for AI Agents". Em português: kit de regras de frontend contra site genérico, pra agentes de IA.
O que isso é, e o que isso não é
Vou tirar três coisas da mesa.
Não é um modelo. Não existe IA nova aqui. É o mesmo Claude, o mesmo GPT, o mesmo Gemini.
Não é biblioteca de componentes. Você não instala componente, não importa pacote, não tem <Button> pronto vindo de lá. Não é um shadcn concorrente.
A skill principal não é um programa que roda. Ela não executa nada e não entrega componente montado. No jargão, não é um runtime. O que muda o comportamento do agente é o arquivo.
É um SKILL.md. Um arquivo de texto que o agente lê antes de escrever a primeira linha de código.
E aqui está a parte que me interessa: o arquivo não descreve estética. Ele transforma gosto em três coisas mecânicas.
Decisões que o agente declara antes de codar. Proibições explícitas do que ele não pode fazer. E um checklist final, item por item, antes de entregar.
Agora três detalhes que parecem burocracia e não são.
A licença é MIT. Você pode usar, modificar e distribuir esse arquivo, inclusive em trabalho de cliente pago, sem pedir autorização. Nada te obriga a manter as regras como vieram. Eu vou usar essa liberdade mais pra frente.
Existem sete versões paralelas do projeto. Versão paralela é o que o GitHub chama de branch: serve pra mexer em algo sem quebrar a versão principal. O GitHub marca a main como principal, e é dela que sai o arquivo instalado por padrão.
Não existe etiqueta de versão publicada. No GitHub essa etiqueta se chama tag, e é o que permite dizer "essa é a 1.0, estável, use essa". Sem ela você pega o que estiver lá no dia em que instalar. Guarda esse detalhe, ele volta no final.
A instalação é uma linha
Não tem cerimônia. O comando principal da documentação oficial:
npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend"Isso coloca um SKILL.md no seu projeto. O agente lê sozinho. Zero configuração extra.
Quer o pacote inteiro, com todas as variantes:
npx skills add Leonxlnx/taste-skillEstá no Codex e quer o pacote na pasta de skills dele:
npx skills add Leonxlnx/taste-skill -a codexServe pra qualquer agente que leia SKILL.md. A lista oficial: Cursor, Claude Code, Codex, Antigravity, Gemini CLI, AI Studio, v0, Lovable, OpenCode, OpenClaw, Windsurf e Copilot.
Se você já usa um desses, a barreira é colar um comando.
São 13 skills, não uma
Aqui a maioria das pessoas para na primeira e perde metade do valor.
Na versão principal encontrei 13 arquivos skills/<nome>/SKILL.md prontos pra instalar. O site resume tudo como oito variantes. Recorte diferente de comunicação, mas os dois números não batem.
Não vou listar as 13 uma por uma. Agrupo por função, que é como você decide.
O núcleo. taste-skill é a v2 experimental, a que vem por padrão hoje. taste-skill-v1 continua instalável, pra quem depende do comportamento antigo. gpt-tasteskill é a mais rígida, feita pra GPT e Codex.
As portas de entrada. image-to-code-skill pra quando você tem referência visual e quer o código. redesign-skill pra site que já existe, com auditoria antes de mexer. stitch-skill pra fluxos compatíveis com o Google Stitch e exportação de DESIGN.md.
Os estilos. soft-skill pra interface calma. minimalist-skill pro oposto do enfeite. brutalist-skill pra linguagem mecânica e crua. Você escolhe a direção em vez de rezar pra o modelo acertar.
A execução. output-skill garante que a resposta chegue completa, sem seção pela metade.
Os complementos. imagegen-frontend-web e imagegen-frontend-mobile pra geração de imagem no fluxo, e brandkit pra identidade de marca.
Regra prática: uma do núcleo, mais uma de entrada se o caso pede, mais no máximo uma de estilo. Empilhar cinco skills de estética é o jeito mais rápido de brigar consigo mesmo.
Como a skill organiza o trabalho em cinco passos
Agora o miolo. A v2 não é uma lista de "faça bonito". São cinco passos encadeados, e a ordem importa.
1. Entender o pedido antes de criar. Antes de escrever uma linha, o agente tem que dizer numa frase que página está fazendo, pra quem, com que cara e apoiado em qual sistema de design. É o pintor que repete o pedido antes de encostar o pincel: "parede de quarto de criança, tinta lavável, tom claro". A skill chama essa leitura inicial de brief inference. É o antídoto pro vício de todo modelo: pular pra estética favorita dele.
2. Escolher três níveis do projeto. Três medidores, de 1 a 10, definidos antes de começar: quanto o layout pode ser ousado, quanto a página se move e quanta informação cabe na tela. Pensa em três botões de volume. No arquivo eles se chamam DESIGN_VARIANCE, MOTION_INTENSITY e VISUAL_DENSITY, com ponto de partida em 8, 6 e 4 (baseline, no jargão). E o agente não usa esse ponto de partida em silêncio: justifica cada número a partir do pedido. Site de órgão público desce a ousadia pra 3 e o movimento pra 2. Portfólio de agência sobe pra 9 e 8.
3. Manter as mesmas escolhas do começo ao fim. Escolheu uma cor de destaque, ela vale na página inteira. Definiu o arredondamento dos cantos, mesma coisa. Escolheu tema claro, não aparece seção clara no meio de página escura. O arquivo chama essas travas de consistência de locks. Parece óbvio. É o que quebra quando o modelo decide tudo de novo em cada seção, como um pintor que troca de lata no meio da parede.
4. Ter uma lista clara do que evitar. Aqui fica opinativo de um jeito raro. Não é "evite", é proibido. O arquivo chama essas proibições de bans. Algumas: roxo de IA como cor inicial, três cards idênticos, print falso de painel de produto, desenho decorativo improvisado, a setinha de 'role a página', número antes do título da seção, bolinha de status só de enfeite, travessão, um jeito de detectar rolagem que trava celular (window.addEventListener('scroll')), número de versão na primeira dobra e a tirinha de cidade e horário no rodapé.
5. Conferir tudo antes de entregar. No fim, o agente roda um checklist, caixa por caixa, e mostra o resultado. É a vistoria antes de liberar o carro da oficina. O arquivo chama isso de pre-flight. Se uma caixa não passa, a entrega não está pronta.
As regras que eu levaria pra qualquer projeto
Essas eu adotaria hoje, mesmo sem instalar nada.
A primeira dobra cabe numa tela. Primeira dobra é o que aparece antes de qualquer rolagem, o que o pessoal de front chama de hero. Título com no máximo 2 linhas, subtítulo com no máximo 20 palavras, botão visível sem rolar. E a melhor regra: se você não explica a proposta em 20 palavras, o problema é a proposta.
Sobretítulo é racionado. Sobretítulo é o rótulo em caixa alta acima do título, tipo "NOSSOS SERVIÇOS". A skill libera um a cada três seções. Todo site feito por IA coloca um em cada seção, e o ritmo fica idêntico em toda página do mundo. A contagem é mecânica: passou, falhou.
Repetição de layout é proibida. Usou três colunas com imagem, não usa de novo. Oito seções pedem no mínimo quatro famílias de layout. E o zigue-zague de imagem e texto é limitado a duas seções seguidas.
Print de produto falso é proibido. Aquele painel desenhado no próprio código, com lista de tarefas inventada e "última sincronização há 4s" no rodapé. É o marcador número um de página feita por IA. Ou usa imagem real, ou não mostra.
Efeito contínuo não pode virar estado do React. Posição do mouse, progresso da rolagem, física de hover: nada disso deve entrar no useState, o mecanismo do React pra guardar informação que muda na tela. Cada mudancinha redesenha a página inteira. Num efeito contínuo isso acontece dezenas de vezes por segundo e derrete o celular.
Movimento precisa de motivo. Antes de animar, o agente responde o que a animação comunica: hierarquia, narrativa, retorno de ação ou mudança de estado. "Ficou legal" não vale.
Isso é régua de revisão melhor do que a maioria das agências tem escrita.
As regras em que eu pisaria no freio
Agora a parte que ninguém escreve, porque dá trabalho.
A proibição total do travessão. Como detector de texto de IA é ótima, e eu concordo em interface. Mas está classificada como falha do checklist final, no mesmo nível de um botão ilegível. Em português, o travessão tem função real em fala e em aposto. Regra de estilo tratada como erro de acessibilidade é hierarquia errada.
As regras de fonte. Inter desencorajada, serifada muito desencorajada como escolha inicial, duas serifadas proibidas por nome. O raciocínio faz sentido: são as favoritas dos modelos. Só que se o cliente tem manual de marca, quem decide é o manual, não um documento genérico.
A exigência dos dois temas. A skill obriga versão clara e versão escura em página voltada ao consumidor. No jargão, dual mode. Numa página de tráfego pago com uma dobra e um formulário, dois temas podem ser custo sem retorno. Eu trocaria por "escolhe um, trava e testa".
A lista de cores proibidas por código. Existe uma lista de códigos de cor vetados como escolha inicial pra produto premium, aqueles que começam com # e definem cor na web. A intenção é boa: evitar que todo site artesanal saia igual. Mas se aquela cor é a da marca do cliente, a regra virou obstáculo.
As proibições de conteúdo apagam coisa legítima. Sem bolinha de status, sem tirinha de cidade e horário, sem contador de estoque. Só que existe endereço físico real, status de servidor real, estoque limitado real.
E aí chego no risco de verdade, que não está em nenhuma regra específica.
Se 79 mil pessoas instalam o mesmo arquivo e ninguém adapta nada, o resultado não é o fim do genérico. É um genérico novo. Mais bonito, mas ainda um padrão único reconhecível.
A skill mata o padrão de fábrica do modelo. Se você não editar nada, ela instala o padrão dela no lugar. Contexto acima de dogma: a regra que serve fica, a que não serve sai. A licença MIT te dá esse direito por escrito.
Como testar de verdade, sem se enganar
Print de "antes e depois" com página diferente não prova nada. Se quer saber se funciona no seu caso, o teste é chato:
- Escolhe uma página real que já existe.
- Cria duas versões paralelas do projeto, as duas saindo do mesmo ponto do histórico.
- Usa o mesmo pedido nas duas. Mesmo conteúdo, mesma oferta, mesmas imagens.
- Numa versão, a skill carregada. Na outra, nada.
- Compara seis coisas: hierarquia visual, repetição de layout, movimento, celular em 375 pixels, acessibilidade e velocidade.
O que eu olharia. Hierarquia: dá pra saber o que é mais importante em três segundos? Repetição: quantas famílias de layout existem? Movimento: cada animação tem motivo, e a página respeita quem desligou animação no aparelho? Existe uma preferência de sistema pra isso, que o navegador passa pro site com o nome prefers-reduced-motion. Celular: alguma coluna estourou? Acessibilidade: o contraste de botão e formulário passa no nível mínimo recomendado, o AA? Velocidade: roda o teste gratuito do Google, o Lighthouse, antes e depois.
Depois disso você tem opinião com lastro. Sem isso, só uma sensação.
O caminho prático, começando agora
Instala:
npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend"Carrega a skill uma vez no começo da sessão. Depois manda um pedido preenchido, não um pedido vago. Esse é o formato que eu usaria, tirado do guia oficial de dois prompts:
Você está usando a taste-skill v2 como única fonte de regras de design.
Projeto: [o que é a página]
Público: [quem decide a compra]
Referências: [dois ou três links]
Marca existente: [cor, fonte e logo, ou "não existe"]
Restrições: [acessibilidade, prazo, stack, performance]
Antes de escrever código: me devolva o design read em uma linha e os três dials com justificativa.
Depois de escrever: rode o pre-flight e me mostre o resultado caixa por caixa.As duas últimas linhas são as que mais mudam o resultado. Elas usam os nomes do arquivo, já traduzidos aqui: leitura do pedido, três medidores e checklist final. Forçam o agente a declarar a intenção antes e auditar o trabalho depois. Sem isso, ele lê 1.206 linhas e aplica metade.
Se o site já existe, o pedido muda. Em vez de página nova do zero, que a skill chama de greenfield, você pede redesign e exige auditoria antes de mexer. O protocolo dela começa mapeando o que não pode mudar em silêncio: endereços de página, rótulos de menu, campos de formulário, logo e texto legal.
Os limites, sem maquiagem
A v2 é experimental, e isso está escrito lá. O nome de instalação design-taste-frontend continua o mesmo, mas o texto das regras pode mudar antes de existir versão fechada. A regra que você leu hoje pode estar diferente no mês que vem.
Não existe versão publicada como oficial. Nenhuma etiqueta de versão no GitHub. Versão e status vêm por site e changelog. Se precisa de estabilidade, anota o ponto exato do histórico que usou, o código que o GitHub chama de commit, e revisa a mão.
1.206 linhas ocupam espaço na cabeça da IA. Todo modelo considera uma quantidade limitada de informação de uma vez. Carregado inteiro, o arquivo disputa esse espaço com o seu código e o resto do projeto. É escolha de orçamento, não ganho puro.
Estrela não é dado de comparação. 79 mil pessoas acharam interessante. Isso não diz nada sobre conversão, taxa de rejeição ou faturamento.
Eu não tenho teste controlado próprio. A fonte foi o site, a documentação e o repositório, com os números atualizados em 22 de agosto. Eu não rodei a mesma página com e sem a skill em ambiente comparável. Quando eu rodar, eu conto o número.
E não substitui designer nem sistema de marca. É uma régua de decisão. Régua boa reduz erro grosseiro. Não cria posicionamento, não escolhe oferta, não escreve headline. Se a copy é fraca, a página vai ser fraca com hierarquia impecável.
Funciona? Funciona. Mas tem limites. E quem te vende sem os limites está vendendo, não ensinando.
O que eu faria hoje: instalar num projeto de teste, não no do cliente. Uma página. O mesmo pedido nas duas versões. Comparar as seis coisas da lista.
Se você fizer isso, me manda o antes e o depois. Print dos dois, mesmo conteúdo. Eu quero ver, principalmente se der errado, porque caso ruim ensina mais que caso bom.
E se essa leitura te economizou tempo, compartilha com quem ainda acha que página genérica é culpa do modelo.
Valeu. Nos vemos no próximo.
- Vini