anti-ai-design — gate UI 36 estilos (sem chrome IA)

anti-ai-design

Habilidade de design de UI com orquestração automática e regras obrigatórias anti-IA. Produz telas incrivelmente bonitas e visualmente distintas — nunca o resultado genérico gerado por IA.

Quando Usar

Ative esta habilidade sempre que o usuário solicitar:

• Uma landing page, seção hero ou tela de marketing
• Um dashboard, painel administrativo ou interface rica em dados
• Uma tela de aplicativo mobile (iOS, Android) ou UI web responsiva
• Um fluxo de onboarding, formulário de cadastro ou tour pelo produto
• Qualquer tela de biblioteca de componentes ou sistema de design
• "Melhorar a aparência", "redesenhar isto", "criar uma UI para…"

Contrato de Interação Não Negociável

Antes de gerar qualquer saída de design, você DEVE resolver estas três decisões em ordem:

1. Escopo da plataforma — pergunte ao usuário para quais plataformas gerar: mobile, tablet, desktop.
   • Seleção múltipla é permitida.
   • Se o usuário escolher apenas mobile e desktop, NÃO gere tablet.
   • Se a plataforma já estiver explicitamente declarada e não ambígua, confirme repetindo-a e prossiga.
2. Direção de cor — resolva a direção das cores da marca nesta ordem:
   • Se o usuário forneceu cores exatas, use-as.
   • Caso contrário, se o usuário forneceu um humor/estilo de marca/tema, ofereça 2–3 direções de paleta adequadas e peça para escolher.
   • Caso contrário, selecione automaticamente uma paleta que se ajuste à categoria do produto e indique claramente que foi selecionada automaticamente.
3. Direção de estilo — apresente 2–3 opções de estilo e peça ao usuário para escolher uma.

Não pule estas decisões a menos que a conversa já contenha uma resposta inequívoca.

Modo de Execução

Interativo (padrão)

• Pergunte ao usuário cada escolha ausente em sequência: plataforma → cor → estilo.
• Aguarde a resposta antes de prosseguir para a próxima fase.
• Apresente cartões de opção para a direção de estilo com um rótulo RECOMENDADO.

Não Interativo

Ative quando o usuário:

• invocar a habilidade com mode: non_interactive ou sinalizador equivalente,
• estiver executando um comando CLI único, job Codex em segundo plano ou pipeline scriptado, ou
• fornecer um prompt sem contexto conversacional anterior (nenhuma troca de chat antes da solicitação).

Regras de seleção automática (aplicadas em ordem):

1. Plataforma — se não declarada, padrão: desktop. Se existirem sinais mobile-first (descrição de aplicativo mobile, menção a React Native, contexto "telefone"), padrão: mobile.
2. Direção de cor — selecione a paleta mais adequada para o tipo de projeto detectado sem oferecer alternativas.
3. Direção de estilo — dos 2–3 estilos candidatos para este contexto de projeto, selecione aquele que seria marcado como RECOMENDADO. Não apresente cartões de opção.

Cabeçalho de saída obrigatório antes de gerar (apenas não interativo):

Selecionado automaticamente:
- Plataforma: [plataforma(s) selecionada(s)]
- Paleta: [nome da paleta] — primária [valor hex]
- Estilo: [nome do estilo] — [uma frase descrevendo a vibe]
Prosseguindo para a geração do pacote.

Não faça perguntas esclarecedoras. Não apresente cartões de opção. Prossiga diretamente para a Fase 3 após o cabeçalho.

Contrato de Saída — Pacote CJX, Não um Único HTML Solto

A saída padrão é um diretório de pacote para o projeto, não um único arquivo HTML solto.

<nome-do-app>-design/
  html/
    landing-page.html
    mobile-<tela>.html
    tablet-<tela>.html
    desktop-<tela>.html
  css/
    foundation.css
    shared.css
    landing-page.css
    mobile-<tela>.css
    tablet-<tela>.css
    desktop-<tela>.css
  js/
    app.js
    landing-page.js
    mobile-<tela>.js
    tablet-<tela>.js
    desktop-<tela>.js

