uix-skill

O que uix-skill faz?

Construa interfaces que parecem projetadas, não geradas. Decida a aparência uma vez (DESIGN.md), construa a partir dele, verifique o resultado com scripts.

Caminhos: todos os caminhos references/, data/ e scripts/ abaixo são relativos à pasta que contém este SKILL.md. Execute os scripts a partir da raiz do projeto do usuário como node <aquela pasta>/scripts/<nome>.mjs. Os scripts precisam do Node 22.

Comandos

Comando	Função
/uix init	Leia o projeto, faça 3 perguntas, ofereça 3 direções, escreva e verifique o DESIGN.md.
/uix build	Construa uma página, tela ou componente a partir do DESIGN.md, verifique-o, corrija-o. Padrão.
/uix audit	Execute as verificações e relate. Não edite nada.
/uix polish	Corrija os principais problemas da auditoria. Mantenha lógica, rotas e significado do texto.
/uix motion	Revise ou adicione movimento, após as 4 perguntas.

O verbo pode chegar como /uix-skill <verbo>, como uix <verbo>, ou como uma solicitação direta ("faça a página de configurações", "audite esta tela"). Mapeie uma solicitação direta para o verbo mais próximo. Sem correspondência clara: build.

Regras rígidas

1. Se o DESIGN.md existir: leia-o primeiro e construa a partir dele. Pule a fase de coleta de informações e direções. Nunca invente cores, fontes ou raios que ele não define.
2. Nunca relate como concluído antes de scripts/rules.mjs ter sido executado e, para stacks web, scripts/check.mjs também. Se uma verificação não puder ser executada (veja Verificações), relate não verificado: <motivo>.
3. No máximo 2 rodadas de reparo após uma verificação. Depois, relate o que restar.
4. Imagens: ativos do projeto, depois Openverse/Wikimedia com crédito, depois arte CSS/SVG. Nunca um placeholder vazio.
5. Apenas ferramentas gratuitas. Sem APIs pagas, sem chaves.
6. Não edite arquivos fora do escopo da UI da solicitação. /uix audit não edita nada.
7. Carregue apenas os arquivos que as tabelas abaixo nomeiam. Carregue um arquivo de stack, exceto para shadcn e nuxt-ui: carregue aquele guia mais o guia do framework hospedeiro.

Ordem de execução

1. Leia o projeto: package.json, config, estilos existentes, DESIGN.md, public/ ou assets/.
2. Detecte o stack (tabela abaixo). Carregue seu guia.
3. Coleta de informações. Faça 3 perguntas juntas, em uma mensagem: público, a função da tela, tom. Stacks móveis: o tom também pergunta "movimento calmo ou animado?"; registre a resposta como o nível de movimento no DESIGN.md (references/design-md.md). Pule qualquer coisa que o usuário ou projeto já respondeu.
4. Ofereça 3 direções de references/directions.md que claramente diferem em tom, densidade e temperatura de cor. Aguarde a escolha. Uma direção que o proprietário já escolheu de antemão pula a oferta.
5. Escreva o DESIGN.md (references/design-md.md) e verifique-o. Corrija todos os erros de verificação.
6. Escolha uma estrutura de references/layouts-web.md (marketing, conteúdo) ou references/layouts-app.md (telas logadas).
7. Construa a primeira seção. Texto real, imagens reais, todos os estados do componente.
8. Verifique (abaixo). Corrija erros, depois avisos. No máximo 2 rodadas.
9. Relate.

As etapas 3 a 5 pertencem ao init. build usa um DESIGN.md existente; sem nenhum, execute init primeiro.

Sistemas de design existentes vencem

• Se o DESIGN.md existir: leia-o, verifique-o, construa a partir dele.
• Sem DESIGN.md, mas o projeto tem seus próprios tokens ou tema (config do Tailwind, variáveis CSS, arquivo de tema): /uix init escreve um DESIGN.md (na raiz do projeto) a partir desses tokens. Não ofereça novas direções, a menos que o usuário peça um novo visual.
• Nenhum dos dois: init completo.
• Tokens próprios significam cores, fontes ou espaçamento além dos padrões iniciais do framework, em um bloco @theme do Tailwind v4, uma config do Tailwind, propriedades personalizadas CSS ou um arquivo de tema da plataforma. O padrão --background/--foreground do create-next-app não conta.

O que carregar

Não carregue mais nada até que seja necessário.

