CommunityImagemgithub.com

ralvarez-ai/landing-page-designer

Projete propostas de landing page para um produto como HTML autossuficiente, fundamentado em seu código, capturas reais e marca — um dispositivo memorável por página, um filme hero coreografado, uma barra de acessibilidade e verificação (axe x8, verificação de parser, teste de fumaça). Use quando solicitado a desenhar, propor ou melhorar a página pública/landing de um produto, comparar direções, ou "torná-la mais atraente / mais dinâmica". Não é para portar um design escolhido para o aplicativo (trabalho posterior); o trabalho upstream de conceito é o website-concept-architect.

O que é landing-page-designer?

Esta skill especializada orienta um agente de IA no design de landing pages para produtos de software, focando em propostas em rodadas, verificações rigorosas de qualidade e aderência estrita aos detalhes reais do produto. O objetivo é criar landing pages impressionantes e autênticas que comuniquem claramente a proposta de valor de um produto em segundos, usando dados reais, capturas de tela em execução e um dispositivo memorável por página. A skill é destinada ao trabalho de conceito upstream (não à implementação final) e é tipicamente usada em conjunto com skills complementares como 'website-concept-architect' e 'ui-ux-architect'. O processo começa com uma pesquisa profunda no código do produto para construir uma tabela de fatos verificáveis, incluindo nomes de ferramentas, códigos de erro e constantes, e então avança por rodadas de direções criativas. Cada rodada produz múltiplas direções de design, e a página final deve passar por uma barra de verificação rigorosa: oito execuções do axe-core para acessibilidade, uma verificação de parser HTML para evitar texto engolido e um teste de fumaça que verifica todos os controles interativos. A skill impõe regras rigorosas de motion, tipografia e identidade visual, garantindo que cada página use apenas as fontes e tokens de marca reais do produto e apresente um 'filme hero' coreografado que conta uma história verdadeira sobre o produto. O resultado final é um HTML autossuficiente e inlinado, com menos de 200 KB, que funciona nos temas claro e escuro e é totalmente acessível.

Funciona com✓Claude Code~Codex CLI✓Cursor
npx skills add https://github.com/ralvarez-ai/ralvaskills/tree/HEAD/skills/frontend/landing-page-designer

Installed? Explore more Imagem skills: steipete/songsee, affaan-m/frontend-design, mattpocock/improve-codebase-architecture · View all 6 →

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

Designer de landing page (rodadas de proposta)

O método para propor landing pages em rodadas, em que cada decisão se baseia e as verificações que uma página deve passar antes que alguém a veja. Upstream desta skill: website-concept-architect (o que é o site). Downstream: ui-ux-architect (portar para o aplicativo).

0. O trabalho, e o que não é

  • Desenhe, não refatore. A saída são propostas em <proposals-dir>/<data>/<produto>/. Não toque no código de entrega do aplicativo; não faça commit ou push a menos que o proprietário autorize.
  • Uma página está finalizada apenas quando passa pela barra de verificação (seção 8) e suas afirmações são rastreadas (seção 2).
  • Trabalhe em rodadas. Cada rodada produz novas direções, mantém as antigas como uma biblioteca de ideias e termina com uma recomendação e o motivo pelo qual ela supera as outras.

1. A barra (o que "impressionante" significa)

Julgue cada captura de tela contra esta lista.

  1. Cinco segundos. Um estranho pode dizer o que o produto faz, para quem é e por que difere, apenas pelo primeiro viewport.
  2. Um dispositivo. A página é lembrada por uma coisa específica, exclusiva do produto, não por uma cor. Bons dispositivos são literais: o cursor no logotipo usado como um cursor real; um número real que se move; uma troca agente-servidor mostrada como as duas chamadas que realmente são; uma notificação push chegando em um telefone no momento em que o texto diz.
  3. Concreto, não abstrato. Cada afirmação aponta para algo no produto ou em seu código.
  4. Pixels reais vencem ilustração. Uma captura de tela recortada do produto em execução supera qualquer desenho dele.
  5. Diga a troca. O texto afirma o que faz, para quem é e a única coisa que aceita em troca (auto-hospedado: suas atualizações e backups; um serviço compartilhado: mais uma dependência; apenas entrega: a política permanece no aplicativo).
  6. Proibido: fotografia de banco de imagens, gradientes roxos, grids bento de cartões cinza com um ícone cada, "Confiado por 10.000 equipes", depoimentos inventados, métricas falsas.