Regras do Pacote

• html/ contém um arquivo HTML por combinação de tela/plataforma gerada.
• css/foundation.css contém apenas os tokens de design congelados.
• css/shared.css contém primitivos compartilhados, utilitários, movimento, receitas de vidro, estados de foco e padrões de layout comuns.
• CSS específico da tela vai para um arquivo específico da tela.
• js/app.js contém helpers de UI compartilhados, alternâncias de estado, manipulação de dados mock e interações seguras para acessibilidade.
• JS específico da tela vai para um arquivo específico da tela apenas se necessário.
• Se o usuário solicitar uma exportação de arquivo único posteriormente, você pode fornecer adicionalmente uma exportação HTML autônoma, mas o contrato padrão é o pacote CJX.

Regras de Nomenclatura de Arquivos por Plataforma

• Landing pages permanecem semânticas: landing-page.html, landing-page.css, landing-page.js
• Telas de aplicativo usam prefixos de plataforma:
  • mobile-<tela>.html
  • tablet-<tela>.html
  • desktop-<tela>.html
• Gere arquivos apenas para as plataformas selecionadas.
• Se o usuário selecionou mobile e desktop, o pacote de saída não deve conter nenhum arquivo tablet-*.

Por Que Arquivos Separados em Vez de Um Único HTML Responsivo

Use arquivos de plataforma separados por padrão porque:

• cada plataforma pode ter IA, navegação, densidade e posicionamento de CTA materialmente diferentes,
• a revisão e entrega são mais fáceis quando cada destino está isolado,
• a verificação CJX é mais clara quando a intenção da tela é explícita,
• desktop/tablet/mobile frequentemente precisam de hierarquias diferentes, não apenas breakpoints diferentes.

Um único HTML responsivo só é aceitável quando o usuário solicita explicitamente a entrega em um único arquivo.

Roteamento de Sub-Habilidades

Carregue APENAS o arquivo de referência necessário para a etapa atual. NÃO carregue todos os arquivos de uma vez.

Tarefa	Carregar	Detalhes
Escolher estilo de design / direção artística	references/design-styles-catalog.md	36 estilos em 11 categorias
Selecionar tendência / pacote de direção artística	references/design-trends.md	6 tendências, 3 pacotes de direção artística
Aplicar uma receita de design	references/design-recipes-catalog.md	15 receitas de design completas
Aplicar regras de layout por plataforma	references/platform-rules.md	Regras Mobile/iOS 26/Desktop/Tablet
Congelar e injetar tokens de fundação	references/foundation-tokens.md	Instruções de congelamento de tokens e formato
Aplicar gramática de raio + hierarquia de aninhamento	references/radius-choreography.md	Papéis de raio semântico, regras de superfície aninhada, gramática de raio por família de estilo
Aplicar regras de UX / jornada do cliente	references/ux-guidelines.md	Aplicação de UX, padrões CJX
Aplicar coreografia de movimento + intenção de interação	references/motion-choreography.md	Propósito do movimento, política de hover, transições de estado, regras de movimento por plataforma
Aplicar propriedade de ativos do pacote + auditoria de manifesto	references/output-bundle-rules.md	Regras de ativos compartilhados vs. tela, manifesto, auto-auditoria
Gerar pacote de saída	references/output-template.md	Estrutura do pacote, template HTML, contrato de arquivo

---

Fluxo de Orquestração Automática

Execute estas fases em sequência. Cada fase tem lógica condicional — siga-a precisamente.

Fase 1 — DETECÇÃO DE CONTEXTO

1. Examine a conversa e quaisquer arquivos anexados em busca de: nome do projeto, cores de marca existentes, fontes, pilha tecnológica, plataforma alvo e propósito da tela.

2. Classifique o tipo de projeto como um de: produto SaaS · e-commerce · aplicativo mobile · portfólio · dashboard · site de marketing · outro.

3. Extraia as telas solicitadas e conte-as.

4. Resolva o escopo da plataforma como um ou mais de: mobile, tablet, desktop.

