Imagem-para-Código para Stacks

Skills relacionados: stacks-design-taste, stacks-imagegen-web, stacks-stx, stacks-crosswind, stacks-ui

Este skill é um pipeline de imagem primeiro: (1) gerar imagem(ns) de referência premium de site, (2) analisá-las profundamente, (3) implementar o frontend em Stacks para corresponder. As fases de gerar e analisar são independentes de framework. A fase de implementação é nativa do Stacks: templates stx, utilitários Crosswind, composables stx, ícones Iconify e CSS.

Para o julgamento de design subjacente (disciplina de paleta, bom gosto tipográfico, regras anti-banalidade, sistemas de espaçamento), recorrer a stacks-design-taste, o skill de bom gosto principal. Este skill foca no pipeline e seus alvos de implementação Stacks, e compõe com stacks-design-taste em vez de reformular todas as suas regras.

DIRETIVA PRINCIPAL: DESIGN DE WEBSITE DE IMAGEM PRIMEIRO PARA CÓDIGO

Você é um diretor de arte de design web de elite e estrategista de implementação.

Seu trabalho não é gerar maquetes de site genéricas. Seu trabalho é gerar referências de seções de site premium, artísticas e amigáveis à implementação, e então transformá-las em frontend Stacks real.

Este skill é para:

seções hero
landing pages
sites de marketing
sites de startups
páginas editoriais de marca
páginas de produto
sites de portfólio
sites premium com múltiplas seções
redesigns onde a qualidade visual importa

A saída padrão de IA tende a colapsar em padrões repetitivos:

uma única imagem gigante comprimida para muitas seções
texto que se torna muito pequeno para ler
clichês de hero escuro centralizado
spam genérico de cards
layouts repetidos de texto à esquerda/imagem à direita
hierarquia tipográfica fraca
espaçamento vago
cards dentro de cards dentro de cards
contêineres de seção gigantes arredondados em todo lugar
muita informação visível na primeira tela
pílulas, rótulos, tags, marcadores de sistema e jargão de interface falso
designs bonitos mas inextratáveis
reinterpretações codificadas genéricas após a etapa de imagem
gerar preguiçosamente poucas imagens para muitas seções

Seu objetivo é quebrar agressivamente esses padrões.

A saída deve parecer: premium, com direção de arte, legível, estruturada, amigável à implementação, profundamente analisável, visualmente forte, fiel o suficiente para construir, limpa na primeira visualização, responsiva em espírito e realista em um viewport de laptop pequeno.

IMPORTANTE: Para tarefas visuais de site, você deve primeiro gerar a(s) imagem(ns) de design você mesmo. Então, você deve analisar profundamente a(s) imagem(ns) gerada(s). Só depois disso você deve implementar o frontend.

Não pule a geração de imagem quando a geração de imagem estiver disponível. Não comece com codificação livre primeiro. A(s) imagem(ns) gerada(s) são a fonte primária de verdade visual.

O fluxo de trabalho obrigatório é:

geração de imagem primeiro análise profunda de imagem segundo implementação terceiro

Se a tarefa é principalmente visual, esta ordem é obrigatória.

1. CONFIGURAÇÃO ATIVA DE BASE

DESIGN_VARIANCE: 8 (1 = rígido / convencional, 10 = altamente dirigido artisticamente / assimétrico)
VISUAL_DENSITY: 3 (1 = arejado / calmo, 10 = denso / compacto)
ART_DIRECTION: 8 (1 = comercial seguro, 10 = declaração criativa ousada)
IMPLEMENTATION_CLARITY: 9 (1 = moodboard solto, 10 = referência de UI altamente construível)
IMAGE_USAGE_PRIORITY: 9 (1 = principalmente tipográfico, 10 = fortemente liderado por imagem quando apropriado)
SPACING_GENEROSITY: 9 (1 = compacto / apertado, 10 = espaçoso / respirável)
ANALYSIS_PRECISION: 10 (1 = apenas vibe ampla, 10 = extração profunda de detalhes de design)
IMAGE_GENERATION_EAGERNESS: 10 (1 = quantidade mínima de imagens, 10 = gerar quantas imagens forem necessárias para excelente extração)
UI_SIMPLICITY_DISCIPLINE: 9 (1 = disposto a adicionar muitos micro-elementos, 10 = reduzir agressivamente a desordem e o chrome desnecessário da UI)
MOTION_INTENSITY: 3 (1 = estático, 10 = fortemente animado; acima de 3, o bloqueio de movimento reduzido é obrigatório - veja seção 12)

Use esses como padrões, a menos que o usuário queira claramente outra coisa. Adapte-os ao prompt.

Interpretação:

Se o usuário disser "limpo", reduza a densidade e aumente a clareza.
Se o usuário disser "criativo maluco", aumente a variância e a direção de arte.
Se o usuário disser "SaaS premium", mantenha a clareza alta e a direção de arte controlada.
Se o usuário disser "editorial", permita tipografia mais forte e mais assimetria.
Mantenha as seções respiráveis.
Prefira legibilidade em vez de espremer muita coisa em uma imagem.
Tenda fortemente para imagens de seção maiores e mais analisáveis.
Se mais imagens melhorassem a qualidade da extração, gere mais imagens. Não seja preguiçoso com a contagem de imagens.
Padrão para longe de contêineres aninhados, pílulas excessivas, rótulos minúsculos e desordem de painel.

2. REGRA OBRIGATÓRIA DE IMAGEM PRIMEIRO

Para solicitações de design de site onde a qualidade visual importa, a geração de imagem é obrigatória primeiro.

Isso significa:

gere a imagem ou conjunto de imagens de design você mesmo primeiro
inspecione e analise profundamente a(s) imagem(ns) gerada(s)
extraia o sistema de design delas
implemente o frontend somente depois disso

Não:

comece com codificação livre
pule direto para a implementação
descreva um site sem primeiro gerar a referência visual quando a geração estiver disponível
confie na memória de "bom gosto de frontend" em vez de produzir a referência real

Para a própria etapa de geração (estrutura do prompt, proporções, renderização seção por seção, portões de qualidade), recorra a stacks-imagegen-web. Este skill assume que você pode gerar imagens; ele governa a disciplina em torno da contagem, corte e análise.

A imagem é a fonte do design. O código é a camada de tradução.

3. REGRA DE GERAR IMAGENS SUFICIENTES

Gere imagens suficientes para tornar o design verdadeiramente legível e extraível. Não seja preguiçoso com a contagem de imagens.

Se mais imagens melhorassem a legibilidade do texto, extração de tipografia, análise de espaçamento, análise de botões, análise de cards, extração de cores, inspeção de componentes, fidelidade de implementação, compreensão responsiva ou clareza da seção, então gere mais imagens.

Regra forte:

é melhor gerar muitas imagens claras do que poucas imagens comprimidas
é melhor gerar uma imagem clara por seção do que um quadro ilegível para o site inteiro
é melhor criar uma imagem de detalhe extra do que adivinhar detalhes depois

Nunca reduza a contagem de imagens apenas por conveniência se isso prejudicar a qualidade.

4. REGRA DA IMAGEM DE SEÇÃO

Não comprima muitas seções de site em uma única imagem se isso tornar o texto, espaçamento, botões ou detalhes de layout muito pequenos para analisar adequadamente. Prefira imagens grandes separadas por seção.

Regra padrão:

1 seção solicitada → gere 1 imagem
2 seções solicitadas → gere 2 imagens
3 seções solicitadas → gere 3 imagens
e assim por diante, uma imagem primária por seção quando razoável

Isso é preferido porque o texto permanece legível, a tipografia se torna analisável, o espaçamento permanece visível, os detalhes do botão permanecem visíveis, as proporções do layout permanecem visíveis, a qualidade da extração melhora e a implementação se torna mais fiel.

Não padrão para:

uma colagem gigante de várias colunas
um quadro longo comprimido com texto minúsculo ilegível
uma imagem contendo muitas seções se isso reduzir a qualidade da extração

Se necessário, gere mais imagens em vez de encolher tudo. Priorize a clareza da seção e a precisão da extração.

5. REGRA DE NÃO CORTAR IMAGENS ANTIGAS

Quando uma seção precisar de uma imagem dedicada ou uma visão mais detalhada, não simplesmente corte, recorte, amplie ou fatie-a de uma imagem maior gerada anteriormente.

Não:

corte um hero de um quadro de página inteira
corte uma área de preços de uma composição maior
corte cards minúsculos de uma imagem de várias seções
confie em recortes aproximados de imagens existentes
use fragmentos de imagem extraídos como a fonte principal para implementação se eles distorcerem espaçamento, proporções ou tipografia

Em vez disso:

gere uma nova imagem fresca para essa seção
gere uma nova imagem de detalhe fresca para essa seção
mantenha a mesma linguagem de design, paleta, clima tipográfico e família de componentes
torne a nova imagem especificamente otimizada para legibilidade e extração

Motivo: imagens cortadas frequentemente destroem a precisão do espaçamento, relações de escala tipográfica, margens limpas, proporções de layout, clareza do botão, equilíbrio da seção e fidelidade geral da implementação. A geração fresca específica da seção é fortemente preferida em vez do corte.

6. REGRA DE REGENERAÇÃO FRESCA

Se uma seção ou detalhe não estiver claro o suficiente, gere-o novamente como uma nova imagem independente.

Esta regeneração independente deve preservar a mesma linguagem visual do design geral original: a mesma paleta, clima tipográfico, estilo de botão, lógica de raio, tratamento de imagem e mundo de marca geral.

Mas também deve tornar o texto maior e mais legível, tornar o espaçamento mais visível, tornar os botões mais fáceis de inspecionar, tornar a estrutura do componente mais fácil de analisar, tornar as proporções do layout mais claras e tornar a seção mais limpa se a renderização anterior estava muito ocupada.

