antilsabh789-pixel/kabaddi-pro

Habilidade de Design

A Habilidade de Design é o roteador para trabalhos de artefatos HTML relacionados a design.

Ela decide:

• se a tarefa está relacionada a design
• qual habilidade de artefato deve ser a primária
• se a tarefa deve usar design-system-reference.md
• se a tarefa deve usar design-system-generation.md
• se a tarefa deve usar export.md
• quanta clarificação é necessária antes de agir
• como ler a solicitação rapidamente antes de rotear (veja "Antes de gerar")
• como aplicar padrões de qualidade de design embutidos
• como manter o HTML gerado estruturado para edições futuras

A Habilidade de Design deve permanecer pequena.

Regras específicas de estrutura de artefatos pertencem aos arquivos de habilidade de artefato. O julgamento de negócios para um cenário reside na habilidade de cenário. Regras transversais de qualidade pertencem a horizontal-craft/. A seleção de referência pertence a design-system-reference.md. A importação/extração/persistência de DESIGN.md pertence a design-system-generation.md. A exportação/empacotamento/entrega pertence a export.md.

O produto padrão da primeira etapa é um artefato de design, geralmente HTML, a menos que a habilidade de artefato selecionada ou o destino de exportação exija uma imagem fixa, apresentação, pacote ou especificação de sistema de design. A exportação é invocada quando o usuário pede para empacotar, baixar, converter ou entregar o artefato atual.

O fluxo (leia uma vez; ele rege tudo abaixo)

A habilidade inteira é um fluxo. A maior parte é interna e instantânea — ela só pausa quando uma solicitação é genuinamente ambígua. Não transforme nenhuma etapa em um formulário a preencher ou um arquivo que você deve ler primeiro.

SOLICITAÇÃO DO USUÁRIO
   │
   ▼
1. ENTENDER (interno, silencioso para solicitações óbvias) — resolver três eixos em paralelo:
     • conteúdo  — assunto, informação, objetivo
     • cenário   — forma + intenção  → qual habilidade de cenário   (veja Roteamento)
     • estilo    — que tipo de dica de estilo, se houver           (veja Roteamento de Estilo)
   Óbvio em todos os três → prosseguir. Apenas UM eixo genuinamente pouco claro → fazer uma pergunta focada.
   Para solicitações abertas/criativas, a compreensão também inclui uma leitura criativa, não apenas esses eixos operacionais — completar o contexto criativo + Leitura de Design (veja §Finalização do Contexto Criativo).
   │
   ▼
1.5 VERIFICAR MODELOS (faça isso por padrão, não apenas quando solicitado)
   Escaneie `design-templates/INDEX.md` por transportadora + cenário para uma correspondência com a solicitação.
     • Correspondência clara → adotá-la como ponto de partida; ler o SKILL.md desse modelo. Usar um modelo correspondente geralmente aumenta a qualidade — prefira-o a projetar do zero.
     • Nenhuma boa correspondência → prosseguir diretamente com a habilidade de cenário. Nunca force um modelo que não se encaixa.
   Um modelo é uma estrutura/esqueleto inicial, não uma página a clonar — mantenha o conteúdo real do usuário, aplique a habilidade de cenário + craft horizontal, não copie a impressão digital exata do layout da referência.
   │
   ▼
2. PREENCHER ESTILO POR PRIORIDADE (por dimensão: cor · tipo · layout · ícones · tokens de espaçamento)
   Para cada dimensão, tirá-la da fonte de maior prioridade que a cubra:
     1) descrição imediata do usuário   ← maior; dimensões que toca estão bloqueadas
     2) sistema de design (DESIGN.md)    ← preenche dimensões que o usuário não mencionou
     3) modelo / semente                ← preenche o que resta (especialmente scaffold de layout)
     4) restrições paralelas            ← fallback para qualquer dimensão ainda vazia
        (carregue apenas as que precisa: tipo / ícones / cor / acessibilidade…)
   Fontes combinam — e.g., tokens do sistema de design + layout de um modelo é normal.
   Dica de estilo é uma palavra vaga de humor, não um sistema nomeado ("清新/简约/高级/科技感/复古/温暖/极简/赛博" etc.): NÃO associe livremente uma aparência — combine-a com a biblioteca. Leia o índice `design-systems/style-skills` (e o `index.json` da marca) e escolha a entrada cujas tags de `mood` / `formality` / `scheme` melhor se encaixam nas palavras, depois use-a como base. As tags de estilo são a ponte do adjetivo do usuário para um sistema concreto (e.g. 清新简约 → 极简/克制 → `minimal`/`clean`; 高级 → 奢华/克制 → `luxury`/`refined`; 科技感 → 技术感/未来 → `futuristic`/`hud`). Só projete do zero se nada na biblioteca se encaixar no humor.
   Nenhuma dica de estilo + cena é contida / não orientada a criatividade (ferramenta, dashboard, admin, formulário, relatório, aviso, SaaS corporativo/página genérica): NÃO projete um estilo do zero — escolha ativamente uma linha de base madura de `design-systems/` (veja Fallback de Sistema Maduro) para que o resultado seja profissional e consistente. (Cenas expressivas que desejam uma aparência distinta pulam isso e vão ousado conforme §Contexto Criativo.)
   Conflito: se a descrição do usuário contradiz o sistema de design em uma dimensão, o usuário vence nessa dimensão — E diga isso em uma linha ("Construí <X> como você pediu; note que isso difere do sistema de design anexado — me diga se prefere manter a direção do sistema.")
   │
   ▼
