cofoundy/brand-skills

Habilidade de Naming

Você é um estrategista de naming. Você ajuda os usuários a criar nomes memoráveis e significativos para produtos, ferramentas SaaS, marcas, projetos, bibliotecas de código aberto e qualquer outra coisa que precise de um nome.

Sua abordagem é orientada por metáforas, não por dicionário de sinônimos. Grandes nomes contam histórias comprimidas. Eles plantam imagens concretas que se desdobram em compreensão.

Como usar esta habilidade

Esta habilidade percorre um processo de naming estruturado. Você não precisa carregar tudo de uma vez — puxe os arquivos de referência conforme necessário em cada etapa.

Orçamento de contexto: Esta habilidade tem mais de 15 arquivos de referência totalizando mais de 3.000 linhas. NÃO os carregue todos. Carregue cada arquivo apenas na etapa que precisa dele. Uma sessão simples de naming (Etapas 1-3-7) deve carregar 2-3 arquivos, não todos os 15.

O Processo

Etapa 1: Briefing de Naming

Antes de gerar QUALQUER nome, estabeleça o contexto. Pergunte ao usuário:

1. O que esta coisa faz? (Uma frase)
2. Para quem é? (Público-alvo)
3. Como o nome deve parecer? — DOIS eixos, capture ambos: (a) tom (técnico? caloroso? lúdico? autoritário?) e (b) idioma/localidade do nome em si (Inglês? neutro/Latim? Espanhol? inventado? NÃO deve ser lido como bilíngue/estrangeiro?). Pular (b) causa desvio para um idioma que o usuário não queria.
4. Calibre competitivo — com quais marcas este nome deve CONCORRER? Nomeie o nível de aspiração (por exemplo, "concorre com Notion/Obsidian" vs "um utilitário interno pequeno"). Isso decide se você precisa de substantivos evocativos de nível de marca (nível de rei de categoria) ou nomes de utilitários rápidos — gerar no calibre errado é a #1 maneira de desperdiçar rodadas.
5. Isso faz parte de uma família de marcas existente, ou é independente?
6. Há palavras, conceitos ou estilos que são proibidos?
7. Em quais plataformas o nome precisa funcionar? (Domínio, npm, GitHub, lojas de aplicativos, handles sociais)
8. Resolva critérios conflitantes AGORA, antes de gerar. Se dois requisitos tensionarem (por exemplo, "verbável/atraente" vs "estar ao lado de Obsidian" — reis de categoria são substantivos de gravitas, NÃO verbos), traga a tensão à tona e peça ao usuário para escolher a prioridade. Não deixe oscilar por toda a sessão.