2. Pesquise primeiro: fatos com fontes

Antes de desenhar, construa uma tabela de fatos por produto: afirmação, valor, arquivo de origem. Leia o código, não o marketing.

  • Onde procurar: README.md, AGENTS.md/CLAUDE.md, documentos de design e ADRs, CHANGELOG.md, validadores e códigos de erro, registros de ferramentas/endpoints, mapeamentos wire/proto, constantes de worker/retry, o componente da marca, o arquivo de tokens de tema, a landing view existente.
  • Fatos que valem a pena encontrar: nomes exatos de ferramentas e quantas são destrutivas; códigos e mensagens de erro; constantes (tentativas de retry, base e limite de backoff, intervalo de polling, limites de confiança); campos de requisição (conte-os no mapeamento wire, não no doc); rotas; comandos reais de quick-start.
  • Verifique contagens e nomes no código. A documentação desvia: um "seis campos" documentado pode ser oito no código; um README pode apontar para um diretório que não existe mais; um exemplo hero pode usar uma unidade que o servidor rejeita.
  • Sinalize, nunca corrija silenciosamente. Inconsistências (marca desatualizada nas capturas, capturas que discordam, doc vs código) vão para NOTES.md e, se relevante, na página.
  • Rotule dados ilustrativos na página (entradas de exemplo, ids, horários, texto de notificação). O leitor deve distinguir o real do exemplo sem as notas.

3. Marca e família

  • Cada produto mantém sua própria marca e destaque. Copie o caminho real da marca de seu componente e os tokens reais (fundos, texto, muted, accent, accent-text, cores semânticas) do arquivo de tokens, ambos os temas.
  • Fontes: apenas as do próprio produto, copiadas como woff2 em fonts/. Inspecione-as antes de escolher uma voz tipográfica:
    python -c "from fontTools.ttLib import TTFont; t=TTFont('inter-latin.woff2'); print([(a.axisTag,a.minValue,a.maxValue) for a in t['fvar'].axes])"
    
    Uma fonte variável declarada em toda sua faixa de peso pode dar numerais finos para um produto e peso pesado cinético para outro, sem novas fontes.
  • Um kit de marca organizacional é família, não template. Use-o para pequenos detalhes compartilhados (uma marca de chamada, um crédito de rodapé em currentColor), nunca como a identidade do produto.
  • Camada de família: um arquivo compartilhado com tokens de espaçamento, tipo e movimento, cabeçalho, botões, chamada, trilho de seção, controle de filme, botão de cópia, rodapé e o kit de movimento. Produtos sobrescrevem cor, voz tipográfica e composição. Várias páginas devem ser lidas como irmãs com personalidades distintas.

4. Direção de arte por produto

Decida uma personalidade antes do layout; deixe-a guiar tipo, grid, peso de cor e ritmo. Exemplos que funcionaram:

PersonalidadeVoz tipográficaComposição e ritmo
Calmo, editorial (finanças)Uma figura hero enorme em peso leve com numerais tabulares; mono para linhas de razãoEspaço branco generoso, grid assimétrico, uma faixa noturna, uma captura real em sangria total
Alto, cinético (fitness)Peso preto, tracking negativo apertado, numerais grandesFaixa de destaque em sangria total com um ticker, regras duras, seções altas e silenciosas alternando
Técnico, exato (identidade)Chamadas mono, grandes numerais monoGrid de linha fina, figuras numeradas com legendas, diagramas anotados
Sucinto, rítmico (notificações)Palavras de status mono gigantesUma régua de tempo como motivo recorrente, espaço negativo, uma seção fixa
  • Evite o esqueleto padrão (sobrancelha, h1, lede, dois botões, lista de confiança, brilho) a menos que o mude com intenção. Uma rodada onde cada produto compartilha um esqueleto falhou.
  • Ritme uma página longa como um filme: uma seção silenciosa, uma alta, um momento em sangria total, uma faixa escura, uma mudança de fundo. Espaçamento uniforme parece costurado.
  • Projete 390 px intencionalmente: recortes próprios de capturas para telefones, diagramas que refluxam (empilhar, barra lateral) em vez de encolher, conteúdo do filme acima da dobra.
  • Verificação de folha de contato: renderize os primeiros viewports de todos os produtos lado a lado (ambos os temas, 1440 e 390). Procure por uniformidade e quebras de família.

5. O filme hero

