Como colocar o tom de voz da marca dentro de uma skill do Claude

Existe um tipo de texto que passa em qualquer revisão e mesmo assim não serve: está correto, está claro, e não tem NADA da sua marca dentro

Isso quase sempre nasce do jeito mais confortável de descrever voz: "tom leve e profissional"

Só que isso não é instrução, é rótulo… e rótulo cada um preenche do seu jeito

Uma skill é uma pasta com um arquivo SKILL.md dentro, e esse arquivo tem duas partes: o frontmatter YAML entre os marcadores --- e o corpo em Markdown com as instruções

O que muda tudo é o que você escreve nesse corpo: exemplo de texto aprovado, lista do que a marca não usa e regra de estrutura, em vez de três adjetivos bonitos

Bora ver na prática? 🙂

O que você precisa ter antes de escrever a skill

A parte chata vem primeiro, e ela é a que decide o resultado

Junta esse material antes de abrir o editor:

• Textos já aprovados: posts, e-mails, páginas, legendas, qualquer coisa que a marca publicou e você assinaria de novo
• Textos rejeitados: aqueles que voltaram da revisão, porque contraexemplo ensina tanto quanto exemplo
• A lista de palavras e expressões banidas: os clichês que a sua marca não usa nem sob tortura

Se você tem só o primeiro item, a skill vai saber imitar, mas não vai saber recusar

O passo zero que quase todo mundo pula:

A documentação de boas práticas recomenda começar pela avaliação, não pela instrução

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

Ou seja: você roda o Claude nas tarefas representativas SEM a skill, documenta as falhas específicas que apareceram e cria avaliações com cenários que testam exatamente essas lacunas

Só depois disso você escreve instruções mínimas, apenas o suficiente pra fechar as lacunas

É como corrigir prova: você ensina o que a pessoa errou, não o conteúdo inteiro de novo

Voz pessoal ou voz de projeto?

No Claude Code isso é uma decisão de pasta

Se mais de uma pessoa escreve pela marca, a de projeto ganha fácil: entra no repo e todo mundo herda a mesma voz sem combinar nada por mensagem

Passo a passo: montando a skill de voz de marca

1. Criar a pasta e o SKILL.md

Cada skill vive na SUA pasta, com o arquivo dentro:

.claude/
  skills/
    voz-da-marca/
      SKILL.md

Pra versão pessoal, mesma estrutura dentro de ~/.claude/skills/

O erro comum deste passo: salvar um voz-da-marca.md solto na pasta skills/, sem a subpasta própria… o formato é pasta contendo SKILL.md, e é isso que permite pendurar arquivos de apoio depois

2. Escrever o frontmatter (é ele que faz a descoberta)

O SKILL.md exige apenas dois campos: name e description

---
name: voz-da-marca
description: Escreve e revisa textos na voz da marca, aplicando os exemplos aprovados, a lista de termos proibidos e as regras de estrutura. Use quando o pedido for redigir, reescrever ou revisar post de blog, e-mail, página ou legenda da marca.
---

As regras do name: máximo de 64 caracteres, só letras minúsculas, números e hifens, sem tags XML, e as palavras anthropic e claude são reservadas

As regras da description: máximo de 1024 caracteres, não pode ficar vazia e não pode ter tag XML

E aqui mora a parte que quase ninguém leva a sério: a description é o mecanismo de descoberta da skill

Ela é injetada no system prompt, então precisa dizer o que a skill faz E quando usá-la

A documentação recomenda escrever sempre em terceira pessoa, porque ponto de vista inconsistente atrapalha justamente essa descoberta

O erro comum deste passo: escrever description: skill de tom de voz e ir embora feliz… isso diz o que ela é, não quando ela deve entrar em campo, e aí ela nunca é chamada sozinha

3. Colocar os exemplos de texto aprovado no corpo

Uma seção com exemplos concretos de uso é prática recomendada pela documentação, e no caso de voz ela é o coração do arquivo

O formato que funciona é o par: aprovado de um lado, rejeitado do outro, com uma linha dizendo por que

## Exemplos de voz aprovada

Aprovado:
"A cobrança falhou. Seu acesso continua ativo até sexta, e a gente tenta de novo automaticamente"

Rejeitado:
"Identificamos uma inconsistência no processamento do seu pagamento e nossa equipe está empenhada em solucioná-la"

Por que: a marca diz o que aconteceu e o que o leitor precisa fazer, nessa ordem, sem eufemismo corporativo

O erro comum deste passo: colar cinco textos aprovados e nenhum rejeitado… sem contraexemplo, o modelo aprende um alvo, mas não aprende a fronteira

4. Escrever a lista de proibições

Aqui é lista fechada, sem poesia:

## O que a marca nunca escreve

