taufiquebuilds/launchday

O que launchday faz?

A maioria dos bons projetos open-source são lançados mal: um README que explica ao invés de mostrar, sem demonstração, sem linha de instalação, um nome que colide com outras três ferramentas e um Show HN postado às 3 AM (horário dos EUA). Este skill corrige tudo isso em uma passada e entrega ao usuário um plano de lançamento que ele pode executar em uma noite.

Você faz a preparação. O usuário faz qualquer coisa pública: criar o repositório público, fazer push de tags, enviar a prévia social e postar. Publicar é difícil de desfazer e fala em nome do usuário, então você prepara até o ponto de copiar e colar, depois para e entrega.

Como executar

Trabalhe através das fases em ordem. Cada fase termina com algo concreto no repositório. Informe ao usuário em qual fase você está, para que ele possa acompanhar.

Os scripts ficam em scripts/ ao lado deste arquivo. Eles usam apenas a biblioteca padrão do Python (mais ffmpeg para a prévia). Execute-os com o caminho para a pasta deste skill, por exemplo, python3 <caminho-do-skill>/scripts/audit.py ..

Fase	Saída	Script ou referência
1. Entender	Resumo de um parágrafo que você confirma com o usuário	nenhum
2. Verificar nome	Decisão de manter ou renomear	scripts/name_check.py
3. Auditar	Pontuação e lista de correções	scripts/audit.py
4. README	README reescrito como página de destino	references/readme.md
5. Demonstração	GIF ou captura de tela mais prévia social	references/demo.md, scripts/social_preview.sh
6. Release	CI e fluxo de trabalho de release	references/release.md
7. Kit de lançamento	LAUNCH.md com posts e agenda	references/launch-posts.md, scripts/launch_time.py
8. Entrega	Comandos exatos para o usuário executar	nenhum

Se o usuário pediu apenas uma parte ("só conserte meu README", "escreva meu Show HN"), faça essa fase. Ainda assim, execute a auditoria primeiro se for barato, pois ela frequentemente revela o verdadeiro bloqueio.

Fase 1: Entender o projeto

Leia o README, o manifesto do pacote (package.json, Cargo.toml, pyproject.toml, go.mod) e o ponto de entrada. Execute o projeto se puder fazê-lo com segurança. Depois, escreva um parágrafo cobrindo três coisas:

• O que faz, em uma frase que um não especialista entende.
• Quem tem a dor. Seja específico: "mantenedores com 10+ repositórios", não "desenvolvedores".
• O momento de prova: a primeira coisa que um novo usuário vê e que o faz dizer "ah, legal". O README e a demonstração são construídos em torno disso.

Confirme com o usuário em uma mensagem curta. Um resumo errado aqui envenena tudo a jusante. Também pergunte o que você não conseguir encontrar: qual conta do GitHub hospedará o repositório e o fuso horário do usuário para a agenda de lançamento.

Fase 2: Verificar nome

python3 <caminho-do-skill>/scripts/name_check.py <nome> [alternativa ...]

O script verifica crates.io, npm, PyPI, Homebrew e GitHub. Um nome compartilhado divide os resultados de pesquisa, então pessoas que ouvem sobre o projeto não conseguem encontrá-lo, e um nome registrado em um registry bloqueia a publicação. Se o veredito for EVITAR ou LOTADO, proponha 3 a 4 alternativas e verifique-as na mesma execução. Bons nomes dizem o que a ferramenta faz, ou evocam isso, e são fáceis de soletrar após ouvi-los uma vez.

Renomear é uma decisão do usuário. Se ele renomear, mude cada ocorrência: manifesto, nome do binário, README, links, CI, caminhos de configuração e strings de user-agent. Use um script que percorra os arquivos em vez de usar separação de palavras do shell, que quebra em caminhos com espaços. Depois, reconstrua e execute os testes.

Fase 3: Auditar

python3 <caminho-do-skill>/scripts/audit.py <caminho-do-repositorio>

Você recebe uma pontuação de 0 a 100 e uma lista de correções, ordenadas por peso. Ela cobre o gancho do README, um elemento visual e uma linha de instalação próximos ao topo, a licença e arquivos da comunidade, CI e fluxos de trabalho de release, segredos vazados, e-mails de commit pessoais e, se gh estiver logado, a descrição do GitHub, tópicos, prévia social e releases.

Duas descobertas vêm antes de qualquer outra coisa, porque não podem ser desfeitas após um push público:

• Um segredo em um arquivo rastreado. Remova-o e informe ao usuário para rotacioná-lo. Ele já está no histórico do git.
• Um e-mail de commit pessoal (Gmail e similares). Cada commit público o mostra. Defina o e-mail do repositório como o endereço noreply do GitHub do usuário, [email protected]. Obtenha o ID de gh api user --jq .id.

Reexecute a auditoria ao final da fase 6. A pontuação subindo é a barra de progresso do usuário, então mostre-a.

Fase 4: README como página de destino

Leia references/readme.md e reescreva o README nessa estrutura. A ideia central: um visitante decide em cerca de 10 segundos, usando apenas a primeira tela. Então a primeira tela deve conter a dor, a prova (o GIF) e o comando de instalação. A explicação vem depois.

