umairmsm/wp-kickoff

Estágio 1: Kickoff

Objetivo: uma página de verdade sobre o negócio e um projeto vazio com todos os arquivos que o método espera. Nada é projetado ou construído ainda.

Passos

1. Já existe um site ativo? Se sim, trate-o como um negócio em funcionamento, não como um domínio estacionado. Primeiro faça o inventário (references/discovery-brief.md, "Site existente"):
   • cada URL (a partir de seus sitemaps), formulário, etapa de pagamento, postagem de blog e detalhe de contato;
   • seus dados do Search Console, se o proprietário puder compartilhá-los;
   • o que gera dinheiro hoje. A reconstrução deve manter tudo funcionando. Rastreie educadamente: leia primeiro os Termos de Uso (robots.txt não é permissão) e aguarde 2 segundos ou mais entre as solicitações.
2. Briefing de descoberta. Faça as perguntas em references/discovery-brief.md e escreva as respostas em docs/BRIEF.md. Marque cada fato com sua fonte (proprietário, documento, rastreio). Se você não souber um fato, escreva PENDING-<quem>. Nunca adivinhe.
3. Stack. Comece pelo padrão em references/stack.md. Altere uma camada apenas por um motivo que você possa declarar e registre-o em DECISIONS.md.
4. Crie o projeto com o scaffold do kit (duas pastas acima deste skill):

   bash <kit>/bin/wp-site-new --name "Acme Tours" --slug acme-tours --prefix acme \
        --domain example.com --dir ~/sites/acme-tours --git
   

   • slug: minúsculas e hífens. Ele nomeia o projeto DDEV, as pastas e os text domains.
   • prefix: 2 a 12 letras minúsculas ou dígitos. Toda função, opção, tipo de post, meta key, hook e nonce começa com <prefix>_.
5. Preencha AGENTS.md:
   • o que é o site;
   • quem aprova design e cópia do cliente;
   • as decisões registradas;
   • regras rígidas específicas para este negócio, como alegações regulamentadas, licenças a mostrar ou palavras que o proprietário nunca quer.
6. Repositório privado remoto, configurado no dia 1. O proprietário cria um repositório privado e faz push. Assim que o site local existir (estágio 3), execute scripts/backup.sh e mantenha uma cópia em outra máquina.
7. Inventário de credenciais (docs/reference/CREDENTIALS_INVENTORY.md):
   • liste cada conta (registrador, DNS, hospedagem, SMTP, analytics, Search Console, pagamentos, CDN);
   • escreva onde cada segredo reside;
   • apenas nomes, nunca valores.
8. Marque o gate do Kickoff em SITE_STATUS.md com evidência: a data de aprovação do briefing, o SHA do primeiro commit, o nome do remoto.

Gate

• docs/BRIEF.md aprovado pelo proprietário (data)
• Decisões registradas e regras rígidas do negócio em AGENTS.md
• Projeto criado e commitado; repositório privado remoto existe
• Inventário de credenciais iniciado (apenas nomes)
• Substituindo um site ativo: inventário de URL e funcionalidades salvo em docs/data/legacy/ (ou "n/a")

Armadilhas que encontramos

• Tratar a "migração" como uma simples mudança de DNS enquanto o site antigo estava recebendo reservas pagas naquele dia.
• As contagens de avaliações de um site antigo ("1.118 avaliações") acabaram sendo inventadas. Não as carregue.
• Proxear o domínio através do Cloudflare enquanto o host antigo tinha limite de taxa por IP. O host via apenas os IPs do Cloudflare, então visitantes reais recebiam erros 429. Verifique os limites da origem antes de ativar o proxy.
• Confiar em anotações de outro agente que diziam "resolvido". A correção estava sem push, não testada e nunca implantada. Verifique a coisa real.
• Alguém colou uma chave de API em um chat de agente. Gire qualquer chave que um agente tenha visto.