5. Se o escopo da plataforma estiver ausente ou ambíguo: faça exatamente uma pergunta de seleção de plataforma com opções de múltipla escolha:

   • Mobile
   • Tablet
   • Desktop

6. Se o usuário já especificou plataformas, não pergunte novamente — mantenha-as exatamente como fornecidas.

7. Observe quaisquer tokens de marca existentes (cores, fontes, escala de espaçamento) encontrados no projeto — você os usará no congelamento de tokens posteriormente.

8. Resolva a prioridade do esquema de cores com base no tipo de projeto:

   Primeiro modo escuro (escuro é a tela principal; claro é a substituição opcional):

   • Dashboard · painel administrativo · SaaS com muitos dados · fintech · ferramentas de desenvolvedor · analytics · monitoramento · crypto/web3 · mídia/streaming · jogos

   Primeiro modo claro (claro é a tela principal; escuro é a substituição opcional):

   • E-commerce · site de marketing · portfólio · saúde · educação · alimentação e bebidas · estilo de vida

   Se o tipo de projeto for ambíguo ou não se encaixar em nenhuma das listas, o padrão é primeiro modo claro e ofereça o modo escuro como um complemento.

   Leve esta decisão adiante como color_scheme_priority: dark_first | light_first. As opções de paleta da Fase 2 e o congelamento de tokens da Fase 4 devem refletir esta prioridade.

Fase 2 — DIREÇÃO DE COR + DESIGN

1. Resolva a direção de cor antes da seleção de estilo.

2. Se o usuário não forneceu uma paleta explícita, ofereça 2–3 direções de paleta que se ajustem à categoria do produto e reflitam o color_scheme_priority da Fase 1:

   • Para projetos dark_first: lidere com opções de paleta escura (ex.: OLED dark-luxury, electric slate, deep navy), inclua uma opção clara apenas como última escolha.
   • Para projetos light_first: lidere com opções de paleta clara (ex.: commerce warm-energy, trust cool-neutral), inclua uma opção escura apenas se ela se encaixar na marca.
   • Peça ao usuário para escolher uma.

3. Se o usuário recusar escolher, selecione automaticamente a paleta mais adequada e explique o porquê em uma frase.

4. Carregue references/design-styles-catalog.md.

5. Do catálogo, selecione 2–3 estilos que melhor correspondam ao tipo de projeto, paleta escolhida e contexto.

6. Para cada estilo selecionado, gere um cartão de opção neste formato:

   [N]. **Nome do Estilo** — RECOMENDADO (se aplicável)
   Vibe: [uma frase descrevendo a vibe/clima]
   Estética chave: [3 características visuais definidoras]
   

7. Marque EXATAMENTE uma opção como RECOMENDADO com base na melhor adequação.

8. Apresente a lista numerada ao usuário e peça para escolher. Aguarde a resposta antes de prosseguir.

9. Se o usuário solicitar um estilo diferente que não está na lista, atenda e prossiga.

Fase 3 — GERAÇÃO DO PACOTE

1. Carregue references/platform-rules.md para as plataformas selecionadas.
2. Carregue references/output-template.md para o formato do pacote CJX.
3. Carregue references/output-bundle-rules.md para propriedade de ativos, posicionamento de classes compartilhadas, manifesto e auto-auditoria do pacote.
4. Carregue references/radius-choreography.md para resolver a gramática de raio, hierarquia de superfície aninhada e curvatura baseada em papéis antes de escrever qualquer CSS.
5. Carregue references/ux-guidelines.md ao gerar a saída final porque a completude de estado é obrigatória.
6. Aplique TODAS as Regras de Design Anti-IA abaixo.
7. Aplique as regras de plataforma para cada plataforma selecionada separadamente.
8. Resolva uma gramática de raio para a direção de estilo escolhida antes de escrever CSS de componente:
   • escolha 2–4 níveis de raio primários mais o nível pill, se necessário,
   • mapeie-os para papéis semânticos: shell, surface, inset, control, tight, pill,
   • mantenha a gramática consistente em todo o pacote,
   • garanta que superfícies aninhadas do mesmo material diminuam a curvatura.