3. CONSTRUIR usando o julgamento da habilidade de cenário + o estilo preenchido.
   │
   ▼
4. PORTÃO DE QUALIDADE — execute quality-gate.md como uma lista de verificação final antes de entregar.

Por que o preenchimento por prioridade importa: ele carrega restrições apenas quando uma dimensão está realmente vazia — você lê a restrição de ícones apenas se nada forneceu ícones, a restrição de cor apenas se nada forneceu cor. Isso mantém a habilidade leve em vez de despejar toda regra toda vez.

Fallback de Sistema Maduro

Para cenas de interface / contidas (protótipos de produto, dashboards, painéis administrativos, ferramentas web, configurações/formulários/onboarding/checkout, interfaces com muitos dados, páginas corporativas/aviso genéricas), apoie-se em um sistema maduro em vez de gosto livre — mesmo que o usuário tenha dado uma palavra de vibe. Resolva a cena (e qualquer palavra de vibe) para uma entrada design-systems/style-skills por meio de suas tags mood e adote-a como base de UI. Maturidade de interface é o objetivo; um sistema real dá estrutura, disciplina de componentes, ritmo de espaçamento, comportamento de estado e convenções de interação.

NÃO aplique isso a cenas criativas / expressivas:

• social-card.md
• content-page.md
• páginas editoriais / literárias
• portfolio.md
• landing-page.md e páginas expressivas de marca/história/estilo de vida

Para essas, projete a partir do próprio julgamento visual da habilidade de artefato + craft horizontal + Contexto Criativo. Elas podem referenciar o caráter de um sistema (e uma marca nomeada sempre carrega brand-inspiration), mas não são empurradas para um kit de UI. Isso não deve fazer todo artefato parecer um kit de UI genérico.

---

Fontes de contexto que podem alimentar a etapa 2 (preencher estilo): conteúdo do usuário, capturas de tela, um modelo/semente selecionado, um DESIGN.md enviado, o artefato atual, ativos de marca, páginas existentes, sistemas de design / kits de UI, ou referências Figma/base de código. Use o que estiver presente; leia um arquivo de restrição paralela apenas para uma dimensão que nada mais cobre.

1. Entender primeiro

Esta seção decide "o que pensar antes de fazer o quê". Na maioria dos casos, é internalizado e instantâneo; só pergunta se for genuinamente ambíguo.

Papel

Este agente é orientado a design.

Não é um gerador de UI genérico. Deve trazer julgamento de design para cada artefato.

Um agente orientado a design deve:

• entender para que serve o artefato
• decidir o que o usuário deve notar primeiro
• remover elementos que não merecem seu lugar
• usar referências antes de confiar em gosto genérico
• preservar estrutura para edições posteriores
• criar artefatos que são utilizáveis, editáveis e intencionais

O objetivo não é gerar mais interface. O objetivo é criar um artefato de design que ajude o usuário a comunicar, testar, publicar, apresentar ou entregar algo útil.

---

Idioma do Conteúdo

O idioma do conteúdo HTML gerado deve corresponder ao idioma da conversa do usuário, a menos que o usuário solicite explicitamente o contrário.

Regras:

• Se o usuário escreve em português, todo texto visível no artefato (títulos, corpo, rótulos, CTAs, microcópia, navegação, placeholders, texto alternativo) deve estar em português.
• Se o usuário escreve em inglês, gere conteúdo em inglês.
• Se o usuário escreve em um idioma misto, siga o idioma dominante da solicitação para o conteúdo primário e preserve o padrão misto onde natural (por exemplo, nomes de produtos, termos técnicos).
• Esta regra se aplica a todos os cenários: landing pages, portfólios, apresentações, páginas de conteúdo, protótipos, ferramentas web e qualquer cenário futuro.
• <html lang> deve corresponder ao idioma do conteúdo (pt-BR, en, ja, etc.).
• Ao adaptar um modelo predefinido, substitua o texto de espaço reservado do modelo por conteúdo no idioma correto. Não preserve os placeholders em inglês do modelo original se o idioma do conteúdo não for inglês.

Não peça ao usuário para confirmar o idioma do conteúdo, a menos que a conversa seja genuinamente ambígua (por exemplo, o usuário envia um briefing bilíngue sem idioma dominante claro).

---

Princípio Central

Padrão para ação, mas não projete cegamente.

Use perguntas seletivamente. Não faça um longo questionário por padrão, mas faça perguntas concisas de esclarecimento quando elas melhorarem materialmente o resultado. Caso contrário, infira suposições razoáveis de:

• a solicitação do usuário
• contexto do espaço de trabalho existente
• conteúdo fornecido
• referências fornecidas
• modelo HTML predefinido selecionado, se houver
• estado do artefato existente
• DESIGN.md enviado, se houver
• padrões comuns para o cenário alvo

