Persona skills no Claude Code: por que nomear um especialista supera o role prompting

Role prompting trata a persona como uma fantasia. Uma persona skill trata como uma coordenada: um ponteiro para o que há de mais denso no que o modelo já sabe sobre o seu problema.

Este é o segundo texto de uma série.

O primeiro cobre o SKILL.md, as referências, o mapa de carregamento e quando vale a pena construir uma skill. Se você ainda não colocou uma skill em uso, comece pelo guia completo para criar skills no Claude Code.

Este é sobre uma única decisão dentro dessa arquitetura: dar ou não à sua skill o nome de uma pessoa. Feito de qualquer jeito, é teatro. Feito direito, é a jogada de maior alavancagem de todo o design. O motivo é mecânico, não estético.

Role prompting tem má fama, e a pesquisa confirma

Pesquise “role prompting” e você cai num debate que os próprios pesquisadores praticamente encerraram ao mudar de ideia no meio do estudo.

O paper mais citado sobre o tema é Zheng et al. (arXiv:2311.10054), depois aceito no Findings of EMNLP 2024. Veja o que aconteceu com a própria conclusão entre uma versão e outra.

A primeira versão, de novembro de 2023:

Por meio de uma análise extensa de 3 LLMs populares e 2457 perguntas, mostramos que adicionar papéis interpessoais aos prompts melhora consistentemente o desempenho dos modelos em uma variedade de perguntas.

(“Is ‘A Helpful Assistant’ the Best Role for Large Language Models?”, v1)

A versão final, de outubro de 2024, depois de ampliar o teste de três modelos para quatro famílias completas de modelos:

Por meio de uma análise extensa de 4 famílias populares de LLMs e 2.410 perguntas factuais, demonstramos que adicionar personas aos system prompts não melhora o desempenho dos modelos em uma variedade de perguntas, em comparação com o cenário de controle, sem persona.

(“When ‘A Helpful Assistant’ Is Not Really Helpful”, v3)

Mesmos autores, mesmas 162 personas, mesmo dataset. Eles viraram o resultado de “melhora consistentemente” para “não melhora” e reescreveram o título, de uma pergunta esperançosa para um veredito seco. A própria análise deles ainda crava o golpe final: nem a melhor persona para cada pergunta pode ser escolhida automaticamente melhor do que uma “seleção aleatória”.

Então os céticos têm razão, e eu concordo com eles. Como rótulo de uma linha, role prompting é fantasia. Muda o tom, não o conhecimento. O modelo se veste de “especialista em marketing” e te entrega o que qualquer post de LinkedIn diria.

Mas repare no que esse estudo, e todos os parecidos, de fato testaram: um rótulo de papel, sozinho, no system prompt, sem nada por trás. Nenhum deles testou um rótulo ligado a referências destiladas, frameworks de decisão e um mapa de roteamento. Porque isso não é um prompt. Isso é uma skill.

Uma persona dentro de uma skill é outra máquina.

Persona é um mecanismo de ativação, não uma fantasia

Nomear um especialista faz três coisas que uma linha de papel não faz. Cada uma é disciplina, não vibe:

1. Obriga você a estudar. Para personificar o Hormozi, você precisa extrair o método dele. A fantasia não exige lição de casa; a skill exige.
2. Mira num cluster mais denso do modelo. “Alex Hormozi” aponta para um corpus específico nos pesos: livros, palestras, transcrições, frases. “Um especialista em marketing” aponta para uma média.
3. Aumenta a densidade de cada resposta, porque a skill roteia para esse cluster em vez de torcer para o modelo chegar lá sozinho.

O resto do artigo são essas três, em ordem. O exemplo que atravessa o texto é uma skill do Alex Hormozi que uso para avaliar ofertas, funis, preço, garantias e retenção.

Força 1: personificar obriga você a estudar

Esta é a parte que ninguém vende, porque soa como trabalho.

Para personificar alguém bem, você precisa aprender o método dessa pessoa a ponto de conseguir codificá-lo. Uma linha de papel deixa você pular essa etapa. “Aja como o Hormozi” não custa nada e não ensina nada. Uma persona skill não deixa você trapacear: as referências ficam vazias até você preenchê-las, e só dá para preenchê-las lendo, assistindo e destilando até conseguir enunciar cada regra de decisão com as suas palavras.

Essa restrição é o recurso. A skill vem depois do seu estudo. Construí-la é o jeito de estudar.

Destile, não cole

O corpus não é a skill. Despejar três livros e quarenta transcrições em references/ te dá uma fantasia maior, não um método.

Destilar é extrair, com as suas palavras:

• princípios: as crenças que sustentam tudo
• frameworks: as estruturas repetíveis (Value Equation, Grand Slam Offer, RAISE)
• critérios de decisão: o que faz uma oferta passar ou reprovar
• exemplos e anti-padrões: como é o bom e o ruim, de forma concreta
• frases de calibração: as linhas que denunciam o desvio (falo delas mais adiante)

Destilar é completar, não só comprimir.

O modelo já conhece o Hormozi público pelos dados de treino: entrevistas, livros, vídeos. O que ele não conhece é a sua versão organizada: o Delivery Cube que você separou, as regras de decisão que você afiou, os exemplos internos que você usa para julgar uma oferta real. Você lê muito e fica só com o que ajuda a decidir.

Anatomia da skill

1

roteador SKILL.md

13

references/um arquivo por domínio de decisão

80KB

método destiladolivros, vídeos, playbooks

0

prompts para repetiro estudo mora na skill

Divida essas referências por decisão, não por fonte. A pergunta do usuário nunca chega como “Livro 2, capítulo 4”. Chega como um problema:

Referências divididas por decisão

Arquivo	Decisão que apoia
00-canon.md	Princípios centrais de oferta
01-value-equation.md	Valor percebido e preço
02-grand-slam-offer.md	Construção de oferta irresistível
04-pricing-and-guarantees.md	Preço, garantia e reversão de risco
07-closing-and-sales.md	Objeções e fechamento
08-retention-and-ltv.md	Retenção e LTV
11-decision-checklist.md	Veredito sobre uma oferta específica

Dividir por fonte (book-1.md, podcast-3.md) é bom para arquivar e ruim para executar. Divida pela decisão que o arquivo precisa tomar.

Força 2: o nome mira num cluster mais denso

O conhecimento de um LLM não é distribuído por igual.

Em torno de um especialista com nome e uma obra pública de verdade, ele é denso: livros, palestras, transcrições, as frases que a pessoa repete, os exemplos a que ela sempre recorre. Em torno de uma categoria abstrata como “um especialista em marketing”, é a média de tudo e de ninguém.

Nomear é como você escolhe em que região o modelo vai buscar primeiro. Trate isso como um modelo de trabalho, não como uma chave documentada. Ele prevê o comportamento com confiabilidade: um nome específico puxa um método específico, um genérico puxa a média.

Nomear é ativar

Um nome genérico ativa a mediana da internet. Um nome específico aponta para um corpus.

Nome fraco	Nome mais afiado
marketing	alex-hormozi-offer-design
writing	arthur-miller-script-review
seo	neil-patel-seo-strategy
teaching	feynman-explanation-review
funnels	russell-brunson-funnel-architecture

O nome mais afiado puxa frameworks específicos e uma voz específica. O nome genérico puxa a média.

Mas o nome só abre a porta. Entre de mãos vazias e você cai na armadilha.

É por isso que a Força 1 existe.

O nome ativa o cluster. As suas referências fazem o modelo usar a sua versão em vez da pública. Persona não é densidade. Ativar é o trabalho da persona. As referências carregam o método. Pule as referências e a skill vira cosplay: uma voz confiante sem nada por baixo.

O ExpertPrompting chega à mesma conclusão: “imagine que você é um especialista” não te dá quase nada. O que paga são as referências que você destilou.

Força 3: o roteamento transforma o cluster em densidade

A ativação te leva a uma boa região dos pesos. Não garante que o modelo leia as suas referências. Deixado por conta própria, o agente pega o atalho e responde com o que for mais fácil nos pesos.

O mapa de carregamento fecha essa lacuna. É a ponte explícita entre a intenção do usuário e a referência que deve responder a ela.

Mapa de carregamento do SKILL.md

Referência	Quando carregar
references/00-canon.md	Qualquer decisão de oferta
references/01-value-equation.md	Perguntas sobre valor, preço ou conversão
references/02-grand-slam-offer.md	Construir uma oferta nova
references/04-pricing-and-guarantees.md	Preço, garantia ou reversão de risco
references/07-closing-and-sales.md	Calls de venda, objeções, taxa de fechamento

A Anthropic chama isso de progressive disclosure: os metadados (name e description) ficam sempre no contexto, o corpo do SKILL.md carrega quando a skill é acionada, e os arquivos em references/ só carregam quando o modelo é instruído a buscá-los. Essa última parte é o pulo do gato. Nada carrega a referência certa automaticamente. Quem decide é o modelo, a partir das instruções que você escreveu. O mapa de carregamento é como você torna essa decisão obrigatória.

Sem o mapa, o agente chuta, e o chute favorece os pesos em vez dos seus arquivos. Com ele, uma pergunta de preço carrega pricing, uma pergunta de retenção carrega retention, e o cluster da persona já chega estreitado para a decisão em questão.

É daí que vem a densidade. Não do nome. Do roteamento.

