Communitygithub.com

gergobalogh/launch-check

Verifique se qualquer nova página pública ou aplicativo web está pronto para lançamento, cobrindo seu gancho, corpo, aparência e funcionamento em telefone, tablet, laptop e desktop grande, seu próximo passo, compartilhamento e medição.

O que é launch-check?

Esta skill é uma checklist abrangente e rigorosa para garantir que qualquer página web ou aplicativo web público esteja pronto para lançamento, minimizando o risco de problemas que afetariam a maioria dos visitantes no dia do lançamento. Ela cobre desde a primeira impressão (o 'gancho') até a medição de eventos de análise, passando pela legibilidade, responsividade, usabilidade e indexação em buscadores. A skill suporta qualquer tipo de página (artigo, ferramenta, hub, etc.) e pode ser usada durante o desenvolvimento (em um build local) ou, em uma versão separada, em páginas já públicas. O processo envolve nomear a página e seus passos, servir um build local com análises bloqueadas, percorrer todas as 29 verificações em quatro tamanhos de tela (telefone, tablet, laptop, desktop grande) e documentar os resultados. Cada verificação é classificada como bloqueadora (deve ser corrigida antes do lançamento) ou recomendação (deve ser relatada, mas não impede o lançamento). A skill é projetada para ser usada com um navegador headless (Playwright) e garante que nenhuma visita seja contada como tráfego real, pois bloqueia o host de análise antes de carregar a página. Ao final, um resumo contagem de verificações é fornecido.

Funciona com~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/gergobalogh/claude-skills/tree/HEAD/skills/launch-check

Perguntar na sua IA favorita

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

Documentação

Verificação de lançamento: esta página está pronta?

O dia do lançamento traz a maior parte do público de uma página, e uma correção no dia 2 perde a maior parte dele. Acerte antes de a postagem ir ao ar.

Esta lista de verificação se aplica a qualquer página. Mantenha-a livre de nomes de página e dados de página: escreva uma nova lição aqui como uma regra geral e mantenha a página e seus números nas anotações do próprio projeto.

Como executar

  1. Nomeie a página. Seu tipo (artigo ou história, ferramenta ou jogo, hub), sua função em uma frase e seus passos: chegou → utilizável → primeiro uso → ação principal → funcionou → próximo passo. Colapse os passos que não se aplicam. Não adicione entradas, números ou ações apenas para satisfazer uma verificação.
  2. Sirva um build local (dist/ ou o servidor de desenvolvimento) com análises bloqueadas. Nunca abra a página ao vivo.
  3. Percorra cada verificação nas quatro telas abaixo. Marque cada uma como aprovada, reprovada, não verificado ou N/A com um motivo. Para uma verificação que exija julgamento, escreva o que você viu (a frase que recontou, a captura de tela que olhou), não apenas "aprovado".
  4. Bloqueador: corrija ou obtenha uma isenção explícita do usuário e verifique se não foi verificado. Recomendação: relate; não impede o lançamento.
  5. Escreva o resultado nas anotações do projeto ou no quadro de tarefas, contando todas as 29 verificações: Verificação de lançamento: 25 aprovados, 1 reprovado, 1 não verificado, 2 N/A; bloqueador: U1 reprovado; recomendação: S3 não verificado; N/A: U2 (sem entrada), U3 (sem esperas).

Telas: telefone 390×844, tablet 820×1180, laptop 1366×768, desktop grande 1920×1080. Verifique cada uma; um layout amplo move as coisas tanto quanto um estreito. Confirme falhas de layout em uma captura de tela, já que a fonte sozinha não pode mostrá-las.

Navegador: um Chromium headless (Playwright) é suficiente, já que um build local não precisa de login. Antes de carregar a página, bloqueie seu host de análise nessa guia (page.route(/seu-host-de-analise/, r => r.abort())), para que as verificações nunca contem como visitas.

Por tipo de página:

  • Artigo ou história: continuar a rolar é o próximo passo, então U2 é N/A e U3 se nada espera.
  • Ferramenta ou jogo: T2 cobre qualquer texto que a página tenha; o primeiro uso deve dar um resultado real.
  • Hub: a recompensa é encontrar a coisa certa, então T1 significa que cada link faz o que promete.