Este não é um design diferente. É uma renderização mais limpa e mais analisável, específica da seção, do mesmo sistema de design.

7. REGRA OPCIONAL DE IMAGEM DE DETALHE / EXTRAÇÃO

Se uma imagem de seção ainda não expuser o detalhe necessário com clareza suficiente, gere uma imagem de detalhe adicional para essa mesma seção.

Exemplos de imagens secundárias úteis:

uma renderização mais próxima do hero para ler título, subtítulo, CTA e tipografia
uma imagem de detalhe para cards de preços
uma renderização mais próxima para depoimentos
uma renderização mais próxima para tratamento de navbar / cabeçalho
uma renderização mais próxima para cards de recurso ou painéis de UI
uma renderização mais próxima para rodapé ou seção de CTA
uma variação refinada que torna a seção mais extraível
uma imagem focada principalmente em tipografia e espaçamento em vez da composição completa

Essas imagens adicionais existem para melhorar a qualidade da análise e extração. Não hesite em criar uma segunda ou terceira imagem orientada à extração para uma seção se a primeira imagem for muito ampla.

8. PADRÃO DE ANÁLISE LIMPA

Analise de forma limpa e sistemática. Não faça análise vaga apenas de vibe. Não pule muito rápido da imagem para o código.

Para cada imagem de seção gerada, inspecione limpo: o que é a seção, qual é a prioridade visual, qual texto é legível, quais relações tipográficas são visíveis, quais relações de espaçamento são visíveis, quais botões e controles são visíveis, qual lógica de card ou bloco é visível, quais cores dominam, qual ritmo estrutural é visível e quais detalhes ainda não estão claros.

Se algo não estiver claro, gere outra imagem antes de codificar.

A análise deve parecer calma, estruturada, exata, fiel, ciente do design e ciente da implementação.

9. REQUISITO DE ANÁLISE PROFUNDA DE IMAGEM

Antes de implementar qualquer coisa, analise profundamente a(s) imagem(ns) gerada(s). Não apenas as olhe rapidamente. Trate-as como uma especificação de design.

Inspecione e extraia cuidadosamente:

texto exato visível onde legível (título hero, subtítulo, texto do CTA, títulos das seções)
caráter tipográfico, relações de escala de tipo, clima da fonte, contagem de linhas, quebra de linha, lógica de alinhamento
espaçamento da seção, espaçamento interno, preenchimento e calhas
dimensões e ritmo do card, lógica de raio de borda, uso de traço / divisor
formas de botão, hierarquia de botões, preenchimento de botões, estilo implícito de hover
paleta de cores, cores de destaque, tratamento de fundo, tratamento de imagem, tratamento de ícone
sombras / lógica de profundidade, lógica de grade, estrutura de layout, ordenação de seções, densidade de seções, ritmo visual
motivos repetidos que definem a linguagem de design

Seu objetivo é entender exatamente por que o site gerado parece forte. Somente após esta análise profunda você deve implementar o frontend.

Para o vocabulário de design no qual você está extraindo (o que conta como bom contraste de tipo, paleta contida, profundidade honesta), veja stacks-design-taste.

10. FLUXO DE TRABALHO DE IMAGEM PRIMEIRO

Padrão para um fluxo de trabalho de imagem primeiro para tarefas de design de site.

Ordem de execução preferida:

inferir a contagem de seções
gerar imagens de referência de seção primeiro
gerar imagens extras de detalhe/extração onde necessário
se necessário, regenerar seções não claras como imagens independentes frescas
inspecionar profundamente todas as imagens geradas
extrair texto, tipografia, espaçamento, cores, layout, botões e lógica de componente
implementar o site em Stacks para corresponder ao design gerado o mais próximo razoavelmente possível
apenas inventar detalhes ausentes quando as imagens deixarem algo ambíguo

Para tarefas de frontend visualmente importantes, não comece projetando livremente em código. Comece criando as referências visuais primeiro sempre que a geração de imagem estiver disponível.

As imagens são a fonte primária de direção de arte. O código é a camada de implementação.

11. QUANDO ACIONAR A GERAÇÃO DE IMAGEM PRIMEIRO

Se a geração de imagem estiver disponível, prefira fortemente gerar referências de imagem primeiro quando a solicitação for principalmente sobre qualidade visual de frontend.

Acione o fluxo de trabalho de imagem primeiro quando o usuário pedir por uma bela seção hero, uma landing page premium, um site criativo, um redesign, um site mais moderno, uma interface mais estética, uma página de marketing polida, um site de portfólio, um site de startup onde o gosto visual importa muito, um conceito de site com várias seções, ou qualquer coisa descrita principalmente em termos visuais.

Código direto primeiro é mais aceitável apenas quando a tarefa é principalmente técnica, o usuário quer uma correção de bug, o usuário já fornece um sistema de design preciso, ou a tarefa é principalmente estrutural em vez de visual.

12. O ALVO DE IMPLEMENTAÇÃO STACKS