Uma sequência coreografada por produto que conta o produto em 4 a 8 segundos e se estabiliza em um estado final estático.

  • O estado final é o HTML simples. JS desligado e movimento reduzido mostram-no imediatamente; o filme apenas anima em direção a ele (um reset() para o estado inicial, passos [ms, fn(instantâneo)], limpeza end()).
  • Toca uma vez na visualização, nunca em loop; pausa quando a aba está oculta; tem um controle visível de Pausa/Repetir (WCAG 2.2.2). A digitação dentro de um filme é conduzida pela linha do tempo do filme, então Pausa a congela também.
  • Conte a verdade em sequência. Use o comportamento real como enredo: requisição → rejeitada com o erro real → reenviada → salva; três cópias → uma; enfileirado → poll → enviado. Não invente um destaque que os dados não suportam.
  • Movimentos de elemento compartilhado (um total voando para a figura hero, tabelas voando para um banco de dados) fazem uma cena em vez de uma lista de revelações.
  • Texto acessível: a camada digitada visível é aria-hidden; a frase completa está em um span .sr uma vez.

6. Regras de movimento

  • Comporta: conteúdo visível por padrão; um script de cabeçalho adiciona html.anim apenas quando prefers-reduced-motion permite; toda regra de ocultar ou animar fica sob .anim.
  • Opacidade apenas em revelações de uma vez (IntersectionObserver, termina em 1). Efeitos vinculados à rolagem (animation-timeline: view()/scroll(), limpeza adesiva) animam transform, clip-path ou stroke apenas: um estado de texto semitransparente falha contraste no axe.
  • Permitido: animações CSS guiadas por rolagem com fallback estático, Transições de Visualização para a troca de tema (limpeza circular do alternador), molas CSS linear(), animação de peso variável, contagens que escrevem o texto final quando o movimento está desligado.
  • Conteúdo de movimento automático (tickers, reprodução automática) precisa de um controle de pausa e pausa ao passar o mouse/foco.
  • Meça a mudança de layout; reserve espaço para contadores e texto digitado.

7. Capturas

  • Apenas do produto em execução, nunca uma maquete dele. Semeie dados de demonstração deterministicamente para que os números concordem entre as capturas (ou diga na página que não concordam).
  • Recorte com intenção (um painel por ponto), ambos os temas, 2x, mais recortes separados para telefone.
  • Recorte marca desatualizada e sinalize-a. Diga nas legendas quando a linguagem da UI difere da da página.
  • Implemente como um par de <img> claro/escuro com height:auto, um alt significativo e marcadores posicionados no espaço de coordenadas da captura (meça-os; marcadores derivam).
  • Se a construção estiver bloqueada (pacotes privados, token ausente), diga isso, rotule os dados desenhados como ilustrativos e liste exatamente o desbloqueio.

8. Requisitos rígidos e barra de verificação

Cada página:

  • HTML autossuficiente, CSS e SVG inline, sem CDN, apenas as fontes do produto; abaixo de 200 KB excluindo capturas.
  • Claro e escuro via data-theme com um alternador (preferência armazenada, padrão do sistema).
  • Marcos, um h1, ordem de títulos sem lacunas, link de pular, focável-visível, alvos de 44 px, fallback forçado-cores.

Verificações (todas devem passar antes de mostrar a alguém):

  1. verify.js: axe-core (wcag2a/2aa/21aa/22aa + melhor prática) em 390x844 e 1440x800 × claro/escuro × movimento/reduzido = 8 execuções, zero violações. No modo de movimento, role a página inteira primeiro para que as revelações disparem. Também: sem rolagem horizontal; imagens bloqueadas ainda legíveis; JS desligado ainda legível.
  2. Verificação de parser HTML para texto engolido: um <token> bruto ou <no-reply@...> no texto se torna uma tag e o axe não dirá. Escape como &lt;.
  3. Teste de fumaça por página: clique em cada controle em 1440 e 390, falhe no pageerror, execute axe novamente nos estados finais interativos (diálogos abertos, após aplicar).
  4. Capturas de tela: filme estabilizado e movimento reduzido, ambos os temas, ambas as larguras. Olhe para elas e itere pelo menos duas vezes como um diretor de arte severo.
  5. Diga o que não está coberto: leitor de tela, Safari/Firefox, dispositivos reais, teste de usuário da afirmação de cinco segundos.

