template-rebrand

Renomeie um projeto Next.js (e NestJS)

Siga os passos na ordem. Cada passo termina com uma verificação: execute-a, corrija o que ela encontrar, e só então prossiga. CHECK significa este comando, a partir da raiz do projeto:

node ${CLAUDE_SKILL_DIR}/scripts/rebrand-check.mjs check \
  --old "Nome Antigo" --old "Nome antigo em cada outro script" \
  --new "Novo Nome" --new "Novo nome em cada outro script"

Adicione --case quando o nome antigo for uma palavra comum (LOJA), e --allow <caminho> para um arquivo que mantém o nome antigo intencionalmente. Nunca execute uma substituição cega.

0. Brief, mapa e linha de base

1. Escreva o nome antigo em todas as formas que o projeto usa (cada idioma, slug, domínio de e-mail) e o novo nome em cada idioma, a cor da marca, os arquivos de logotipo e o tom. Se a solicitação omitir um deles, escolha um valor sensato, continue e liste a escolha no relatório.
2. Execute node ${CLAUDE_SKILL_DIR}/scripts/rebrand-check.mjs map.
3. Execute o comando de build de cada aplicativo do mapa uma vez, antes de qualquer edição.

Verificação: você tem o mapa, uma contagem de CHECK para reduzir e um resultado para cada build. Um build que já falhou é anotado como não causado pela renomeação.

1. Nomes e logotipo

Arquivos de configuração da marca, o componente de logotipo, o manifesto do aplicativo web e qualquer linha de configuração que um seed escreve (um nome de remetente de e-mail geralmente fica lá). Deixe nomes de pacotes, nomes de variáveis de ambiente, nomes de banco de dados, volumes Docker e prefixos de armazenamento sozinhos, a menos que solicitado: renomeá-los quebra instalações e dados existentes.

Verificação: CHECK mostra 0 ocorrências em "configuração da marca". As ocorrências de infraestrutura que você manteve vão para o relatório.

2. Cores

Tokens da marca nos arquivos de tema que o mapa lista, claro e escuro, mais a cor do tema do navegador no manifesto ou viewport. Nenhuma cor é escrita em um componente.

Verificação: CHECK com --old "#hexantiga" para cada cor antiga da marca mostra 0 ocorrências, e o texto na nova cor mantém um contraste de 4.5:1 em ambos os temas.

3. Arquivos de logotipo e ícones

Substitua o logotipo, marca, favicon, ícones do aplicativo e imagem de compartilhamento que o mapa lista. Mantenha nomes de arquivo e tamanhos, ou atualize cada referência. Abra cada novo arquivo e olhe para ele.

Verificação: CHECK relata 0 caminhos de imagem ausentes de public/, e nenhum nome de arquivo ou pasta com o nome antigo, exceto aqueles que você manteve intencionalmente.

4. Texto em cada idioma

Reescreva, não apenas renomeie: herói, sobre, rodapé, legal, suporte, SEO e qualquer frase que descreva o negócio antigo. As mesmas chaves em cada idioma, cada língua escrita nativamente.

Verificação: CHECK mostra 0 ocorrências em "mensagens", e nenhum arquivo de idioma ou mensagem tem o novo nome em um idioma, mas não em outro.

5. Metadados e SEO

Layouts raiz e de página, generateMetadata, templates de título, campos Open Graph e Twitter, JSON-LD, sitemap, robots, name e short_name do manifesto.

Verificação: CHECK mostra 0 ocorrências em "metadados e SEO".

6. E-mails

Nome do remetente, assuntos, cabeçalho e rodapé, links, em cada idioma que a API envia. O endereço e domínio do remetente vêm de env: liste-os no relatório.

Verificação: CHECK mostra 0 ocorrências em "e-mails".

7. Dados de seed e mock

Seeders, fixtures e catálogos mock: produtos, categorias, linhas de configuração, domínios de e-mail de conta demo, caminhos de imagem. O seed da API e quaisquer dados mock do frontend concordam.

Verificação: CHECK mostra 0 ocorrências em "dados de seed".

8. Build e verificação final

Execute o comando de build de cada aplicativo novamente. Corrija erros até que cada um passe. Não inicie um servidor de desenvolvimento ou produção a menos que solicitado.

Verificação: todo build sai com 0, então CHECK imprime Resultado: PASS.

Relatório

Arquivos alterados por passo, as escolhas feitas para qualquer coisa que o brief omitiu, cada ocorrência permitida e porquê, os resultados dos builds e o que fica para uma pessoa: domínio, DNS, remetente de e-mail, textos legais.