Forçando o método para dentro da resposta

“Por favor, consulte as referências” é uma sugestão, e o modelo trata como sugestão. Você força densidade de forma estrutural, em camadas que se somam, cada uma tirando do agente uma forma de responder a partir dos pesos em vez das suas referências.

Quatro camadas que forçam densidade

1. L1

   Roteamento explícito

   A skill diz quais referências carregar para cada tipo de pergunta. Não deixe o agente decidir tudo sozinho. Ele vai tentar economizar esforço.

   +
2. L2

   Saída dependente de framework

   Se a resposta precisa aplicar a Value Equation, o RAISE ou a Grand Slam Offer, o modelo tem menos espaço para responder de forma genérica. O framework vira uma trava: para cumprir o formato de saída, o agente precisa usar a referência certa.

   Every recommendation must map to the relevant framework.
   If pricing is discussed, use RAISE.
   If offer value is discussed, use the Value Equation.

   +
3. L3

   Checklist de decisão

   Uma referência como decision-checklist.md obriga o modelo a cruzar critérios antes de dar um veredito. Conselho aberto vira palestra; um checklist vira decisão.

   +
4. L4

   Frases canônicas como calibração

   Ancoram o comportamento e denunciam o desvio. Se a resposta parece algo que qualquer assistente de IA poderia ter escrito, a persona não ancorou. As frases são o sinal.

   "Simple scales. Fancy fails."
   "Volume negates luck."
   "Revenue is vanity. Profit is sanity. Cash is reality."

Persona ou função? O limite da técnica

Nem toda skill deve ter um rosto.

Use persona quando houver um corpus forte por trás: livros, palestras, entrevistas, frameworks publicados, playbooks, estudos de caso. Alex Hormozi para ofertas, Russell Brunson para funis, Neil Patel para SEO, Richard Feynman para clareza.

Para trabalho técnico interno, uma função costuma ser melhor:

• security-reviewer
• database-migration-planner
• api-contract-auditor
• react-performance-reviewer
• technical-seo-auditor

A regra é simples. Se existe uma pessoa com um método público forte, uma persona pode ajudar. Se o trabalho depende mais de um checklist técnico do que de um estilo de pensamento, use uma função. Forçar persona onde ela não cabe deixa a skill teatral e traz de volta a fantasia da qual você queria escapar.

Persona skills são componíveis

Eu não rodo uma persona. Rodo várias, cada uma um módulo independente, com seu próprio contrato, suas referências e sua saída esperada.

Personas que rodo como skills separadas

Skill	Domínio
Alex Hormozi	Ofertas, preço, garantias, stack de valor
Russell Brunson	Funis, escada de valor, conversão
Gary Vaynerchuk	Conteúdo, distribuição, redes sociais
Neil Patel	SEO, palavras-chave, conteúdo orgânico
Arthur Miller	Roteiro e narrativa
Richard Feynman	Clareza didática

Não tento fazer duas personas discutirem dentro de uma chamada. Se preciso do Hormozi e do Brunson na mesma estratégia, rodo um, pego a saída e passo para o outro. A composição acontece na orquestração, não dentro da skill.

Pense em microsserviços. Cada um tem uma fronteira clara, faz uma coisa bem e devolve algo que o próximo consegue consumir. Uma boa persona skill tem a mesma propriedade. Ela não tenta resolver o mundo.

Como construo a primeira versão de uma persona skill

O processo começa pelo trabalho a ser feito. Uma frase. Se não cabe numa frase, a persona está ampla demais.

Construindo a primeira versão

Entrada

Um trabalho em uma frase. Se não cabe numa frase, a persona está ampla demais.

↓

1. 01Nomeie o corpus

   Escolha uma pessoa sobre quem o modelo tem material de verdade: livros, palestras, playbooks. Sem corpus, sem persona.

   ↓
2. 02Destile, não cole

   Extraia princípios, frameworks, critérios de decisão, exemplos, anti-padrões e frases de calibração com as suas palavras.

   ↓
3. 03Divida por decisão

   pricing-and-guarantees.md, closing-and-sales.md, e não book-1.md, video-2.md.

   ↓
4. 04Escreva o mapa de carregamento

   Pergunta de preço carrega pricing. Retenção carrega retention. Óbvio, e quase ninguém faz.

   ↓
5. 05Teste num caso real

   Uma oferta, um funil, um preço, uma objeção, um concorrente reais. Uma persona que só funciona num exemplo de brinquedo não está pronta para produção.

↓

Saída

Uma persona skill que você versiona, testa e reutiliza: infraestrutura, não fantasia