Quando	Carregar
Qualquer build, polish ou audit	references/anti-slop.md, references/components-a11y.md
init, ou qualquer escrita de DESIGN.md	references/design-md.md
init (oferecendo direções)	references/directions.md, em seguida as linhas escolhidas de data/fonts.csv, data/palettes.csv, data/styles.csv
Página de marketing, conteúdo, catálogo	references/layouts-web.md
Dashboard, tabela, formulário, configurações, autenticação	references/layouts-app.md
Qualquer movimento, ou /uix motion	references/motion.md
Build, polish ou audit móvel	references/mobile-foundations.md, references/mobile-patterns.md
Movimento móvel	references/mobile-motion.md em vez de references/motion.md
Móvel: visualização segura do aplicativo, Expo Go versus um dev build, verificações de toque e deslize	references/mobile-testing.md
init para um aplicativo móvel	data/mobile-styles.csv em vez de data/styles.csv (as linhas escolhidas)
Qualquer espaço de imagem	references/images.md
Exemplo de formato DESIGN.md	data/examples/ledger.md, field-notes.md ou harbor.md. Apenas um.
Cada tarefa	Um references/stacks/<id>.md. Para shadcn ou nuxt-ui, também o guia hospedeiro (veja Detecção de stack).

Detecção de stack

A primeira correspondência vence, de cima para baixo. Nada corresponde: html-tailwind. Corresponda nomes exatos de dependências (next, não next-themes).

Sinal	ID do stack
@nuxt/ui no package.json	nuxt-ui
components.json com shadcn, ou @/components/ui	shadcn
Arquivo artisan ou laravel/framework no composer.json	laravel
nuxt no package.json	nuxtjs
next no package.json	nextjs
@angular/core ou angular.json	angular
astro no package.json ou astro.config.*	astro
svelte ou @sveltejs/kit	svelte
vue no package.json	vue
three no package.json	threejs
react-native ou expo no package.json	react-native
react no package.json	react
pubspec.yaml	flutter
build.gradle(.kts) com Compose (androidx.compose)	jetpack-compose
*.xcodeproj ou Package.swift com SwiftUI	swiftui
*.csproj com Avalonia	avalonia
*.csproj com Uno. ou Uno.WinUI	uno
*.csproj com Microsoft.WindowsAppSDK	winui
*.csproj com <UseWPF>true</UseWPF>	wpf
*.csproj com TargetPlatformIdentifier UAP ou Microsoft.NETCore.UniversalWindowsPlatform	uwp
pom.xml ou build.gradle com javafx	javafx
nenhum dos acima	html-tailwind

IDs web: angular, astro, html-tailwind, laravel, nextjs, nuxt-ui, nuxtjs, react, shadcn, svelte, threejs, vue. Os demais são nativos. "Stack móvel" significa react-native, flutter, swiftui ou jetpack-compose. Suas solicitações também carregam as linhas móveis de "O que carregar". O stack mais específico vence: nextjs sobre react, react-native sobre react, laravel sobre seu frontend JS. Stacks de camada de componente carregam dois guias: shadcn mais o guia hospedeiro (nextjs, react, astro, laravel, ... detectados por esta tabela com a linha shadcn pulada), e nuxt-ui mais nuxtjs. Qualquer outro projeto carrega um.

Verificações

A partir da raiz do projeto do usuário. Substitua <skill> pela pasta que contém este SKILL.md.

node <skill>/scripts/rules.mjs [--design DESIGN.md] <caminho...>
node <skill>/scripts/check.mjs <url|arquivo> [--widths 375,768,1280] [--out .uix/shots] [--themes attr=v1,v2]
node <skill>/scripts/images.mjs "<consulta>" [--count 6]

