Direção de arte para landing page

Diretor de Design

Um modelo deixado sozinho projeta a média de cada página que já viu, para um cliente que imaginou. Esta skill parte da pesquisa sobre o negócio real e seus clientes reais, transforma-a em uma história, ataca esse plano antes de construir, insere o gosto do designer nos momentos mais importantes e verifica o resultado com um navegador e um segundo par de olhos. Bom design aqui significa três coisas ao mesmo tempo: serve ao negócio, responde ao cliente e parece certo.

<skill> abaixo significa a pasta desta skill. Execute os scripts a partir da raiz do projeto; os arquivos de trabalho vão para .design/ lá. Os scripts precisam de Node 18+ e Playwright com Chromium (CHROME_PATH se necessário).

Princípios

1. Pesquisa primeiro, sempre. Cada execução pesquisa o negócio, os concorrentes e os clientes (research/method.md) sem ser solicitada, e toda decisão pode ser rastreada até uma descoberta. O relatório de pesquisa é devolvido ao usuário junto com o trabalho.
2. Negócio e cliente antes da aparência. A estratégia nomeia a ação que gera retorno e as perguntas do cliente; a história as responde em ordem (strategy/method.md). A aparência serve à história, não o contrário.
3. Critique antes de construir, sempre. Um agente separado ataca o plano com quatro vozes (roast/method.md); cada ponto é aceito e implementado, ou rejeitado com um motivo. A crítica pode mudar a direção; esse é o seu trabalho.
4. Decida antes de construir. Cada decisão é escrita em .design/ antes do código. O código usa apenas o que a especificação diz.
5. O designer escolhe; você propõe. Portões curtos: o briefing, a estratégia, a direção e o resultado final.
6. O gosto da equipe é dado. team/taste.md e o arquivo da marca superam suas próprias preferências. Os elementos da marca vêm de brand/method.md (um kit de uma execução brand, ou um kit curto na etapa de direção).
7. Nunca julgue a aparência pelo código, e nunca julgue sozinho. Julgue capturas de tela. No esforço padrão e acima, um júri de agentes especialistas separados julga (rubric/jury.md), e os votos dos designers são combinados com os deles; empates de gosto vão para os humanos, vetos de acessibilidade não podem ser anulados. O código também é julgado, mas em seus próprios termos e por seu próprio chefe: a revisão de engenharia (rubric/council.md).
8. Respeite o que existe. Em um projeto existente, altere tokens e componentes, não substituições de página.
9. Nunca invente provas. Nenhum depoimento, logotipo de cliente, estatística, prêmio ou imprensa inventados.
10. Leia apenas o que a etapa precisa. Cada etapa nomeia seus arquivos; não carregue toda a skill.
11. Cinco cabeças aprovam cada trabalho. Produto (visão, resultado, métrica, escopo), Negócio (percepção de mercado), Design (composição, sistema, acessibilidade), Criativo (ideia, marca, assinatura, movimento) e Engenharia (o código) cada um é responsável por sua parte (rubric/council.md). Quatro são interpretados dentro da crítica e do júri que já são executados; a Engenharia revisa o código após o portão. A especificação termina com a aprovação ## Council.

Iniciar cada execução

1. Modo. Escolha um a partir da solicitação e do projeto. Se não tiver certeza, declare sua leitura em uma linha e continue.

   Modo	Quando	Arquivo
   create	Uma nova página	modes/create.md
   site	Várias páginas, ou um fluxo em etapas (cadastro, checkout, integração)	modes/site.md
   section	Uma seção ou componente em um design existente	modes/section.md
   review	"Revisar", "auditar", "por que isso parece estranho" (sem alterações de código)	modes/improve.md
   restyle	Melhorar a aparência, manter o layout	modes/improve.md
   redesign	Reconstruir a estrutura, manter conteúdo, pilha e comportamento	modes/improve.md
   brand	Um kit de marca (elementos, cores, tipografia, forma, movimento, um logotipo provisório) mostrado em um quadro, antes ou sem uma página	modes/brand.md

   Adicione modes/app-screen.md por cima quando a tela for trabalhada em (painel, admin, configurações, caixa de entrada, editor) em vez de leitura. Um painel de administração, dashboard ou back-office sem sistema de design ou biblioteca de componentes acordado é construído com shadcn/ui (React + Tailwind) até o usuário aprovar outro; diga a eles o motivo (rules/stack.md). Na etapa de direção, pergunte se o usuário deseja ver de 2 a 3 variações de estilo (barra lateral, modal, …) para que o painel não pareça genérico; eles escolhem na página de adminoptions.mjs, ou confiam na IA (admin/method.md). Uma tela que lista registros (três linhas ou mais) segue as regras de tabela de dados de admin/table.md: números alinhados à direita, uma barra de ação em massa na seleção, identificador fixo e ações em tabelas largas, e o restante, cada um com seu motivo e quando não.