Gancho

  • H1 · Bloqueador. A partir da primeira tela sozinha, em todos os tamanhos, você pode dizer em uma frase o que o visitante obtém. A recompensa, não o tópico. Escreva essa frase. Se você não conseguir escrevê-la, ou ela apenas nomear o assunto, isso falha.
  • H2 · Recomendação. A primeira tela dá a um estranho um motivo para continuar: uma descoberta, número, resultado ou pergunta específicos, e verdadeiros. Ainda deve funcionar para alguém que chega de uma postagem sem contexto.
  • H3 · Recomendação. A pré-visualização do link faz a mesma promessa. og:image, título e descrição dizem a recompensa. Verifique as tags e a imagem no build.
  • H4 · Bloqueador. A primeira ação é visível sem rolagem em todos os tamanhos e claramente parece uma, com contraste suficiente. Em uma história de rolagem, a primeira ação é a rolagem: uma sugestão de rolagem visível passa.

Corpo

  • T1 · Bloqueador. O corpo entrega o que o gancho prometeu, e cedo. A recompensa não espera até o final. Se a página for longa, uma versão curta vem primeiro e o resto é escolha do visitante.
  • T2 · Bloqueador. É bem legível do início ao fim. Leia tudo em ordem, como um estranho faria. Cada parte segue a anterior e acrescenta algo, nada é preenchimento, e você pode recontar tudo em uma frase.
  • T3 · Recomendação. Um ponto ou número principal por tela. O resto vai em uma tabela ou atrás de "mais". N/A se a página não apresentar números ou descobertas.
  • T4 · Bloqueador. Cada número e afirmação tem uma fonte, e tudo que está oculto funciona. Abra cada gaveta, guia e acordeão e siga cada link de fonte. Uma seção fechada ainda faz parte da página.
  • T5 · Recomendação. O texto passa pelas regras de estilo do autor e uma verificação de 'escrito por IA', sem texto de placeholder, rascunho ou depuração restante. O texto da página é publicado sob o nome do usuário, então relate problemas e pergunte; não reformule sozinho.

Telas

  • S1 · Bloqueador. Parece correto em todas as quatro telas, em cada passo. Tire uma captura de tela após cada passo e olhe para cada uma: nada cortado, sobreposto ou sem estilo (elementos feitos por script podem perder CSS com escopo), sem rolagem lateral. Após uma pesquisa ou seleção que mova um mapa, verifique se o resultado cai na parte não coberta por um painel, em todos os tamanhos.
  • S2 · Bloqueador. Todo texto é legível em seu tamanho renderizado. Meça, não julgue a olho nu, e mire em 12 px ou mais. Para gráficos SVG: tamanho da fonte × largura renderizada ÷ largura da viewBox.
  • S3 · Recomendação. Utilizável em menos de 2 s em um telefone. Utilizável significa o ponto mais cedo em que a primeira ação funciona. Cronometre a partir de quando o carregamento começa, com cache frio e um perfil de CPU e rede de telefone declarado. Uma execução em desktop sem limitação não pode mostrar uma aprovação em telefone.
  • S4 · Bloqueador. Carregamento lento e com falha ambos parecem corretos. Teste redes lentas (CDP Network.emulateNetworkConditions, 9 / 1.6 / 0.75 / 0.4 Mbps) e um carregamento com falha. Sirva com compressão como a CDN para tempos; um servidor local não compactado superestima cada espera. Capture a tela a cada 0,5 s em cada transição de carregamento a partir de uma inicialização a frio e olhe os quadros. Mantenha a última boa imagem com um rótulo de carregamento; um fallback é apenas para falha. Os rótulos devem estar corretos durante o carregamento e após a falha. N/A se nada carregar tarde.

Uso

  • U1 · Bloqueador. Após cada passo, o próximo controle está na tela em todos os tamanhos, onde a página deixa o visitante. Teste cada maneira de entrar em um passo separadamente (exemplo, digitado, tocado). Verifique cada destino de rolagem, cabeçalho fixo e a dobra.
  • U2 · Recomendação. Há uma maneira de um toque (um exemplo ou predefinição) ao lado de qualquer entrada de formulário livre, e o evento diz qual foi usado. N/A sem entrada de formulário livre.
  • U3 · Bloqueador. Qualquer espera acima de 2 s mostra progresso e termina em um resultado claro ou um erro claro. Conduza uma resposta atrasada e com falha localmente. Um spinner que nunca termina falha. N/A se nenhuma ação espera. Um controle mostrado antes de seu script ter carregado (um formulário para um mapa lento) deve funcionar ou enfileirar: use-o durante o carregamento e após um carregamento com falha. Um envio de formulário não tratado recarrega a página.