• Todos os três imprimem JSON. rules.mjs imprime {findings, skipped}: arquivos minificados, com mais de 1 MB ou ilegíveis vão para skipped com um motivo e não são um erro. check.mjs imprime {shots, findings, notes}; leia notes (por exemplo, um tempo limite de carregamento investigado precocemente, ou uma captura de tela que falhou). Saída 0: limpo. Saída 1: achados de erro (rules.mjs, check.mjs). Saída 2: problema de uso ou ambiente (todos os três). images.mjs só sai com 0 ou 2.
• Saída 2 nunca é um resultado limpo e nunca conta como uma rodada de reparo. Se check.mjs não conseguir acessar a página e o projeto tiver um script de desenvolvimento óbvio (npm run dev etc.), inicie-o uma vez em segundo plano e tente novamente. Caso contrário, pergunte ao usuário. Nomeie o que está faltando (Chrome, Node 22, um servidor que não está rodando).
• Se a verificação ainda não puder ser executada, o relatório diz não verificado: <motivo>.
• Stacks web: execute rules.mjs no código-fonte, depois check.mjs na URL do servidor de desenvolvimento ou no arquivo construído. As larguras são 375, 768 e 1280. As capturas de tela vão para .uix/shots: <w>.png é a página inteira, e <w>-<n>.png são blocos de no máximo 1600 px. Olhe para os blocos, não para a captura inteira; ela encolhe para ficar ilegível. check.mjs rola a página primeiro para que o conteúdo revelado ao rolar apareça.
• Quando o projeto define vários temas ([data-theme], [data-skin], .dark), passe-os com --themes, por exemplo --themes data-skin=oatmeal,rose ou --themes class=dark. Cada tema é verificado na última largura; seus achados carregam theme.
• Achados de contraste são agrupados por par de cores (count, sample, selectors). Corrija o token, não cada elemento.
• React Native (Expo): execute rules.mjs, depois node <skill>/scripts/check-mobile.mjs --app exp://127.0.0.1:<porta> contra um servidor Metro em execução; adicione --platform android para emuladores Android (as flags e o arquivo de rotas estão no guia do stack). Ele imprime {shots, findings, notes} e sai com 0, 1 ou 2 como check.mjs. Uma nota começando com maestro missing: significa que hierarquia e fluxo não foram executados; relate como não verificado: <motivo>, não como uma execução bem-sucedida. As capturas vão para .uix/mobile-shots. Um achado route-not-navigated é um erro e nunca é um resultado limpo: a captura mostra outra tela. Loop de reparo: verifique novamente com --only <rotas> e uma entrada --devices, não a matriz completa.
• Outros stacks móveis: execute rules.mjs. Aplicativos iOS nativos (SwiftUI) em seguida usam check-mobile.mjs --native (flags no guia do stack); em uma passagem de auditoria --out "$(mktemp -d)". Outros usam a receita de captura de tela manual no "Como verificar" do arquivo de stack (claro, escuro, texto xxxl). Nenhum simulador disponível: não verificado: <motivo>. O limite de 2 rodadas se aplica.
• Outros stacks nativos: execute rules.mjs, depois a lista de verificação manual no "Como verificar" do arquivo de stack. Não há verificação de navegador.
• Corrija achados de error antes de warn. Um aviso que você mantém precisa de um motivo de uma linha.
• Loop de reparo: verifique, corrija, verifique novamente. No máximo 2 rodadas. Depois pare e relate.
• IDs de regras e suas correções estão em references/anti-slop.md. Ele também lista regras de julgamento que nenhum script captura; revise-as você mesmo.

Contratos de comando

init

1. Leia o projeto, detecte o stack, carregue seu guia.
2. Tokens existentes ou DESIGN.md: veja "Sistemas de design existentes vencem".
3. Caso contrário, faça as 3 perguntas, ofereça 3 direções claramente diferentes, aguarde. Qualquer stack: detecte o idioma do conteúdo (lang, arquivos i18n, texto) e selecione apenas linhas de data/fonts.csv cuja coluna scripts o cubra.
4. Escreva DESIGN.md. Verifique: npx --yes @google/[email protected] lint DESIGN.md. Corrija erros.
5. Relate a direção escolhida, os arquivos escritos e o resultado da verificação.

build

1. Leia DESIGN.md, o guia do stack e o arquivo de layout.
2. Escolha uma estrutura. Diga qual e por que em uma linha.
3. Construa a primeira seção completamente. Depois o restante.
4. Execute as verificações. Corrija em no máximo 2 rodadas.
5. Relate.

audit

1. Detecte o stack e carregue seu guia.
2. Execute as verificações. Revise as regras de julgamento. Passe --out "$(mktemp -d)" para check.mjs e também para check-mobile.mjs, para que a auditoria não escreva nada no projeto.
3. Produza uma tabela. Não edite nada.

Antes	Depois	Porquê
o que está lá agora	o que deveria ser	o ID da regra ou motivo

polish

1. Detecte o stack e carregue seu guia.
2. Execute uma auditoria primeiro.
3. Corrija os principais problemas, erros primeiro. Não altere lógica, rotas ou significado do texto.
4. Reexecute as verificações. No máximo 2 rodadas. Relate.

motion

1. Carregue references/motion.md (stacks móveis: references/mobile-motion.md). Responda suas 4 perguntas por escrito para cada animação: necessária, o que comunica, qual easing, quanto tempo.
2. Descarte qualquer animação sem uma resposta clara. Adicione tratamento prefers-reduced-motion (o guia do stack nomeia o equivalente nativo).
3. Produza uma tabela Antes / Depois / Porquê. Aplique a alteração apenas quando o usuário pediu para adicionar ou corrigir movimento, não para revisá-lo.

Relatório

Termine cada execução com:

• O que mudou (arquivos).
• Achados que permanecem, cada um com ID da regra e motivo.
• Caminhos de capturas de tela e blocos em .uix/shots (web), caminhos de capturas em .uix/mobile-shots (móvel) ou as verificações manuais feitas (outros nativos).
• Créditos de imagem adicionados.