Sebasm2kuy/trazabilidade

Habilidade de Design

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

Ela decide:

• se a tarefa é relacionada a design
• qual habilidade de artefato deve ser 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 de estrutura específicas de artefatos pertencem aos arquivos de habilidade de artefato. O julgamento de negócios para um cenário vive dentro da habilidade desse cenário. Regras de ofício transversais 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. Exportar/empacotar/entregar pertence a export.md.

O entregável padrão de 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, deck, 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 isto uma vez; rege tudo abaixo)

Toda a habilidade é 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 sugestão de estilo, se houver (veja Roteamento de Estilo)
   Óbvio em todos os três → prosseguir. Apenas UM eixo genuinamente incerto → fazer uma pergunta focada.
   Para solicitações abertas/criativas, entender também inclui uma leitura criativa, não apenas estes
   eixos operacionais — completar o contexto criativo + Leitura de Design (veja §Conclusão do Contexto Criativo).
   │
   ▼
1.5 VERIFICAR TEMPLATES (fazer isso por padrão, não apenas quando solicitado)
   Escanear `design-templates/INDEX.md` por portador + cenário para uma correspondência com a solicitação.
     • Correspondência clara → adotá-lo como ponto de partida; ler o SKILL.md desse template. Usar um
                      template correspondente geralmente aumenta a qualidade — prefira isso a projetar do zero.
     • Nenhuma boa correspondência → prosseguir diretamente com a habilidade de cenário. Nunca force um template que não se encaixa.
   Um template é uma estrutura/esqueleto inicial, não uma página a ser clonada — manter o conteúdo real do usuário,
   aplicar a habilidade de cenário + ofício transversal, não copiar a impressão digital 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, obtê-la da fonte de maior prioridade que a cobre:
     1) descrição imediata do usuário   ← mais alto; as dimensões que toca são bloqueadas
     2) sistema de design (DESIGN.md)    ← preenche dimensões que o usuário não abordou
     3) template / semente              ← preenche o que resta (especialmente scaffold de layout)
     4) restrições paralelas           ← fallback para qualquer dimensão ainda vazia
        (carregar apenas as que você precisa: tipo / ícones / cor / a11y …)
   As fontes se combinam — p. ex., tokens do sistema de design + layout de um template é normal.
   Sugestão de estilo é uma palavra de humor vaga, não um sistema nomeado ("清新/简约/高级/科技感/复古/温暖/极简/
   赛博" etc.): NÃO apenas associar livremente uma aparência — corresponder à biblioteca. Ler
   `design-systems/style-skills` índice (e `index.json` de marca) e escolher a entrada cujas tags `mood` /
   `formality` / `scheme` melhor se encaixam nas palavras, então usá-la como base. As tags de estilo são a
   ponte de um adjetivo do usuário para um sistema concreto (p. ex., 清新简约 → 极简/克制 → `minimal`/`clean`;
   高级 → 奢华/克制 → `luxury`/`refined`; 科技感 → 技术感/未来 → `futuristic`/`hud`). Só projetar
   do zero se nada na biblioteca se encaixar no humor.
   Nenhuma sugestão de estilo + cena é contida / não impulsionada pela criatividade (ferramenta, dashboard, admin,
   formulário, relatório, aviso, página genérica de SaaS/corporativa): NÃO projetar um estilo do zero —
   ativamente escolher 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 ousadas 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 dizê-lo em uma linha
   ("Construído <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 DA QUALIDADE — executar quality-gate.md como uma lista de verificação final enxuta 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 interface / cenas contidas (protótipos de produtos, dashboards, painéis de admin, ferramentas web, configurações/formulários/onboarding/checkout, interfaces com muitos dados, páginas genéricas corporativas/aviso), apoiar-se em um sistema maduro em vez de gosto livre — independentemente de o usuário ter dado uma palavra de vibe. Resolver a cena (e qualquer palavra de vibe) para uma entrada design-systems/style-skills através de suas tags mood e adotá-la como base da UI. Maturidade de interface é o objetivo; um sistema real fornece estrutura, disciplina de componentes, ritmo de espaçamento, comportamento de estados e convenções de interação.

NÃO aplicar 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, projetar a partir do próprio julgamento visual da habilidade de artefato + ofício transversal + 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 template/semente selecionado, um DESIGN.md carregado, o artefato atual, ativos de marca, páginas existentes, sistemas de design / kits de UI, ou referências do Figma/codebase. Usar o que estiver presente; ler um arquivo de restrição paralela apenas para uma dimensão que nada mais cobre.

1. Entender primeiro

Este bloco decide "o que pensar antes de fazer". Na maioria dos casos, é internalizado e instantâneo; só perguntar quando realmente 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 sejam 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ópias, navegação, placeholders, texto alternativo) deve estar em português.
• Se o usuário escreve em inglês, gerar conteúdo em inglês.
• Se o usuário escreve em um idioma misto, seguir o idioma dominante da solicitação para o conteúdo primário e preservar o padrão misto onde natural (p. ex., nomes de produtos, termos técnicos).
• Esta regra se aplica a todos os cenários: landing pages, portfólios, decks, páginas de conteúdo, protótipos, ferramenta web e qualquer cenário futuro.
• <html lang> deve corresponder ao idioma do conteúdo (pt-BR, en, ja, etc.).
• Ao adaptar um template predefinido, substituir o texto placeholder do template pelo conteúdo no idioma correto. Não preservar os placeholders em inglês originais do template se o idioma do conteúdo não for inglês.
• Quando conteúdo em português for detectado (por esta regra ou por solicitação do usuário), também carregar horizontal-craft/portuguese-typography.md como referência compartilhada. Regra de ferro para fontes (aplica-se mesmo antes de ler esse arquivo): qualquer fonte não-sistema nomeada em font-family deve ser realmente carregada (<link> ou @font-face), e uma página contendo português deve ter o nome de uma fonte portuguesa em seu font-family — nunca deixar uma fonte latina cair diretamente em system-ui, ou o português renderiza em um fallback não controlado. Detalhes sobre seleção/carregamento de fontes: horizontal-craft/fonts.md.

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

---

Princípio Central

Apadrinhar para ação, mas não projetar cegamente.

Usar perguntas seletivamente. Não fazer um longo questionário por padrão, mas fazer perguntas esclarecedoras concisas quando elas melhorariam materialmente o resultado. Caso contrário, inferir suposições razoáveis a partir de:

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

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

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

Quando houver informação suficiente, gerar uma primeira versão razoável e deixar 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.

---

Conclusão do Contexto Criativo

Para geração aberta, antes de construir, completar silenciosamente um pequeno contexto criativo (uma frase cada; usar a do usuário se fornecida, caso contrário inferir a partir de cenário/público/conteúdo/referências; não mostrar a menos que seja ú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 visivelmente isso.

Declarar uma Leitura de Design de uma linha antes de gerar

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

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

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

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

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

• Cena de interface (protótipo, info-interativo, ferramenta web, dashboard/admin): nomear um sistema — "inclinando <style-skill> (correspondido das tags de mood)", ou "inclinando <marca> de brand-inspiration" se uma marca foi nomeada. Padrão para um sistema maduro; não inventar UI do zero.
• Cena criativa (landing, portfólio, campanha, cartão, conteúdo): ou "referenciando <caráter> de <sistema>, 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, classificar a cena; para cenas expressivas, comprometer-se com um plano visual concreto

• Expressiva (site de marca, campanha/promo, portfólio, hero de landing de produto, recurso editorial/cultural, capa social): o impacto visual faz parte do trabalho; uma página centrada 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; manter movimento mínimo, layout regular e pular o compromisso visual abaixo.

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

Compromisso visual (apenas cenas expressivas)
1. assunto_hero: o ÚNICO elemento feito grande/dominante (p. ex., nome do produto '桂花酪酪' em 1/3 viewport, ouro+cinábrio)
2. entrada: quais elementos animam, como (p. ex., caracteres do título entram em escalonamento + pétalas caem do topo)
3. quebrar_simetria: onde o layout quebra centro/grid (p. ex., etiqueta de preço inclinada no canto inferior direito; selo sangra da borda)
4. contraste_focal: o que faz o olho pousar primeiro (salto de tamanho / bloco de cor / espaço em branco ao redor do hero)

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

Exemplo (em linha)

"Criar um site de apresentação do modelo GLM-5.1" → posicionamento: infraestrutura de raciocínio/execução, não uma página de IA genérica; primeira_impressão: calmo, preciso, técnico; anti_padrão: evitar o template genérico de hero + feature-card de IA-SaaS. Cena: expressiva → assunto_hero: "GLM-5.1" superdimensionado com um único acento; entrada: título + tagline em fade-up escalonado; quebrar_simetria: números de especificação deslocados para um lado; contraste_focal: tipo grande contra espaço negativo profundo.

Suposições do Produto de Primeira Etapa

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

...[truncado para tradução]