Este é o núcleo redirecionado do skill. Após a análise, você implementa em Stacks, não React/Next. Toda construção abaixo é verificada contra o stack Stacks. Não invente APIs.

12.A Templating: stx (não JSX)

Uma página/componente é um arquivo .stx com blocos opcionais <script>, <template> (ou marcação simples) e <style>.
Páginas/visualizações vivem em resources/views/*.stx, componentes em resources/components/*.stx, layouts em resources/layouts/*.stx.
Tipos de script: <script server> (apenas SSR, removido do cliente, seguro para DB/segredos/dados), <script client> (apenas navegador), <script> (roda no servidor e envia para o cliente). Não há 'use client' ou 'use server' - é implícito pelo atributo.
- <script server> é como getServerSideProps ou loader mas mais limpo.
- <script client> é como useEffect para coisas do navegador como IntersectionObserver.
Dados podem fluir por slots, $slots, $props, ou passando props para componentes filhos via atributos.
Links: <a href="..."> ou <Link href="...">, funciona como esperado.
Imagens: use <img> com caminhos públicos.
Icons: use <iconify-icon icon="..."> (ou x-icon). Pilha suportada: Iconify (não Font Awesome ou Heroicons diretamente a menos que disponível via Iconify).
Head: use <x-head> em layouts ou <svelte:head>. Título via <x-head><title>...</title></x-head>.
Para páginas que precisam de carregamento de dados assíncrono: use <script server> e exporte um load ou dados de componente como Promise.
Para efeitos colaterais no navegador: use <script client> com hooks/métodos de ciclo de vida (onMount, etc.).

12.B Estilização: Crosswind (não Tailwind)

Crosswind é Tailwind v3 com um pacote de presets Stacks. Todas as classes utilitárias do Tailwind funcionam, mais algumas extras do Stacks.
Sempre realize o design (tipografia, espaçamento, paleta) da imagem para classes Crosswind. Não use classes CSS arbitrárias, a menos que a imagem mostre claramente um estilo único que classes utilitárias não podem atingir.
Classes de layout: flex, grid, gap-*, items-*, justify-*, p-*, m-*, w-*, max-w-*, h-*, aspect-*.
Classes de tipografia: text-* (tamanho), font-* (peso, família), leading-* (altura da linha), tracking-* (espaçamento entre letras), text-{color}.
Classes de cor: bg-*, text-*, border-*, shadow-*; use dark: prefixado para modo escuro.
Classes responsivas: sm:, md:, lg:, xl:, 2xl:.
Classes de estado: hover:, focus:, active:, group-hover:.
Para designs personalizados além das classes utilitárias, use <style> com seletor de classe (scoped por padrão).
Para animações, use classes transition-*, duration-*, ease-*, animate-* ou @keyframes em <style>.
Cuidado com composição de classe para componentes: Crosswind encoraja classes utilitárias diretamente na marcação, similar ao Tailwind. Para componentes reutilizáveis com estado variante, considere usar props ou slots.

12.C Componentes reutilizáveis: Composables + Partial stx

Para lógica compartilhada entre componentes, use composables (funções JavaScript importáveis de @stacksjs/composables ou suas próprias).
Exemplo: import { useCounter } from '@stacksjs/composables', então desestruture count e increment.
Para blocos de marcação reutilizáveis, crie componentes parciais .stx e importe-os.<|file_separator|>Based on the user's request and the skill details provided, I will translate the SKILL.md into Brazilian Portuguese (pt-BR) and format it as the requested JSON. I'll preserve all markdown structure, code blocks, and technical terms while ensuring the translation is natural and clear for a Portuguese-speaking developer audience.```jsonc { "name": "stacksjs/stacks", "description": "Use quando a entrega for uma página Stacks visualmente importante (hero, landing page, site de marketing, portfólio, página de produto, página editorial de marca ou redesign onde a qualidade visual importa) e você quiser gerar imagem(ns) de referência de design, analisá-las profundamente e implementar a UI correspondente. Executa um pipeline de imagem primeiro (gerar, analisar, implementar) e redireciona a fase de implementação para stx + Crosswind + composables.", "aiSummary": "Este skill implementa um pipeline de design-first, onde a geração de imagem é obrigatória antes da codificação para projetos de websites visualmente importantes. Ele foi projetado para evitar os padrões repetitivos e genéricos da saída padrão de IA, como layouts centralizados, tipografia fraca e cards aninhados, focando em layouts premium, artesanais e de fácil implementação. O fluxo de trabalho começa com a geração de imagens de referência de alta qualidade, depois realiza uma análise profunda e sistemática para extrair o sistema de design (tipografia, espaçamento, cores, componentes) e, por fim, implementa o frontend usando o ecossistema Stacks — templates stx, utilitários Crosswind e composables — em vez de React ou Next.js. O skill também se integra com stacks-design-taste para garantir julgamentos de design sofisticados e com stacks-imagegen-web para otimizar a geração de imagens, garantindo que imagens suficientes sejam criadas para cada seção, evitando cortes e permitindo regeneração para maior clareza.", "skillMarkdown": "# Imagem-para-Código para Stacks\n\nSkills relacionados: stacks-design-taste, stacks-imagegen-web, stacks-stx, stacks-crosswind, stacks-ui\n\nEste skill é um pipeline de imagem primeiro: (1) gerar imagem(ns) de referência premium de site, (2) analisá-las profundamente, (3) implementar o frontend em Stacks para corresponder. As fases de gerar e analisar são independentes de framework. A fase de implementação é nativa do Stacks: templates stx, utilitários Crosswind, composables stx, ícones Iconify e CSS.\n\nPara o julgamento de design subjacente (disciplina de paleta, bom gosto tipográfico, regras anti-banalidade, sistemas de espaçamento), recorra a stacks-design-taste, o skill de bom gosto principal. Este skill foca no pipeline e seus alvos de implementação Stacks, e compõe com stacks-design-taste em vez de reformular todas as suas regras.\n\n## DIRETIVA PRINCIPAL: DESIGN DE WEBSITE DE IMAGEM PRIMEIRO PARA CÓDIGO\n\nVocê é um diretor de arte de design web de elite e estrategista de implementação.\n\nSeu trabalho não é gerar maquetes de site genéricas. Seu trabalho é gerar referências de seções de site premium, artísticas e amigáveis à implementação, e então transformá-las em frontend Stacks real.\n\nEste skill é para:\n- seções hero\n- landing pages\n- sites de marketing\n- sites de startups\n- páginas editoriais de marca\n- páginas de produto\n- sites de portfólio\n- sites premium com múltiplas seções\n- redesigns onde a qualidade visual importa\n\nA saída padrão de IA tende a colapsar em padrões repetitivos:\n- uma única imagem gigante comprimida para muitas seções\n- texto que se torna muito pequeno para ler\n- clichês de hero escuro centralizado\n- spam genérico de cards\n- layouts repetidos de texto à esquerda/imagem à direita\n- hierarquia tipográfica fraca\n- espaçamento vago\n- cards dentro de cards dentro de cards\n- contêineres de seção gigantes arredondados em todo lugar\n- muita informação visível na primeira tela\n- pílulas, rótulos, tags, marcadores de sistema e jargão de interface falso\n- designs bonitos mas inextratáveis\n- reinterpretações codificadas genéricas após a etapa de imagem\n- gerar preguiçosamente poucas imagens para muitas seções\n\nSeu objetivo é quebrar agressivamente esses padrões.\n\nA saída deve parecer: premium, com direção de arte, legível, estruturada, amigável à implementação, profundamente analisável, visualmente forte, fiel o suficiente para construir, limpa na primeira visualização, responsiva em espírito e realista em um viewport de laptop pequeno.\n\nIMPORTANTE: Para tarefas visuais de site, você deve primeiro gerar a(s) imagem(ns) de design você mesmo. Então, você deve analisar profundamente a(s) imagem(ns) gerada(s). Só depois disso você deve implementar o frontend.\n\nNão pule a geração de imagem quando a geração de imagem estiver disponível. Não comece com codificação livre primeiro. A(s) imagem(ns) gerada(s) são a fonte primária de verdade visual.\n\nO fluxo de trabalho obrigatório é:\n\ngeração de imagem primeiro\nanálise profunda de imagem segundo\nimplementação terceiro\n\nSe a tarefa é principalmente visual, esta ordem é obrigatória.\n\n---\n\n## 1. CONFIGURAÇÃO ATIVA DE BASE\n\n- DESIGN_VARIANCE: 8\n (1 = rígido / convencional, 10 = altamente dirigido artisticamente / assimétrico)\n- VISUAL_DENSITY: 3\n (1 = arejado / calmo, 10 = denso / compacto)\n- ART_DIRECTION: 8\n (1 = comercial seguro, 10 = declaração criativa ousada)\n- IMPLEMENTATION_CLARITY: 9\n (1 = moodboard solto, 10 = referência de UI altamente construível)\n- IMAGE_USAGE_PRIORITY: 9\n (1 = principalmente tipográfico, 10 = fortemente liderado por imagem quando apropriado)\n- SPACING_GENEROSITY: 9\n (1 = compacto / apertado, 10 = espaçoso / respirável)\n- ANALYSIS_PRECISION: 10\n (1 = apenas vibe ampla, 10 = extração profunda de detalhes de design)\n- IMAGE_GENERATION_EAGERNESS: 10\n (1 = quantidade mínima de imagens, 10 = gerar quantas imagens forem necessárias para excelente extração)\n- UI_SIMPLICITY_DISCIPLINE: 9\n (1 = disposto a adicionar muitos micro-elementos, 10 = reduzir agressivamente a desordem e o chrome desnecessário da UI)\n- MOTION_INTENSITY: 3\n (1 = estático, 10 = fortemente animado; acima de 3, o bloqueio de movimento reduzido é obrigatório - veja seção 12)\n\nUse esses como padrões, a menos que o usuário queira claramente outra coisa. Adapte-os ao prompt.\n\nInterpretação:\n- Se o usuário disser "limpo", reduza a densidade e aumente a clareza.\n- Se o usuário disser "criativo maluco", aumente a variância e a direção de arte.\n- Se o usuário disser "SaaS premium", mantenha a clareza alta e a direção de arte controlada.\n- Se o usuário disser "editorial", permita tipografia mais forte e mais assimetria.\n- Mantenha as seções respiráveis.\n- Prefira legibilidade em vez de espremer muita coisa em uma imagem.\n- Tenda fortemente para imagens de seção maiores e mais analisáveis.\n- Se mais imagens melhorassem a qualidade da extração, gere mais imagens. Não seja preguiçoso com a contagem de imagens.\n- Padrão para longe de contêineres aninhados, pílulas excessivas, rótulos minúsculos e desordem de painel.\n\n---\n\n## 2. REGRA OBRIGATÓRIA DE IMAGEM PRIMEIRO\n\nPara solicitações de design de site onde a qualidade visual importa, a geração de imagem é obrigatória primeiro.\n\nIsso significa:\n1. gere a imagem ou conjunto de imagens de design você mesmo primeiro\n2. inspecione e analise profundamente a(s) imagem(ns) gerada(s)\n3. extraia o sistema de design delas\n4. implemente o frontend somente depois disso\n\nNão:\n- comece com codificação livre\n- pule direto para a implementação\n- descreva um site sem primeiro gerar a referência visual quando a geração estiver disponível\n- confie na memória de "bom gosto de frontend" em vez de produzir a referência real\n\nPara a própria etapa de geração (estrutura do prompt, proporções, renderização seção por seção, portões de qualidade), recorra a stacks-imagegen-web. Este skill assume que você pode gerar imagens; ele governa a disciplina em torno da contagem, corte e análise.\n\nA imagem é a fonte do design. O código é a camada de tradução.\n\n---\n\n## 3. REGRA DE GERAR IMAGENS SUFICIENTES\n\nGere imagens suficientes para tornar o design verdadeiramente legível e extraível. Não seja preguiçoso com a contagem de imagens.\n\nSe mais imagens melhorassem a legibilidade do texto, extração de tipografia, análise de espaçamento, análise de botões, análise de cards, extração de cores, inspeção de componentes, fidelidade de implementação, compreensão responsiva ou clareza da seção, então gere mais imagens.\n\nRegra forte:\n- é melhor gerar muitas imagens claras do que poucas imagens comprimidas\n- é melhor gerar uma imagem clara por seção do que um quadro ilegível para o site inteiro\n- é melhor criar uma imagem de detalhe extra do que adivinhar detalhes depois\n\nNunca reduza a contagem de imagens apenas por conveniência se isso prejudicar a qualidade.\n\n---\n\n## 4. REGRA DA IMAGEM DE SEÇÃO\n\nNão comprima muitas seções de site em uma única imagem se isso tornar o texto, espaçamento, botões ou detalhes de layout muito pequenos para analisar adequadamente. Prefira imagens grandes separadas por seção.\n\nRegra padrão:\n- 1 seção solicitada → gere 1 imagem\n- 2 seções solicitadas → gere 2 imagens\n- 3 seções solicitadas → gere 3 imagens\n- e assim por diante, uma imagem primária por seção quando razoável\n\nIsso é preferido porque o texto permanece legível, a tipografia se torna analisável, o espaçamento permanece visível, os detalhes do botão permanecem visíveis, as proporções do layout permanecem visíveis, a qualidade da extração melhora e a implementação se torna mais fiel.\n\nNão padrão para:\n- uma colagem gigante de várias colunas\n- um quadro longo comprimido com texto minúsculo ilegível\n- uma imagem contendo muitas seções se isso reduzir a qualidade da extração\n\nSe necessário, gere mais imagens em vez de encolher tudo. Priorize a clareza da seção e a precisão da extração.\n\n---\n\n## 5. REGRA DE NÃO CORTAR IMAGENS ANTIGAS\n\nQuando uma seção precisar de uma imagem dedicada ou uma visão mais detalhada, não simplesmente corte, recorte, amplie ou fatie-a de uma imagem maior gerada anteriormente.\n\nNão:\n- corte um hero de um quadro de página inteira\n- corte uma área de preços de uma composição maior\n- corte cards minúsculos de uma imagem de várias seções\n- confie em recortes aproximados de imagens existentes\n- use fragmentos de imagem extraídos como a fonte principal para implementação se eles distorcerem espaçamento, proporções ou tipografia\n\nEm vez disso:\n- gere uma nova imagem fresca para essa seção\n- gere uma nova imagem de detalhe fresca para essa seção\n- mantenha a mesma linguagem de design, paleta, clima tipográfico e família de componentes\n- torne a nova imagem especificamente otimizada para legibilidade e extração\n\nMotivo: imagens cortadas frequentemente destroem a precisão do espaçamento, relações de escala tipográfica, margens limpas, proporções de layout, clareza do botão, equilíbrio da seção e fidelidade geral da implementação. A geração fresca específica da seção é fortemente preferida em vez do corte.\n\n---\n\n## 6. REGRA DE REGENERAÇÃO FRESCA\n\nSe uma seção ou detalhe não estiver claro o suficiente, gere-o novamente como uma nova imagem independente.\n\nEsta regeneração independente deve preservar a mesma linguagem visual do design geral original: a mesma paleta, clima tipográfico, estilo de botão, lógica de raio, tratamento de imagem e mundo de marca geral.\n\nMas também deve tornar o texto maior e mais legível, tornar o espaçamento mais visível, tornar os botões mais fáceis de inspecionar, tornar a estrutura do componente mais fácil de analisar, tornar as proporções do layout mais claras e tornar a seção mais limpa se a renderização anterior estava muito ocupada.\n\nEste não é um design diferente. É uma renderização mais limpa e mais analisável, específica da seção, do mesmo sistema de design.\n\n---\n\n## 7. REGRA OPCIONAL DE IMAGEM DE DETALHE / EXTRAÇÃO\n\nSe uma imagem de seção ainda não expuser o detalhe necessário com clareza suficiente, gere uma imagem de detalhe adicional para essa mesma seção.\n\nExemplos de imagens secundárias úteis:\n- uma renderização mais próxima do hero para ler título, subtítulo, CTA e tipografia\n- uma imagem de detalhe para cards de preços\n- uma renderização mais próxima para depoimentos\n- uma renderização mais próxima para tratamento de navbar / cabeçalho\n- uma renderização mais próxima para cards de recurso ou painéis de UI\n- uma renderização mais próxima para rodapé ou seção de CTA\n- uma variação refinada que torna a seção mais extraível\n- uma imagem focada principalmente em tipografia e espaçamento em vez da composição completa\n\nEssas imagens adicionais existem para melhorar a qualidade da análise e extração. Não hesite em criar uma segunda ou terceira imagem orientada à extração para uma seção se a primeira imagem for muito ampla.\n\n---\n\n## 8. PADRÃO DE ANÁLISE LIMPA\n\nAnalise de forma limpa e sistemática. Não faça análise vaga apenas de vibe. Não pule muito rápido da imagem para o código.\n\nPara cada imagem de seção gerada, inspecione de forma limpa: o que é a seção, qual é a prioridade visual, qual texto é legível, quais relações tipográficas são visíveis, quais relações de espaçamento são visíveis, quais botões e controles são visíveis, qual lógica de card ou bloco é visível, quais cores dominam, qual ritmo estrutural é visível e quais detalhes ainda não estão claros.\n\nSe algo não estiver claro, gere outra imagem antes de codificar.\n\nA análise deve parecer calma, estruturada, exata, fiel, ciente do design e ciente da implementação.\n\n---\n\n## 9. REQUISITO DE ANÁLISE PROFUNDA DE IMAGEM\n\nAntes de implementar qualquer coisa, analise profundamente a(s) imagem(ns) gerada(s). Não apenas as olhe rapidamente. Trate-as como uma especificação de design.\n\nInspecione e extraia cuidadosamente:\n- texto exato visível onde legível (título hero, subtítulo, texto do CTA, títulos das seções)\n- caráter tipográfico, relações de escala de tipo, clima da fonte, contagem de linhas, quebra de linha, lógica de alinhamento\n- espaçamento da seção, espaçamento interno, preenchimento e calhas\n- dimensões e ritmo do card, lógica de raio de borda, uso de traço / divisor\n- formas de botão, hierarquia de botões, preenchimento de botões, estilo implícito de hover\n- paleta de cores, cores de destaque, tratamento de fundo, tratamento de imagem, tratamento de ícone\n- sombras / lógica de profundidade, lógica de grade, estrutura de layout, ordenação de seções, densidade de seções, ritmo visual\n- motivos repetidos que definem a linguagem de design\n\nSeu objetivo é entender exatamente por que o site gerado parece forte. Somente após esta análise profunda você deve implementar o frontend.\n\nPara o vocabulário de design no qual você está extraindo (o que conta como bom contraste de tipo, paleta contida, profundidade honesta), veja stacks-design-taste.\n\n---\n\n## 10. FLUXO DE TRABALHO DE IMAGEM PRIMEIRO\n\nPadrão para um fluxo de trabalho de imagem primeiro para tarefas de design de site.\n\nOrdem de execução preferida:\n1. inferir a contagem de seções\n2. gerar imagens de referência de seção primeiro\n3. gerar imagens extras de detalhe/extração onde necessário\n4. se necessário, regenerar seções não claras como imagens independentes frescas\n5. inspecionar profundamente todas as imagens geradas\n6. extrair texto, tipografia, espaçamento, cores, layout, botões e lógica de componente\n7. implementar o site em Stacks para corresponder ao design gerado o mais próximo razoavelmente possível\n8. apenas inventar detalhes ausentes quando as imagens deixarem algo ambíguo\n\nPara tarefas de frontend visualmente importantes, não comece projetando livremente em código. Comece criando as referências visuais primeiro sempre que a geração de imagem estiver disponível.\n\nAs imagens são a fonte primária de direção de arte. O código é a camada de implementação.\n\n---\n\n## 11. QUANDO ACIONAR A GERAÇÃO DE IMAGEM PRIMEIRO\n\nSe a geração de imagem estiver disponível, prefira fortemente gerar referências de imagem primeiro quando a solicitação for principalmente sobre qualidade visual de frontend.\n\nAcione o fluxo de trabalho de imagem primeiro quando o usuário pedir por uma bela seção hero, uma landing page premium, um site criativo, um redesign, um site mais moderno, uma interface mais estética, uma página de marketing polida, um site de portfólio, um site de startup onde o gosto visual importa muito, um conceito de site com várias seções, ou qualquer coisa descrita principalmente em termos visuais.\n\nCódigo direto primeiro é mais aceitável apenas quando a tarefa é principalmente técnica, o usuário quer uma correção de bug, o usuário já fornece um sistema de design preciso, ou a tarefa é principalmente estrutural em vez de visual.\n\n---\n\n## 12. O ALVO DE IMPLEMENTAÇÃO STACKS\n\nEste é o núcleo redirecionado do skill. Após a análise, você implementa em Stacks, não React/Next. Toda construção abaixo é verificada contra o stack Stacks. Não invente APIs.\n\n### 12.A Templating: stx (não JSX)\n\n- Uma página/componente é um arquivo .stx com blocos opcionais <script>, <template> (ou marcação simples) e <style>.\n- Páginas/visualizações vivem em resources/views/*.stx, componentes em resources/components/*.stx, layouts em resources/layouts/*.stx.\n- Tipos de script: <script server> (apenas SSR, removido do cliente, seguro para DB/segredos/dados), <script client> (apenas navegador), <script> (roda no servidor e envia para o cliente). Não há 'use client' ou 'use server' - é implícito pelo atributo.\n - <script server> é como getServerSideProps ou loader mas mais limpo.\n - <script client> é como useEffect para coisas do navegador como IntersectionObserver.\n- Dados podem fluir por slots, $slots, $props, ou passando props para componentes filhos via atributos.\n- Links: <a href="..."> ou <Link href="...">, funciona como esperado.\n- Imagens: use <img> com caminhos públicos.\n- Icons: use <iconify-icon icon="..."> (ou x-icon). Pilha suportada: Iconify (não Font Awesome ou Heroicons diretamente a menos que disponível via Iconify).\n- Head: use <x-head> em layouts ou <svelte:head>. Título via <x-head><title>...</title></x-head>.\n- Para páginas que precisam de carregamento de dados assíncrono: use <script server> e exporte um load ou dados de componente como Promise.\n- Para efeitos colaterais no navegador: use <script client> com hooks/métodos de ciclo de vida (onMount, etc.).\n\n### 12.B Estilização: Crosswind (não Tailwind)\n\n- Crosswind é Tailwind v3 com um pacote de presets Stacks. Todas as classes utilitárias do Tailwind funcionam, mais algumas extras do Stacks.\n- Sempre realize o design (tipografia, espaçamento, paleta) da imagem para classes Crosswind. Não use classes CSS arbitrárias, a menos que a imagem mostre claramente um estilo único que classes utilitárias não podem atingir.\n- Classes de layout: flex, grid, gap-*, items-*, justify-*, p-*, m-*, w-*, max-w-*, h-*, aspect-*.\n- Classes de tipografia: text-* (tamanho), font-* (peso, família), leading-* (altura da linha), tracking-* (espaçamento entre letras), text-{color}.\n- Classes de cor: bg-*, text-*, border-*, shadow-*; use dark: prefixado para modo escuro.\n- Classes responsivas: sm:, md:, lg:, xl:, 2xl:.\n- Classes de estado: hover:, focus:, active:, group-hover:.\n- Para designs personalizados além das classes utilitárias, use <style> com seletor de classe (scoped por padrão).\n- Para animações, use classes transition-*, duration-*, ease-*, animate-* ou @keyframes em <style>.\n- Cuidado com composição de classe para componentes: Crosswind encoraja classes utilitárias diretamente na marcação, similar ao Tailwind. Para componentes reutilizáveis com estado variante, considere usar props ou slots.\n\n### 12.C Componentes reutilizáveis: Composables + Partial stx\n\n- Para lógica compartilhada entre componentes, use composables (funções JavaScript importáveis de @stacksjs/composables ou suas próprias).\n- Exemplo: import { useCounter } from '@stacksjs/composables', então desestruture count e increment.\n- Para blocos de marcação reutilizáveis, crie componentes parciais .stx e importe-os." }

stacksjs/stacks

O que é stacks?

Perguntar na sua IA favorita

Documentação