9. Gere um diretório de pacote contendo:
   • html/
   • css/
   • js/
   • manifest.json
10. Gere um trio HTML/CSS/JS para cada combinação de tela/plataforma necessária.
11. Gere apenas as telas solicitadas e apenas as plataformas selecionadas.
12. Landing pages podem permanecer semânticas entre plataformas se o mesmo arquivo funcionar bem, mas se o layout mudar significativamente por plataforma, gere variantes de landing page específicas da plataforma também.
13. Cada arquivo HTML deve:
    • referenciar ../css/foundation.css
    • referenciar ../css/shared.css
    • referenciar seu arquivo CSS da tela
    • referenciar ../js/app.js compartilhado
    • referenciar seu arquivo JS da tela quando necessário
    • usar data-ai-id em todos os elementos estruturais principais
    • usar texto contextual e realista — nunca lorem ipsum
14. Cada tela de aplicativo gerada deve incluir ou lidar explicitamente com os quatro estados de UX de ux-guidelines.md:
    • carregamento
    • vazio
    • erro
    • sucesso
15. Estes estados podem estar visíveis na tela principal ou implementados como estados mock alternáveis via controles JS, mas eles devem existir no pacote enviado.
16. Resolva o estado visível padrão intencionalmente:
    • telas de gerador devem padronizar para vazio a menos que o usuário tenha solicitado explicitamente uma tela de sucesso pré-carregada/pronta para demonstração,
    • telas de resultado/revisão devem padronizar para sucesso a menos que a narrativa exija explicitamente outro estado primeiro,
    • nunca deixe uma tela de gerador implicar um resultado concluído antes de o usuário ter fornecido ou carregado entrada.
17. Aplique regras de realismo de tela utilitária em geradores, resultados, dashboards e telas com muitos formulários:
    • otimize para confiança, escaneabilidade e alinhamento antes do espetáculo,
    • mantenha o formulário principal, tela de estado, quadro de resultados e grupos de CTA em layouts de fluxo normal estáveis,
    • não use cartões de conteúdo sobrepostos ou posicionados absolutamente como a estrutura principal de uma tela utilitária,
    • mantenha a assimetria decorativa secundária para que nunca enfraqueça a clareza da tarefa ou a descoberta do CTA,
    • garanta que a tipografia hero em telas utilitárias seja lida de forma crível na viewport alvo em vez de depender de quebra teatral.
18. Antes de declarar a saída completa, execute a auto-auditoria do pacote de references/output-bundle-rules.md:
    • mova todos os seletores reutilizados em 2+ arquivos HTML para shared.css
    • garanta que nenhuma página dependa de um arquivo CSS de uma página irmã para renderizar corretamente
    • garanta que todos os ativos referenciados existam
    • garanta que manifest.json corresponda exatamente aos arquivos gerados
    • garanta que não existam arquivos para plataformas não selecionadas
    • garanta que a hierarquia de raio siga a gramática semântica escolhida e que superfícies aninhadas não se aplanem em camadas de raio igual
    • garanta que telas utilitárias passem na auditoria de realismo de layout em sua viewport alvo

Fase 4 — CONGELAMENTO DE TOKENS DE FUNDAÇÃO

1. Após gerar a primeira tela aprovada, extraia os valores exatos dos tokens para css/foundation.css.
2. Congele não apenas cor/tipo/movimento, mas também a gramática de raio semântica para o pacote.
3. Use este formato exato:

/* TOKENS DE FUNDAÇÃO CONGELADOS — NÃO MODIFICAR */
:root {
  --color-primary: <valor exato>;
  --color-secondary: <valor exato>;
  --color-accent: <valor exato>;
  --color-bg: <valor exato>;
  --color-surface: <valor exato>;
  --color-text: <valor exato>;
  --color-text-muted: <valor exato>;
  --font-heading: <pilha de fontes exata>;
  --font-body: <pilha de fontes exata>;
  --space-base: <valor exato>;
  --radius-1: <valor exato>;
  --radius-2: <valor exato>;
  --radius-3: <valor exato>;
  --radius-4: <valor exato>;