- "solução completa", "solução robusta", "empoderar"
- "neste artigo vamos falar sobre" como abertura
- exclamação em texto de suporte
- emoji em página de preço

Repara que proibição é verificável: ou a palavra está no texto, ou não está

Adjetivo não tem essa propriedade, e é por isso que ele falha

O erro comum deste passo: transformar a lista em recomendação ("evite termos genéricos")… evite é opinião, a lista de termos é regra

5. Definir as regras de estrutura

Voz não é só vocabulário, é ritmo e formato

## Regras de estrutura

- Parágrafo de no máximo 3 linhas
- Uma ideia por parágrafo
- Abertura: cena concreta ou pergunta do leitor, nunca definição de dicionário
- Lista só quando os itens são paralelos entre si
- Todo H2 responde uma pergunta e funciona sozinho

A documentação de boas práticas orienta ser específico em vez de genérico e só adicionar o contexto que o Claude ainda não tem

O exemplo que ela dá é ótimo: remover a explicação do que significa win rate, porque o modelo já sabe

Traduzindo pra cá: não gaste linha explicando o que é um parágrafo curto, gaste linha dizendo o limite que a SUA marca usa

O erro comum deste passo: encher o arquivo de aula de redação… você está escrevendo o que falta, não um manual

6. Segurar o tamanho e mandar o resto pros arquivos irmãos

A recomendação é manter o corpo do SKILL.md abaixo de 500 linhas

Passou disso, divide em arquivos separados usando os padrões de progressive disclosure

E o que é progressive disclosure? É carregamento em camadas, se liga:

1. Na inicialização, o agente pré-carrega apenas name e description de cada skill instalada no system prompt
2. O SKILL.md completo só é lido quando a skill se torna relevante
3. Arquivos adicionais só são lidos conforme a necessidade

Esse padrão está documentado com a skill de PDF: o SKILL.md aponta pra arquivos extras (reference.md e forms.md) mantidos na mesma pasta, e o Claude lê forms.md só quando vai preencher um formulário

Na skill de voz a divisão sai sozinha:

voz-da-marca/
  SKILL.md        (regras + os exemplos essenciais)
  examples.md     (a biblioteca grande de aprovado x rejeitado)
  reference.md    (glossário, nomes de produto, jeito certo de escrever cada um)

O erro comum deste passo: despejar 40 exemplos dentro do SKILL.md porque "quanto mais contexto melhor"… o arquivo inteiro é lido quando a skill ativa, e o que é consulta ocasional vive melhor no arquivo irmão

7. Invocar e testar

No Claude Code dá pra chamar a skill na mão digitando / seguido do nome dela:

/voz-da-marca reescreve o e-mail de cobrança falhada que está em drafts/cobranca.md

Digitar / sozinho lista os comandos disponíveis

E tem um detalhe que muda o jeito de escrever a skill: se ela usa $ARGUMENTS, o texto digitado depois do comando entra ali; se ela não tem $ARGUMENTS, o Claude Code anexa ARGUMENTS: <o que você digitou> ao final do conteúdo da skill

Dá pra empilhar também: o Claude Code expande a primeira skill mais até cinco empilhadas depois dela, o que é útil quando você quer voz da marca + a skill que formata o post

No frontmatter ainda existem campos opcionais de comportamento, como disable-model-invocation (pra skill que só entra quando você chama na mão) e allowed-tools

O erro comum deste passo: testar com um pedido fácil… teste com o texto que costuma sair genérico, que é exatamente a falha que você documentou lá no passo zero

Por que "tom leve e profissional" produz texto genérico

O sintoma:

A skill está lá, a pasta está certa, ela ativa, e o texto continua com cara de qualquer marca

Você lê e pensa: tá bom, mas isso poderia ser de qualquer empresa do mesmo setor

A causa:

Adjetivo vago não é instrução executável, é rótulo

E rótulo vazio é preenchido com a média: a média do que existe escrito por aí sobre "leve" e sobre "profissional"

O resultado é literalmente a média da internet, e a média da internet é genérica por definição, né?

Por isso a documentação de boas práticas insiste em ser específico em vez de genérico e em só adicionar o contexto que o modelo ainda não tem

"Profissional" o Claude já sabe. O que ele não sabe é que a sua marca começa e-mail de suporte pelo fato, nunca pelo pedido de desculpas

A solução:

Troca cada adjetivo por evidência:

E corta o resto: explicação do que o Claude já sabe só ocupa espaço no arquivo que vai ser lido inteiro toda vez que a skill ativar

Como prevenir:

Escreve a avaliação ANTES da instrução

Pega as tarefas representativas (um e-mail de suporte, uma abertura de post, uma legenda curta), roda sem a skill, anota a falha específica de cada uma