Cada afirmação no README deve ser verdadeira para o código como ele está hoje. Verifique cada recurso, bandeira e número contra o código-fonte ou uma execução real antes de escrever. Exageros são detectados no primeiro comentário do HN e custam mais confiança do que a afirmação ganha. Coloque trabalhos futuros em uma seção de Roadmap, claramente marcada.

Fase 5: Demonstração e prévia social

Leia references/demo.md. Escolha o formato de acordo com o tipo de projeto:

• CLI ou TUI: grave um GIF com VHS, usando um arquivo tape commitado em docs/demo.tape, para que qualquer um possa regravá-lo.
• Aplicação web: capturas de tela, ou uma gravação de tela curta.
• Biblioteca: um trecho de código antes/depois com saída real.

Depois, faça a prévia social:

sh <caminho-do-skill>/scripts/social_preview.sh docs/demo.gif docs/social-preview.png

Observe os quadros você mesmo antes de prosseguir. Extraia 2 ou 3 quadros com ffmpeg e visualize-os. As gravações falham silenciosamente: cores desaparecem porque NO_COLOR está definido no ambiente, um token é digitado na tela, o texto é ilegível na linha selecionada, ou o quadro capturado mostra um spinner de carregamento. Corrija e regrave. Olhar os quadros é barato; um GIF quebrado no topo do README não é.

Fase 6: Release e CI

Leia references/release.md para o ecossistema do projeto. O objetivo são caminhos de instalação para pessoas que não têm a toolchain: binários pré-compilados, ou um pacote publicado, a partir de um push de tag. Faça qualquer etapa de publicação pular limpa quando seu segredo não estiver definido, para que o primeiro release do usuário não mostre uma falha vermelha. Execute os próprios comandos de lint, formatação e teste do projeto localmente, e faça-os passar, pois o CI os executa no primeiro push.

Fase 7: Kit de lançamento

python3 <caminho-do-skill>/scripts/launch_time.py --tz <fuso horário IANA do usuário>

Isso escolhe a próxima terça, quarta ou quinta-feira às 8:30 AM (horário dos EUA Oriental) e converte a agenda para o fuso horário do usuário, seguindo as regras de horário de verão. Pula semanas de eleições nos EUA, semana de Ação de Graças, Natal a Ano Novo e 4 de Julho, e diz o porquê. Não faça a conversão de cabeça: as mudanças de horário de verão dos EUA/Europa deslocam o offset em uma hora duas vezes por ano. Se você puder pesquisar na web, também verifique a semana escolhida para qualquer coisa que dominaria as notícias de tecnologia (um grande evento da Apple, Google ou OpenAI, uma grande paralisação) e mude um dia se necessário.

Depois, leia references/launch-posts.md e escreva LAUNCH.md na pasta pai do repositório, ou em docs/ se o usuário preferir. Ele contém a agenda, uma lista de verificação pré-lançamento, o título e primeiro comentário do Show HN, 2 ou 3 posts no Reddit para os subreddits mais adequados, um tópico no X e o plano do dia seguinte.

A história nos posts deve ser real. Use o que é realmente verdadeiro sobre por que o projeto existe ou o que foi aprendido ao construí-lo. Se você não souber, pergunte ao usuário por uma frase de sua motivação real. Nunca invente uma história de fundo, contagens de usuários ou um benchmark.

Fase 8: Entrega

Termine com uma mensagem curta que contenha:

1. A pontuação da auditoria, antes e depois.
2. O que está agora no repositório, como uma lista de arquivos.
3. Os comandos exatos que o usuário executa para publicar, em ordem: criar o repositório público, fazer push, esperar o CI, marcar o release.
4. As etapas manuais que nenhuma API consegue fazer: enviar a prévia social (Settings, depois Social preview), fixar o repositório e corrigir detalhes do perfil.
5. O dia e hora do lançamento no fuso horário do usuário, e onde está LAUNCH.md.

Depois que o usuário disser que publicou, ofereça-se para verificar. Verifique se o repositório é público, o CI está verde, o release tem assets, o comando de instalação funciona a partir de um diretório limpo e a prévia social está configurada (gh api graphql -f query='{repository(owner:"o",name:"r"){usesCustomOpenGraphImage}}').

O que faz um lançamento funcionar

Estas são as ideias que as fases servem. Use-as para tomar decisões que as etapas não cobrem.

• Mostre antes de contar. Um GIF da coisa funcionando vale mais que três parágrafos sobre ela.
• Uma linha para testar. Cada etapa extra antes do primeiro "ah, legal" perde pessoas.
• Seja honesto e específico. "Classifica seus repositórios por estrelas ganhas esta semana" vence "Plataforma de análise com IA". A audiência do HN pune hype e recompensa uma história real.
• Momento e respostas importam tanto quanto o post. Poste quando a audiência estiver acordada e responda a todos os comentários nas primeiras 3 horas.
• Nunca peça upvotes ou estrelas. No HN faz o post ser sinalizado. Em outros lugares, parece spam.