2. Esforço. quick para uma seção ou uma pequena correção, standard para uma página (padrão), thorough para uma apresentação, uma página principal ou um site inteiro (melhor de 3 em cada seção chave). Orçamento de subagente por execução (meça e registre o número real no relatório de entrega):

   Esforço	Subagentes	Orçamento
   quick	um crítico (as cinco cabeças interpretadas pela sessão principal, não independente)	cerca de 70k
   standard	examinador de razões + 2 jurados combinados + 1 verificador por rodada posterior + 1 revisor de engenharia	cerca de 320-430k
   thorough	4 examinadores de cabeças + examinador de razões + júri herói (2) + painel de aparência completo (5-6, agrupados por cabeça) + 1 revisor de engenharia + 2 por rodada posterior	cerca de 850k-1,15M

   Partes medidas: examinador de razões 93k (página de execução 2, 67 elementos, 9 chamadas); jurados 59-94k cada. Ainda não medidos (estimativas): o revisor de engenharia cerca de 70-110k (53k de custo fixo mais os arquivos de origem de uma página); cada examinador de cabeça adicional em thorough cerca de 60-80k (custo fixo mais briefing, pesquisa e estratégia). Meça ambos na próxima execução real e substitua esses números. A sessão principal vem por cima. A execução 2 (standard, antes desses limites) gastou cerca de 630k apenas em subagentes; a maior parte foi em dois painéis de cinco jurados.

3. Estilo de portão. guided (padrão): três cartas de direção. quick: uma recomendação com um motivo de uma linha e "continuar?", para pessoas que não querem escolher, ou que disseram "terserah" / "você decide". autopilot: sem humano no loop (execuções em lote, avaliações); cada escolha é registrada com seu motivo. Verifique designers/<name>.md para uma preferência salva.

4. Guie, depois deixe o usuário escolher cedo. Antes da pesquisa, ajude o usuário a dizer o que deseja em uma mensagem curta (rules/brief-interview.md): quem e para quê, o produto por trás (visão, resultado, a única métrica, o que está dentro e fora do escopo: a pergunta do Chefe de Produto, rubric/council.md), 1 a 3 sites que eles gostam e 1 que não gostam (transformados em controles por dials.mjs), três palavras de sentimento, o que existe (fotos, UI do produto, ativos da marca: rules/brief-interview.md → Materiais), o que está descartado. Sem fotos, pergunte quais imagens substitutas o usuário deseja e ofereça os cinco caminhos (fotos de banco de imagens que eles escolhem ou você pesquisa, um rascunho gratuito gerado por IA, placeholders projetados com desenho, ou sem imagens: rules/illustration.md). Diga imediatamente qual caminho é usado e como será. No portão de direção, o usuário escolhe entre esboços de primeira tela de cada direção; essa escolha define a composição, então o esforço padrão não precisa de herói melhor de 3. Variantes de página completa (2 a 3 páginas inteiras, --variants) são para esforço thorough ou quando o usuário pede; o usuário escolhe em compare.mjs (--choose user), o júri apenas em autopilot.

5. Execute node <skill>/scripts/progress.mjs init --mode <mode> --effort <effort> --gates <style> [--variants N --choose user|jury].

6. Leia team/taste.md, o arquivo da marca (brands/<client>.md, ou .design/brand.md no projeto) se existir, designers/<name>.md se o usuário for nomeado, e rules/precedence.md.

7. Abra o arquivo de modo e siga-o passo a passo.

Regras para cada etapa

• Antes de uma etapa, execute progress.mjs check <step>; depois dela, execute progress.mjs done <step>. Quando o script recusar, faça o que a mensagem diz. Nunca edite .design/progress.json manualmente.
• Portões. Mostre o portão (formatos abaixo), depois pare e aguarde a resposta do usuário. Execute progress.mjs approve <gate> --note "<as palavras do usuário>" apenas após uma resposta explícita. Nunca aprove pelo usuário, a menos que a execução tenha sido iniciada com --gates autopilot.
• Conteúdo de amostra pode preencher lacunas deixadas pelo briefing (nomes de pratos, preços de quartos); marque-o como [SAMPLE] em .design/copy.md e liste-o no relatório final. Prova (citações, logotipos, números sobre clientes) nunca é amostrada: deixe a seção de fora ou peça o real.
• Referências seguem rules/copyright.md: pelo menos três fontes, um papel cada, nenhum ativo copiado.
• Quando duas regras entrarem em conflito, rules/precedence.md decide. Nomeie o conflito no relatório.
• Em uma sessão longa, releia .design/spec.md antes de construir cada seção.
• Não relate uma verificação que você não executou. Se o navegador ou um subagente estiver indisponível, diga isso.
• Explique cada decisão chave com seu motivo de UX, sua compensação (quando estaria errada) e uma fonte onde houver uma, em palavras neutras ("a maioria das orientações recomenda … porque …; uma exceção é …"), para que o usuário possa defender o design ao lado de outra IA (rules/rationale.md).

Formatos de portão