Depois escreve o mínimo suficiente pra fechar aquelas lacunas, e só

Skill de voz engorda pela saída que ainda falha, não pela sua vontade de documentar tudo de uma vez

O que eu aprendi usando skills em todos os projetos

Vou ser honesto: o vídeo que eu gravei não é sobre voz de marca, é sobre as skills que eu uso em todo projeto com Claude Code

Mas o princípio que eu defendo lá é exatamente o mesmo, e é por isso que eu trouxe pra cá

Eu prefiro criar skill sob medida em vez de baixar uma pronta, porque eu quero que as regras estejam alinhadas com o que EU estou fazendo naquele projeto

Não é implicância com coleções de skills de terceiros, é que critério genérico entrega resultado genérico, e voz de marca é o caso mais extremo disso

Quando eu crio a skill personalizada, eu escrevo no prompt a lista de critérios que eu quero ver cobertos, tirados do que já vi dar problema na minha vivência, em vez de deixar o modelo escolher o que checar

E eu exijo na descrição da skill que a verificação seja mecânica: comando real, contagem de problemas e resultado em formato fixo (nota total, breakdown por categoria e lista de problemas), em vez de um parecer solto

Isso vale igualzinho pra voz: "o texto ficou na voz da marca?" é parecer solto

"quantos termos da lista de proibições apareceram e em quais linhas?" é verificação

No vídeo eu escolho criar a skill como skill de projeto, valendo só naquela pasta, e é o que eu faria de novo com voz de cliente

Tem outra coisa que eu falo lá e que se aplica direto aqui: com a skill de design, eu descrevo no prompt a sensação que eu quero passar (visual clean, moderno, que passe confiança, usuário no controle sem se sentir sobrecarregado) em vez de pedir só "melhore o layout"

O resultado desse tipo de skill varia MUITO conforme o prompt, e boa parte das reclamações de resultado ruim que eu vejo vem de prompt fraco, não da ferramenta

Na comparação antes e depois, o projeto saía com interface genérica, sem alma, e depois veio tipografia, consistência e um acabamento bem mais autoral

Texto sem voz de marca é a mesma doença: correto, entregue, sem alma

No vídeo abaixo eu mostro esse processo de criar skill sob medida e o antes e depois no projeto, e dá pra ver bem o tamanho da diferença entre critério seu e critério genérico:

Onde essa skill de voz vale mais a pena

Nem todo texto sofre igual sem voz definida

Esses aqui sofrem MUITO:

• Blog e newsletter: voz longa, onde o leitor passa minutos com você. É onde texto sem personalidade fica mais visível
• Redes sociais: voz curta, onde só sobra o jeito de dizer. Aqui a lista de proibições faz mais trabalho que os exemplos
• Respostas de suporte: é onde a marca é mais testada, porque o cliente já está irritado. Regra de estrutura (o fato primeiro, depois o que ele precisa fazer) vale ouro
• Documentação de produto: nome de recurso escrito de três jeitos diferentes é o clássico. Um reference.md irmão resolve isso melhor que qualquer briefing em PDF
• Time com várias pessoas escrevendo: aqui é o caso mais forte de todos

No caso do time, a skill de projeto entra no repositório e todo mundo passa a herdar a mesma voz sem precisar decorar nada

Quem entrou ontem escreve com a mesma régua de quem está lá há três anos, e a discussão sobre voz vira pull request no SKILL.md em vez de comentário solto na revisão

Se você quer ver como esse formato se distribui, a Anthropic mantém um repositório público de Agent Skills em anthropics/skills, com skills de exemplo autocontidas em pastas próprias com SKILL.md, incluindo casos de brand guidelines e comunicações internas

Dá pra ler a estrutura desses exemplos e roubar o formato descaradamente 😀

Agora, se a ideia é ampliar pra além da voz, tem outras ideias de skills pra automatizar o que você repete todo dia no Claude Code

Conclusão

Voz de marca vira executável quando deixa de ser adjetivo e vira três coisas concretas: exemplo, proibição e regra de estrutura

"Tom leve e profissional" o modelo preenche com a média

Um par de aprovado x rejeitado, uma lista fechada de palavras banidas e um limite de parágrafo ele consegue seguir e você consegue conferir

O próximo passo é pequeno, dá pra fazer hoje: cria a pasta, escreve um SKILL.md mínimo com name e description (em terceira pessoa, dizendo o que faz e quando usar), joga dentro dois pares de exemplo e a lista do que a marca não escreve

Depois roda as mesmas tarefas com e sem a skill, compara as duas saídas e engorda o arquivo de exemplos SÓ onde ainda saiu genérico

É assim que o arquivo cresce pelo motivo certo

Espero que ajude, e até o próximo post! 🙂