Próximo passo

  • N1 · Recomendação. No momento do sucesso, há uma próxima coisa clara: uma página relacionada, tentar outra, jogar novamente. Coloque onde o sucesso acontece, não no rodapé.
  • N2 · Recomendação. Botões de compartilhar que enviam a descoberta: WhatsApp, Facebook, X e copiar link, cada um carregando uma frase escrita com a descoberta, não apenas o título, colocados onde o resultado aparece. A frase é cópia pública, então o usuário a redige: pergunte. Um hub sem uma descoberta ainda precisa de uma frase do usuário. Não invente uma ou marque isso como N/A sozinho. O evento share envia a rede apenas, nunca o texto ou a URL.

Pesquisa

As respostas de IA do Google (AI Overviews, AI Mode) usam páginas do índice de Pesquisa comum: uma página que classifica com um snippet pode ser citada, e nenhum arquivo ou marcação somente de IA é necessário. Dados estruturados devem corresponder ao que a página mostra.

  • F1 · Bloqueador. A página pode ser indexada: um endereço canônico, nenhum noindex perdido, listada no sitemap. Uma página muito fina para classificar (um stub que apenas linka para outro lugar, uma lista vazia) é mantida fora da pesquisa: noindex e fora do sitemap, sem outra versão de idioma apontando para ela.
  • F2 · Recomendação. O título diz o que a página contém, não apenas o nome do site, com o nome no final; a descrição é própria da página e não aparece em nenhuma outra página.
  • F3 · Recomendação. Uma linha visível diz quem fez, quando foi publicado e quão novos são seus dados, com a mesma data de publicação nos dados estruturados. Altere a data de modificação apenas quando o conteúdo realmente mudar. N/A para um hub.
  • F4 · Bloqueador. Cada imagem no HTML tem uma fonte e texto alternativo real, incluindo figuras mostradas apenas sem JavaScript. Uma <img> vazia falha.
  • F5 · Recomendação. Uma página construída sobre dados oferece os dados: um CSV após uma verificação de privacidade (apenas os campos que a página já mostra), uma linha de licença ao lado do download e marcação Dataset. Um vídeo recebe marcação VideoObject com um poster. N/A quando a página não tem nenhum.

Após o lançamento: solicite a indexação da página no Search Console (a conta do usuário, então pergunte) e adicione a pergunta que ela responde à lista de perguntas de resposta de IA do projeto, se ele mantiver uma.

Medição

As verificações assumem um rastreador de eventos amigável à privacidade (Umami, Plausible ou similar) com eventos personalizados.

  • M1 · Bloqueador. Os eventos estão no build que será lançado. Um evento por passo aplicável, um por ação, sucesso é o efeito e não o clique, e um evento *-leave fornece o passo mais distante e o tempo em vista.
  • M2 · Bloqueador. Os eventos disparam através do rastreador real. Uma função de rastreador simulada pode esconder eventos perdidos. Execute o rastreador real no nome de host de produção, com context.route servindo o build local e capturando o endpoint de envio do rastreador para que nada saia da máquina. Acione cada controle, links de salto também: cada evento descreve sua ação, falha não envia sucesso, e um salto sobre o conteúdo não envia evento de leitura. Siga um link de saída rastreado na mesma guia e verifique se o evento *-leave ainda chega: uma solicitação iniciada enquanto a página descarrega pode ser perdida, então tais links abrem em uma nova guia.
  • M3 · Bloqueador. Os eventos estão listados em docs/analytics.md do projeto com a hora de entrada em funcionamento, e uma especificação de funil está em docs/funnels/ (salvá-la na ferramenta de análise precisa da aprovação do usuário).
  • M4 · Bloqueador. Nada que um visitante digitou ou escolheu é enviado para análise: sem hash em visualizações de página (exclua o hash), sem texto de consulta, sem lugares. Apenas rótulos fixos e buckets.
  • M5 · Bloqueador. Os alvos são escritos antes do lançamento (um número por passo que você espera alcançar), para que a revisão após o lançamento tenha algo para comparar.
  • M6 · Bloqueador. Os agentes ficam fora da página ao vivo, porque suas visitas contam como tráfego real. Um script de verificação que pode apontar para a página ao vivo deve bloquear a análise por si só.

Individual skills in this repo

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

Habilidades Relacionadas