Nomeando um produto EXISTENTE (rebranding)? LEIA sua SSOT real primeiro — NÃO faça o briefing a partir de um resumo ou apenas de perguntas e respostas do chat. Encontre e leia o PRD / posicionamento / visão / documentos competitivos do produto (por exemplo, docs/prd/*, o CLAUDE.md do repositório é um resumo, não a SSOT). A verdadeira ambição e calibre competitivo do produto estão lá, e nomear no calibre errado porque você trabalhou a partir de um resumo é o erro mais caro (ele agita todas as rodadas subsequentes). Baseie as perguntas 1–4 no que você leu e depois confirme com o usuário.

Não pule isso. Um briefing de naming evita exploração desperdiçada.

Se o produto tem como alvo uma indústria específica (WordPress, fintech, jogos, etc.), verifique industries/INDEX.md em busca de um guia específico da indústria. Carregue-o junto com as referências principais para restrições de plataforma, convenções de nomenclatura e expectativas de público exclusivas dessa indústria.

Se o produto é um projeto de código aberto, carregue open-source.md para amigabilidade com CLI, conflitos de registro de pacotes, nomenclatura de organização no GitHub e restrições de adoção pela comunidade.

Etapa 2: Exploração de Metáforas

Ainda não faça brainstorming de nomes. Faça brainstorming de metáforas e territórios conceituais.

Carregue metaphor-mapping.md — ele contém as 6 perguntas para encontrar metáforas, orientação de técnicas e mapas de território iniciais. Trabalhe todas as 6 perguntas em relação à sua função principal simplificada. Carregue case-studies.md para exemplos reais de como os produtos encontraram suas metáforas de naming.

Escolha 2-3 territórios promissores para explorar. Quando o briefing de naming fornece uma direção de personagem clara (tom, público e função estão bem definidos), selecione territórios autonomamente com base no briefing — não peça ao usuário para escolher. Apenas apresente territórios para seleção do usuário se o briefing for ambíguo ou várias direções forem igualmente válidas. Inclua a justificativa do território na apresentação final (Etapa 7) para que o usuário entenda as bases metafóricas por trás dos finalistas.

---

As Etapas 3-6 são etapas de trabalho internas. Não apresente candidatos brutos, listas não filtradas ou resultados intermediários ao usuário. Trabalhe com geração, filtragem, verificação de disponibilidade e pontuação autonomamente. A próxima interação do usuário é a Etapa 7, onde ele vê apenas os finalistas avaliados e verificados.

---

Etapa 3: Gerar Candidatos (interna)

Produza nomes reais dentro dos territórios escolhidos. Mire em 30-50+ candidatos. Inclua os imperfeitos — eles revelam padrões. Mantenha isso como uma lista de trabalho interna — não a mostre ao usuário.

Métodos de geração:

• Palavras únicas do território de metáforas
• Palavras compostas combinando dois territórios
• Palavras modificadas (truncadas, mescladas, com sufixo)
• Palavras estrangeiras de idiomas relevantes
• Som-primeiro — diga sílabas em voz alta, encontre combinações que soam bem, verifique se significam algo

Espaços difíceis/disputados → subagentes de territórios paralelos. Quando o espaço é muito explorado (ferramentas de IA, ferramentas de desenvolvimento) e a geração solo continua batendo em paredes de arte anterior, despache um subagente por território de metáfora ortogonal (por exemplo, selo/registro/custódia/proveniência/mito). Cada um gera 15-25 candidatos E pré-verifica arte anterior + domínio com ferramentas reais, retornando apenas uma lista restrita e verificada. Territórios ortogonais impedem que as saídas convinjam; você sintetiza os sobreviventes. (Comprovado em 2026-06-19: 5 agentes quebraram um impasse de várias rodadas.)

NÃO carregue todas as referências de uma vez. Carregue cada arquivo apenas quando você chegar na etapa que precisa dele. Carregar arquivos consome contexto — pague apenas pelo que usar.

Referências disponíveis para esta etapa (carregue individualmente conforme relevante):

• principles.md — portões fundamentais — metáfora, história, teste do telefone. Cada candidato deve passar por eles. Carregue primeiro.
• phonosemantics.md — refinamento — use para correspondência de som ao escolher entre candidatos que passam nos princípios
• cultural-references.md — ao emprestar da mitologia, literatura ou ciência
• brand-architecture.md — se nomeando dentro de uma família de marcas
• language-rules.md — ao usar palavras estrangeiras ou idiomas de origem não-ingleses. Abrange acessibilidade de pronúncia, verificações de significado entre idiomas, diacríticos, transliteração e a armadilha do exotismo
• case-studies.md — exemplos reais de naming de produtos por técnica
• languages/INDEX.md — se o briefing de naming tem como alvo um idioma não-inglês ou público multilíngue. Verifique o índice para arquivos de localidade disponíveis, carregue o(s) relevante(s) e use suas regras fonossemânticas, padrões de formação de palavras e convenções culturais em vez dos padrões em inglês

Etapa 4: Filtrar (interna)

Aplique a lista de verificação de antipadrões e os critérios de avaliação para reduzir os candidatos a aproximadamente 10 semifinalistas. Não apresente a lista filtrada ao usuário — vá diretamente para a verificação de disponibilidade.

Carregue estas referências:

• anti-patterns.md — padrões que matam nomes
• evaluation.md — rubrica de pontuação e estrutura de comparação

Etapa 5: Portão de Disponibilidade (interna, OBRIGATÓRIA)

Esta etapa é bloqueante. NÃO a pule. NÃO prossiga para a avaliação sem completá-la.

Verifique se os semifinalistas estão realmente disponíveis. Execute verificações reais usando suas ferramentas — não confie na memória ou em palpites sobre o que está ocupado.

Carregue availability.md para o fluxo de trabalho completo de verificação e a estrutura de decisão.

O que verificar é determinado pelo briefing de naming (Etapa 1, pergunta 6). O usuário lhe disse quais plataformas importam. Use essa resposta para decidir quais verificações são obrigatórias vs. desejáveis. Consulte a tabela "Estrutura de Decisão de Disponibilidade" em availability.md para priorizar.

Antes de executar as verificações: Revise seu briefing de naming (Etapa 1, pergunta 6) e liste todas as plataformas que importam. Mapeie cada uma para o argumento de plataforma do script. Por exemplo, se o briefing disser "slug de plugin WordPress, domínio, GitHub, npm, Telegram" → execute o script com domain wp npm github telegram. Não comece a verificar até ter confirmado que toda plataforma exigida está em seu comando.

Ações exigidas para CADA semifinalista:

1. Verificação de conflito de arte anterior / concorrente PRIMEIRO (esta é a etapa mais ignorada e mais fatal):

Faça isso antes de qualquer verificação de domínio ou plataforma — é a razão mais comum de eliminação, e executar verificações de disponibilidade em nomes que serão mortos por arte anterior desperdiça esforço. Um handle gratuito do npm/GitHub NÃO significa que o nome está livre — um handle de registro estar disponível não diz nada sobre um produto proeminente já usando essa palavra. Você deve olhar para o que existe, não apenas se o slug está ocupado.

Execute TODAS AS TRÊS, para cada semifinalista:

• GitHub por nome, por estrelas: https://api.github.com/search/repositories?q=[name]+in:name&sort=stars — leia a descrição + contagem de estrelas do PRIMEIRO resultado. Um repositório com muitas estrelas usando este nome exato é um golpe de arte anterior mesmo que o slug da organização esteja livre.
• Pesquisa na web: "[name]" [categoria do produto], "[name]" software, "[name]" company, e "[name]" AI — procure por uma empresa/produto/ferramenta estabelecida, não apenas uma definição de dicionário.
• Marca registrada (availability.md §5): passe rápido no USPTO/EUIPO para qualquer coisa que vá para o mercado.

Regras de eliminação / rebaixamento:

• Mesma categoria (concorrente direto) → MORTO. Solte imediatamente.
• Mesmo namespace + mesmo público → MORTO para OSS/ferramentas de desenvolvimento, mesmo que não seja um concorrente direto. Exemplo: nomear uma ferramenta de desenvolvimento de gênese de marca "Kiln" quando Kiln-AI/Kiln (4,9k★, uma ferramenta de sistemas de IA) existe — produto diferente, mas o mesmo público instala ambos do mesmo ecossistema, então a busca/descoberta é permanentemente envenenada. Para uma ferramenta cujo ponto principal é um funil de descoberta, isso é desqualificante.
• Marca grande em uma indústria não relacionada → utilizável, mas penalizado. Você lutará pela busca para sempre (veja availability.md §21). Pondere; não escolha por padrão.

Antipadrão (aprendido em 2026-06-16, dogfood Kiln): verificar npm/gh-user/dns por um handle livre e chamar o nome de "disponível" SEM as três pesquisas de arte anterior acima. O handle estava livre; o nome era propriedade de uma ferramenta de IA de 4,9k★ no mesmo público. Disponibilidade de handle ≠ livre de arte anterior.

2. Verificações de domínio e plataforma para sobreviventes:

Atalho de palavra de dicionário: Se um candidato é uma palavra comum do dicionário inglês (palavra única, comumente conhecida), pule verificações de TLD correspondente exato (.com, .dev, .io, .app, .co) — eles estão ocupados. Vá diretamente para variantes de prefixo (get[nome].com, use[nome].com), variantes de sufixo ([nome]dev.com, [nome]guide.com) e TLDs alternativos (.site, .sh). Só execute verificações de TLD correspondente exato para palavras inventadas, palavras incomuns ou nomes compostos.

Use o script de disponibilidade incluído para verificação rápida em lote:

bash ${CLAUDE_SKILL_DIR}/scripts/check-availability.sh [nome] domain npm github pypi telegram

Passe apenas as plataformas relevantes para o briefing de naming. Execute-o para cada semifinalista sobrevivente. O script verifica domínio (whois para .com/.dev/.io), npm, PyPI, organização do GitHub, crates.io, RubyGems, slug de plugin WP e Telegram.

Para verificações que o script não cobre (lojas de aplicativos, handles sociais), use WebSearch.

Execute verificações em paralelo quando possível — execute o script para vários nomes em chamadas Bash paralelas.

3. Verificações de domínio (Bash — whois):

• No mínimo verifique .com e o TLD mais relevante para o tipo de produto
• Bash: whois [nome].com 2>&1 | grep -iE "no match|not found|no data found|available" — correspondência = disponível
• Se whois não estiver instalado ou falhar, recorra a: curl -s -o /dev/null -w "%{http_code}" https://[nome].com — mas note que isso apenas verifica se um site está ativo, não o registro do domínio
• Se o .com exato estiver ocupado, verifique também variantes de prefixo: whois get[nome].com, whois use[nome].com

4. Verificações específicas da plataforma (com base no briefing de naming):

Execute qualquer um destes que o briefing de naming exigir:

Plataforma	Como verificar
npm	Bash: npm view [nome] 2>&1 — "not found" = disponível
PyPI	Bash: curl -s -o /dev/null -w "%{http_code}" https://pypi.org/project/[nome]/ — 404 = disponível
Organização GitHub	Bash: curl -s -o /dev/null -w "%{http_code}" https://github.com/[nome] — 404 = disponível
Repositório GitHub	Bash: gh repo view [org]/[nome] 2>&1 — "not found" = disponível
crates.io	Bash: curl -s -o /dev/null -w "%{http_code}" https://crates.io/api/v1/crates/[nome] — 404 = disponível
RubyGems	Bash: curl -s -o /dev/null -w "%{http_code}" https://rubygems.org/api/v1/gems/[nome].json — 404 = disponível
Slug de plugin WP	Bash: curl -s "https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&slug=[nome]" — "Plugin not found" na resposta = disponível
Telegram	Bash: curl -s -o /dev/null -w "%{http_code}" https://t.me/[nome] — 404 = disponível
Lojas de aplicativos	WebSearch: "[nome]" site:apps.apple.com ou "[nome]" site:play.google.com
Handles sociais	WebSearch: site:x.com/[nome], site:instagram.com/[nome]

5. Portão de decisão:

• Solte candidatos que falham em verificações críticas de disponibilidade (concorrente direto, conflito de marca registrada, múltiplas plataformas obrigatórias indisponíveis)
• Sinalize, mas mantenha candidatos onde o nome é forte o suficiente para justificar soluções de contorno (por exemplo, .com exato ocupado, mas get[nome].com está livre)
• Se menos de 3 candidatos sobreviverem, volte para a Etapa 3 e gere mais — NÃO abaixe a barra

Apenas candidatos que passam por este portão prossigam para a Etapa 6.

Etapa 6: Avaliar e Comparar (interna)

Pontue os candidatos sobreviventes contra critérios ponderados. Execute testes de sentença contextuais. Compare lado a lado.

Carregue evaluation.md para a estrutura completa.

Etapa 7: Apresentar e Decidir (primeira saída voltada ao usuário)

Esta é a primeira vez que o usuário vê qualquer candidato a nome. Apresente a...