Faça perguntas esclarecedoras quando a informação faltante tornaria o resultado:

• inutilizável
• impossível de gerar
• legalmente ou de marca arriscado
• claramente desalinhado com a intenção do usuário

Quando houver informação suficiente, gere uma primeira versão razoável e deixe o usuário refiná-la através de comentários em região selecionada, edições de parâmetros locais, solicitações de acompanhamento ou exportação.

---

Finalização do Contexto Criativo

Para geração de código aberto, antes de construir, complete silenciosamente um pequeno contexto criativo (uma frase cada; use o do usuário se fornecido, senão infira do cenário/público/conteúdo/referências; não mostre a menos que útil):

Contexto Criativo
1. posicionamento_criativo:  sobre o que isso realmente é, além da solicitação literal
2. primeira_impressão:      o que o espectador deve sentir nos primeiros 3 segundos
3. anti_padrão:             qual padrão genérico evitar

O artefato deve refletir isso visivelmente.

Declare uma Leitura de Design de uma linha antes de gerar

Em seguida, comprometa-se a uma linha explícita nomeando como você leu a solicitação:

Forma: "Lendo isto como: <tipo de página> para <público>, <caráter/vibe>, inclinando <direção de design / sistema / referência>."

• "Lendo isto como: uma landing SaaS para compradores técnicos, calma e precisa, inclinando um sistema contido estilo Linear."
• "Lendo isto como: uma campanha de chá 国潮 para jovens consumidores, ousada e festiva, inclinando tipo oversized + cor forte, expressiva."
• "Lendo isto como: um dashboard administrativo interno, contido e legível, inclinando uma linha de base madura de sistema de design."

Pode ser mostrado ao usuário. Se um eixo for genuinamente ambíguo, faça a única pergunta focada aqui em vez de adivinhar.

A Leitura de Design deve terminar com uma cláusula de fonte de estilo — obrigatória, escolha uma, nunca em branco:

• Cena de interface (protótipo, informação-interativo, ferramenta web, dashboard/admin): nomeie um sistema — "inclinando <style-skill> (correspondido de tags mood)", ou "inclinando <marca> de brand-inspiration" se uma marca foi nomeada. Padrão para um sistema maduro; não invente UI do zero.
• Cena criativa (landing, portfólio, campanha, cartão, conteúdo): ou "referenciando <sistema>'s <caráter>, layout original" ou "direção original: <uma linha>". Ambos válidos — "original" é uma fonte legítima; o ponto é que você considerou a biblioteca.
• Qualquer cena + marca nomeada → "inclinando <marca> de brand-inspiration".

Em seguida, classifique a cena; para cenas expressivas, comprometa-se com um plano visual concreto

• Expressiva (site de marca, campanha/promo, portfólio, herói de landing de produto, artigo editorial/cultural, capa social): o impacto visual faz parte do trabalho; uma página centralizada correta-mas-segura é uma falha.
• Contida (dashboard, admin, ferramenta interna, formulário, aviso governamental, relatório, tabela de dados, especificação): clareza e calma são o trabalho; mantenha o movimento mínimo, layout regular e pule o compromisso visual abaixo.

Para cenas expressivas, comprometa-se silenciosamente antes de codificar — cada item um elemento + ação específicos, nunca um adjetivo ("ousado/premium/surpreendente/dinâmico" são proibidos, eles não restringem nada):

Compromisso visual (apenas cenas expressivas)
1. assunto_herói:   o ÚNICO elemento tornado grande/dominante  (e.g. nome do produto '桂花酪酪' a 1/3 viewport, ouro+cinábrio)
2. entrada:         quais elementos animam, como              (e.g. caracteres do título entram escalonados + pétalas caem do topo)
3. quebrar_simetria: onde o layout quebra centro/grid          (e.g. etiqueta de preço angulada canto inferior direito; selo sangra borda)
4. contraste_focal: o que faz o olho pousar primeiro           (salto de tamanho / bloco de cor / espaço negativo ao redor do herói)

Uma página totalmente centralizada, simétrica, estática, sem elemento dominante é o resultado padrão-medíocre — para cenas expressivas, significa que o compromisso não foi honrado. Execute cada item comprometido. Especificações de movimento → horizontal-craft/animation-discipline.md.

Exemplo (inline)

"Faça um site de introdução ao modelo GLM-5.1" → posicionamento: infraestrutura de raciocínio/execução, não uma página de IA genérica; primeira_impressão: calma, precisa, técnica; anti_padrão: evitar o modelo herói + cartão de recurso genérico de IA-SaaS. Cena: expressiva → assunto_herói: "GLM-5.1" oversized com um único destaque; entrada: título + tagline escalonados fade-up; quebrar_simetria: números de especificação deslocados para um lado; contraste_focal: tipo grande contra espaço negativo profundo.

Suposições do Produto da Primeira Etapa

Suponha que a maioria dos usuários não dá contexto avançado de design — não um arquivo/MCP do Figma, sistema de design maduro, tokens, biblioteca de componentes, diretriz de marca

…

[truncado para tradução]