Nos termos do próprio skill
Uma disciplina centrada no ofício para construir UI de produto — dashboards, painéis administrativos, apps SaaS, ferramentas, páginas de configurações, interfaces de dados — com as decisões que uma equipe de design de ponta tomaria. Ela exige um briefing de trabalho antes do código: quem é o humano, o único verbo que ele veio realizar e como a interface deve parecer, em palavras que tenham significado real.
A partir daí, o skill prescreve a exploração de domínio (domínio, universo de cores, assinatura, padrões rejeitados), uma escala tipográfica construída sobre uma razão em que peso e cor fazem o trabalho de hierarquia, uma única estratégia de profundidade adotada, tokens semânticos em vez de valores fixos, e os elementos essenciais de acabamento e movimento — números tabulares, raio concêntrico, durações abaixo de 300ms, sem animação em ações de alta frequência. Explicitamente não é indicado para landing pages, sites de marketing, campanhas ou trabalhos apenas de marca.
O que ele produz
- Uma proposta Sugerir + Perguntar nomeando Domínio, Universo de cores, Assinatura, Rejeições e Direção.
- Espécimes renderizados inline — amostras de paleta, a escala tipográfica na tipografia real, cartões de elevação empilhados, a assinatura como um componente real — quando há uma ferramenta de renderização presente; a implementação em si continua indo para o código-fonte.
- Um arquivo .interface-design/system.md salvo, contendo direção, estratégia de profundidade, decisões de hierarquia e padrões de componentes repetidos, escrito somente após o usuário confirmar.
Como funciona
- 01Escreva o Briefing de Trabalho
Antes de qualquer código, responda quem é o humano, qual verbo ele precisa realizar e como a interface deve parecer — mantido compacto, a menos que a direção precise de confirmação.
- 02Explore o Domínio do Produto
Produza quatro resultados antes de propor uma direção: pelo menos 5 conceitos de domínio, 5 ou mais cores do mundo físico do produto, um elemento de assinatura e 3 padrões óbvios a rejeitar.
- 03Proponha e Confirme a Direção
Comece com um bloco Sugerir + Perguntar nomeando Domínio, Universo de cores, Assinatura, Rejeições e Direção, depois verifique se a direção está correta antes de construir.
- 04Renderize Espécimes Quando Possível
Se a sessão tiver uma ferramenta de renderização visual inline, mostre a paleta, a escala tipográfica, os níveis de elevação e a assinatura como componentes reais em vez de descrevê-los; caso contrário, recorra ao código.
- 05Construa em Cima do que Existe, Depois Verifique
Inspecione o aplicativo, os tokens, os padrões de componentes e o system.md, corrija a implementação, execute build, typecheck ou testes quando disponíveis, e então verifique visualmente em larguras de desktop e mobile.
- 06Ofereça-se para Salvar os Padrões
Depois de uma tarefa, ofereça-se para registrar direção, estratégia de profundidade, decisões de hierarquia e padrões de componentes repetidos, para que sessões futuras permaneçam consistentes.