No exemplo do Hormozi, o corpus é concreto: $100M Offers, $100M Leads, $100M Money Models, os playbooks da Acquisition.com, vídeos, entrevistas e as frases canônicas. Numa skill interna, o corpus pode ser ADRs, pull requests antigos, runbooks, postmortems ou specs aprovadas. Mesma destilação, outro rosto.

Checklist de uma persona skill

Antes de considerar uma persona skill pronta, passo por isto:

Antes de uma persona skill ficar pronta

• ✓Obrigatório:
  O nome aponta para um corpus real e reconhecível.
• ✓Obrigatório:
  A description deixa a ativação clara.
• ✓Obrigatório:
  As referências estão destiladas com as suas palavras, não coladas.
• ✓Obrigatório:
  As referências estão divididas por decisão, não por fonte.
• ✓Obrigatório:
  Existe um mapa de carregamento explícito.
• ✓Obrigatório:
  O formato de saída obriga o uso do framework relevante.
• ✓Obrigatório:
  As frases canônicas estão presentes como calibração.
• ✓Obrigatório:
  Existe pelo menos um exemplo real de entrada e saída.
• ✓Obrigatório:
  A skill está versionada no git.
• ✓Obrigatório:
  Dá para testar se ela consultou as referências.

O erro que engana todo mundo: persona como densidade

A falha mais comum com persona é confiar na voz.

Você ancora “Alex Hormozi”, o tom acerta, a energia está certa, e você supõe que o método veio junto. Não veio. A voz sai de graça. O método são os 80KB que você teve que destilar.

A persona melhora a ativação. A densidade vem das referências. Sem referências, a skill é cosplay.

Então teste. Dê a mesma entrada real antes e depois da skill e compare: ela usou o framework, carregou a referência certa, largou as ressalvas genéricas e se manteve consistente em duas sessões? Se você não mede isso, não está rodando uma persona skill. Está só acreditando em uma.

FAQ

Role prompting funciona de verdade?+

Como prompt, quase nada. O estudo mais citado sobre o tema (Zheng et al., arXiv:2311.10054, Findings of EMNLP 2024) testou 162 personas em quatro famílias de modelos e concluiu que um simples rótulo de persona não melhora a precisão factual. Muda o tom, não o conhecimento.

Como skill, sim. A diferença não é a persona; são as referências destiladas e o mapa de carregamento por trás dela. Nomear um especialista sem nada por baixo é fantasia. Nomear um com um método por baixo é ativação mais recuperação.

O que a pesquisa diz sobre persona prompting e precisão?+

Que o rótulo sozinho não basta. Zheng et al. não encontraram ganho confiável de precisão com personas em system prompts, e o ExpertPrompting descobriu que 'imagine que você é um especialista' tem mais ou menos o mesmo resultado que nenhuma persona.

Este artigo concorda com esse resultado e vai além dele: os estudos testaram identidade sem conhecimento. Uma persona skill fornece a metade que falta: as referências e os frameworks que o especialista realmente usaria.

Persona skill é a mesma coisa que persona prompt?+

Não.

Um prompt é uma instrução de sessão que se perde. Uma persona skill é um módulo persistente: nome, referências destiladas, mapa de carregamento, formato de saída. O mesmo comportamento em toda sessão.

Toda skill precisa de persona?+

Não.

Persona ajuda quando existe uma obra pública reconhecível. Para tarefas técnicas internas, uma função costuma ser melhor: revisor, arquiteto, auditor de segurança, planejador de migração.

Quanto eu preciso destilar de fato?+

O suficiente para separar os domínios de decisão e dar um veredito real.

Minha skill de ofertas tem 13 referências e cerca de 80KB. Uma persona mais enxuta pode começar com 3 a 5 referências bem destiladas, desde que cada uma tome uma decisão.

O Claude Code deve carregar todas as referências automaticamente?+

Não.

Escreva um mapa de carregamento no SKILL.md dizendo ao agente quais arquivos carregar para cada tipo de pergunta. É isso que leva o cluster da persona à decisão em questão.

Dá para usar isso fora do Claude Code?+

Sim.

A arquitetura é portável. O SKILL.md é uma implementação, mas nomear um corpus, destilar referências e rotear até elas funciona em qualquer agente que suporte contexto persistente e arquivos de referência.

Fechando

Role prompting ganhou a má fama com mérito. Como fantasia de uma linha, muda o tom, não o conhecimento.

Uma persona skill é construída de outro jeito. O nome é uma coordenada, não decoração. Ele obriga você a estudar o método, mira o modelo no cluster mais denso e roteia as respostas pelas suas referências em vez da média da internet.

Um persona prompt dura uma sessão.

Uma persona skill é o estudo, o corpus e o roteamento. Rode num problema real. Ou as referências carregaram e a resposta é diferente, ou você ainda tem uma fantasia.