9. Armadilhas (cada uma custou tempo uma vez)

  • Especificidade CSS: uma regra de troca de tema para imagens deve vencer regras de componentes (img.sl, não .crop img).
  • Medir um elemento oculto dá 0 (lente, zoom): mostre, depois meça.
  • Etapas inativas esmaecidas por opacidade falham contraste: enfatize com borda/fundo.
  • role="list" precisa de filhos listitem; títulos de seção não devem pular de h1 para h3.
  • Fundos gradientes/mesh precisam de sangria total, uma máscara e body{overflow-x:clip}.
  • Um <code> inquebrável em uma célula de grid causa rolagem horizontal em 390; um pre rolável falha scrollable-region-focusable (dê a ele tabindex="0", role="region" e um rótulo único, ou use pre-wrap).
  • Nomes de classe genéricos colidem entre CSS compartilhado e de produto (.tl, .copy): namespace classes de família.
  • cqw resolve contra um contêiner ancestral, nunca o próprio elemento.
  • Um aria-label que difere do texto visível quebra rótulo-em-nome; coloque contexto extra em um span .sr.
  • Uma string de template Python sem seu prefixo f vaza {label} no nome acessível: grep na saída.
  • Imagens com loading="lazy" estão ausentes nas capturas de tela de página inteira; não é um defeito.
  • Páginas montadas por extração não atualizam quando uma fonte muda até que o montador seja executado novamente.

10. Processo

  1. Leia o brief/repasso, o código e documentos do produto; construa a tabela de fatos e sinalizações (seção 2).
  2. Inventário da marca: caminho da marca, tokens, fontes (eixos), capturas existentes e seus problemas.
  3. Rodada de direções: 3 direções pequenas e diferentes por produto, cada uma construída em torno de um dispositivo. Mantenha-as como a biblioteca de ideias.
  4. Feedback do proprietário → combine as melhores ideias em uma página longa (trilho de seção, FAQ, quick-start real com botão de cópia, um bloco ponderado "o que você aceita").
  5. Eleve o teto: uma camada de família compartilhada primeiro, depois uma página com direção de arte por produto com um filme hero. Produtos independentes podem ser construídos em paralelo (um agente por produto, camada de família somente leitura, sugestões relatadas e aplicadas uma vez, depois todas as páginas reconstruídas e reverificadas).
  6. Revise juntos: folhas de contato, correções de consistência na camada de família, reverificação completa.
  7. Entregue: por produto, um NOTES.md (conceito, real vs exemplo, sinalizações, tabela de verificação); um HANDOFF.md para a próxima sessão (objetivo, decisões, sinalizações, fraquezas, próximas ideias); prévias independentes apenas para visualização com fontes e capturas inline; um resumo curto com uma recomendação por produto e por que ela vence.

11. Arquivos e ferramentas

<proposals-dir>/<data>/
  HANDOFF.md                  brief para a próxima sessão
  <produto>/direction-N.html  páginas; NOTES.md; fonts/; shots/
  _tools/verify.js            axe x8, estouro, imagens bloqueadas, JS desligado
  _tools/family.py            shell compartilhado, tokens, kit de movimento (filme, contagem, tipo, onView)
  _tools/build_<produto>.py   um gerador por produto
  _tools/settled.js           captura de tela após o filme estabilizar
  _tools/standalone.py        cópia apenas para visualização com fontes e capturas inline
  _tools/smoke_<produto>.js   testes de fumaça de interação

Geradores carregam caminhos codificados da sessão que os criou; corrija sys.path e caminhos de saída antes de executar. verify.js espera [email protected] instalado em um verify/node_modules irmão.

12. Lista de verificação antes de mostrar uma página

  • O primeiro viewport passa no teste de cinco segundos; o único dispositivo está visível ali.
  • Cada número e nome rastreado até um arquivo; dados de exemplo rotulados na página; sinalizações em NOTES.md.
  • Troca declarada claramente e com peso visual.
  • Filme hero estabiliza; o estado final é o HTML padrão; Pausa/Repetir funciona; movimento reduzido e JS desligado são legíveis.
  • Efeitos vinculados à rolagem usam apenas transform/clip/stroke; revelações são de uma vez.
  • 390 px projetado (recortes próprios, diagramas refluídos), não apenas empilhado.
  • verify.js TODO LIMPO (8 execuções), verificação de parser limpa, teste de fumaça limpo, abaixo de 200 KB.
  • Olhou para as capturas de tela, ambos os temas, ambas as larguras, e mudou algo por causa do que viu.

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

Habilidades Relacionadas