Portão do briefing (approve brief). Um cartão de no máximo 10 linhas: o que é, para quem é e sua situação, a única ação, a parte do produto (visão, resultado, a única métrica, o que está dentro e fora do escopo: rubric/council.md), o conteúdo real e os ativos que existem (a seção ## Materials do briefing: fotos, UI do produto, ativos da marca e o plano para o que está faltando), restrições da marca, o que evitar e sua leitura em uma linha de qualquer coisa pouco clara. Faça no máximo 5 perguntas, apenas para fatos que bloqueiam o trabalho.

Portão da estratégia (approve strategy, após a crítica). É aqui que o usuário vê a pesquisa pela primeira vez. Mostre, nesta ordem:

1. o resumo da pesquisa: as 3 a 5 descobertas que mudam o design, os clichês da categoria, as principais perguntas do cliente em suas próprias palavras e quantas fontes foram lidas;
2. a estratégia: a ação que gera retorno, o cliente e seu nível de consciência, a casa de mensagem (promessa, três pilares, objeções) e a história como uma lista de batidas;
3. o que a crítica mudou e qualquer ponto de alta gravidade que você rejeitou, com o motivo;
4. as perguntas em aberto para o cliente e a prova que está faltando.

Portão de direção (approve direction).

• Guided: três cartas de draw.mjs, cada uma com a frase da ideia, composição em uma linha, abordagem de tipografia e cor e por que se encaixa neste assunto. Diga qual você recomenda e por quê. O usuário pode escolher uma ou misturar ("tipografia de A, layout de B"); escreva a mistura na especificação. Abaixo dos cartões, os controles visuais (rules/visual-dials.md), cada um definido para sua recomendação com um motivo e o que precisa do cliente: energia da cor, expressão tipográfica, imagens, movimento, preço. Nomeie referências da equipe como predefinições ("warna seperti Swehl"). Traduza palavras vagas em valores de controle e mostre a tradução de volta. A resposta vai para .design/targets.json.
• Quick: apenas o cartão recomendado, mais "os outros dois estão em .design/directions/ se você quiser". Continue com "ok", "lanjut" ou similar.

Se o usuário responder "terserah" ou aceitar a recomendação três vezes seguidas, ofereça-se para mudá-lo para portões rápidos e, se concordar, escreva isso em designers/<name>.md.

Portão final (approve final). O pacote do arquivo de modo, escrito em .design/deliver.md: o que foi construído, capturas de tela em desktop e celular, o que é conteúdo de amostra (cópia [SAMPLE], UI de amostra marcada data-sample, cada imagem substituta: fotografias encontradas com créditos, rascunhos gerados por IA, placeholders e desenhos projetados, com a lista de tomadas), problemas em aberto (com o veredito da revisão de engenharia, orçamento medido e descobertas abertas), "Alasan desain": pelo menos três decisões chave, cada uma com seu motivo de UX, compensação e fonte, e a cabeça por trás dela onde isso ajuda (rules/rationale.md, rubric/council.md), e "Supaya mais bagus": no máximo cinco coisas concretas que o usuário pode fazer ou decidir para elevar o resultado (imagens a fornecer, com a lista de tomadas; provas reais a coletar; um controle que vale a pena girar; um nível de esforço mais alto; o movimento de assinatura, quando a especificação de movimento não encontrou nenhuma mensagem para mover), cada uma com o que mudaria.

Quando o usuário muda de ideia

Cada etapa depende das anteriores: briefing → pesquisa → estratégia → crítica → direção → esqueleto → especificação → cópia → construção → razões → portão → aparência → entrega.

1. Encontre a decisão mais antiga que mudou ("voltar para a direção B" → direction; "o público agora são estudantes" → brief; "o problema real é o preço, não o medo" → strategy).
2. Diga o impacto em uma linha antes de fazer qualquer coisa: o que será refeito e o que permanece.
3. Execute progress.mjs back <step> --reason "<o que mudou>", depois refaça a partir dessa etapa.
4. Mantenha o trabalho anterior: direções tratadas permanecem em .design/directions/, capturas de tela antigas em .design/snapshots/. Nunca aplique uma nova decisão sobre uma construção feita para a antiga.

Uma pequena mudança (uma cor, um tamanho, uma linha de cópia) não é uma volta: altere o token ou a cópia, registre-o com progress.mjs log, inspecione novamente.

Quando o feedback é vago

"Kurang wow", "algo está errado", "não é premium o suficiente": não adivinhe e repinte a página.

1. Escreva 2 a 3 hipóteses concretas ("o herói não tem um ponto focal único", "os tamanhos de tipo estão muito próximos", "as fotos são genéricas").
2. Faça pequenas variantes apenas da área afetada (um corte de herói A/B/C) e mostre-as lado a lado.
3. O usuário escolhe; escreva o que eles escolheram na especificação como uma regra para o resto da página.

Aprendizado

No final, peça uma frase de feedback. Transforme-a, e qualquer coisa que o usuário corrigiu durante a execução, em mudanças propostas para team/taste.md (ou designers/<name>.md para gosto pessoal), mostradas como um diff com a fonte (projeto, data, quem). Aplique apenas o que

…

[truncated for translation]