Pular para o conteúdo principal
Esta página é para engenheiros individuais que já estão usando Claude Code e desejam ajudar sua equipe a adotá-lo. Ela cobre o que compartilhar, como responder às perguntas que você receberá, um guia de trinta dias e respostas a preocupações comuns. A adoção de uma ferramenta de desenvolvedor raramente acontece por causa de um anúncio de lançamento. Acontece porque alguém da equipe começa a usar a ferramenta bem, fala sobre ela abertamente e facilita para outros seguirem. O trabalho que você faz como campeão tem um efeito desproporcional: cada exemplo que você compartilha encurta a curva de aprendizado para os engenheiros que vêm depois de você, e cada pergunta que você responde em público transforma a experiência de uma pessoa em algo que toda a equipe pode construir. Você está agindo como um multiplicador para sua equipe, não como um help desk, e este guia é estruturado para manter o papel sustentável nesses termos.

O papel do campeão

O papel consiste em três comportamentos que se reforçam mutuamente. A maioria disso se encaixa naturalmente no trabalho que você já está fazendo. A diferença é uma pequena quantidade de intenção adicional sobre onde suas descobertas são postadas e como suas respostas se propagam.

O que isso deve custar você

Defina expectativas com você mesmo e com seu líder. As atividades abaixo são destinadas a se encaixarem em uma semana de trabalho normal, e o papel deve permanecer um multiplicador do seu trabalho existente em vez de uma responsabilidade de suporte adicional.

Compartilhe o que você descobre

Sua própria experiência é o material mais persuasivo que seus colegas encontrarão, porque é específico para o codebase, fluxos de trabalho e problemas que todos compartilham. A documentação diz às pessoas o que é possível; seus posts mostram a eles o que está realmente funcionando em seu ambiente.

O que vale a pena compartilhar

Os posts mais úteis descrevem uma técnica que um colega pode reutilizar amanhã em vez de um resultado que já está completo. As técnicas se compõem conforme se espalham por uma equipe; atualizações de status não. Exemplos de técnicas reutilizáveis:
  • “Aprendi que @-mencionar um diretório funciona. Apontei para @src/components/ e perguntei quais estavam faltando testes, o que revelou dois que eu tinha negligenciado.”
  • “Plan mode (Shift+Tab) mostra exatamente quais arquivos serão tocados antes de qualquer edição ser feita, é por isso que estou confortável em usá-lo em código compartilhado.”
  • “Configurei um hook Stop para receber uma notificação de desktop quando uma tarefa longa é concluída. A configuração está na thread.”
  • “Executar /init gera um CLAUDE.md do repositório para que o assistente pare de fazer perguntas sobre nossas convenções.”

Onde compartilhá-lo

Poste onde sua equipe já lê. O objetivo é colocar exemplos no caminho do trabalho normal em vez de criar um destino.

O formato que funciona

Uma captura de tela acompanhada de uma única linha de contexto, ou uma breve descrição antes e depois, é geralmente o nível certo de detalhe. Mantenha cada post curto o suficiente para que alguém rolando ainda absorva o ponto. Uma redação longa tende a ser salva para depois e esquecida, enquanto um post curto com uma captura de tela tende a ser copiado e testado. Os posts de exemplo abaixo ilustram tom e comprimento; adapte-os em vez de copiar verbatim.

Seja a pessoa que as pessoas perguntam

Depois de compartilhar alguns exemplos, as perguntas virão. É aqui que o papel do campeão tem a maior alavancagem, porque uma boa resposta para uma pessoa frequentemente desbloqueia vários outros que estão observando o mesmo canal.

Responda com um prompt em vez de uma explicação

Quando um colega pergunta como você realizou algo, a resposta mais útil é o prompt que você realmente usou. Ele aprenderá mais executando esse prompt contra seu próprio problema do que com qualquer descrição que você pudesse escrever, e isso lhe dá algo em que ele pode agir imediatamente.

Aponte para o recurso em vez da documentação

Uma resposta como “Tente plan mode, pressione Shift+Tab até vê-lo” é mais útil no momento do que um link para a documentação. Se a pessoa precisar de mais profundidade depois, ela encontrará por conta própria; agora ela precisa da única coisa que a desbloqueia.

Perguntas que você provavelmente ouvirá

Cresça o círculo

O objetivo não é construir um programa ou possuir um lançamento. É estabelecer um pequeno número de hábitos leves que permitam que o momentum continue depois que você parar de impulsioná-lo ativamente. Quando as perguntas no canal estão sendo respondidas por pessoas além de você, o papel cumpriu seu trabalho.

Padrões que tendem a funcionar

Guia de trinta dias

Se um plano solto for útil, a sequência abaixo reflete o que tende a funcionar na maioria das equipes. Ajuste livremente para se adequar ao seu contexto.
1

Semana 1: Semeie o canal

Crie o canal, fixe o Quickstart e poste dois ou três de seus próprios exemplos com os prompts incluídos.Sinal de que está funcionando: alguns colegas reagem ou respondem, e pelo menos uma pergunta é feita no canal.
2

Semana 2: Comece o ritmo

Comece a thread semanal de show-and-tell, responda a todas as perguntas publicamente e compartilhe um skill personalizado ou trecho de CLAUDE.md.Sinal de que está funcionando: alguém além de você posta um exemplo do seu próprio.
3

Semana 3: Emparelhe e consolide

Ofereça duas ou três sessões curtas de emparelhamento e consolide as perguntas e respostas mais comuns em uma mensagem de FAQ fixada.Sinal de que está funcionando: você vê uso repetido, com os mesmos colegas retornando em vez de tentar uma vez e parar.
4

Semana 4: Passe adiante

Identifique um segundo campeão e compartilhe um breve resumo do que está funcionando e do que não está com seu líder ou administrador.Sinal de que está funcionando: as perguntas no canal estão sendo respondidas por pessoas além de você.

Quando alguém quer ir mais fundo

Você é a introdução calorosa em vez do programa de onboarding. Quando um colega passa de “devo tentar isso” para “como me torno eficaz com isso,” aponte-o para as páginas Quickstart e Common workflows. Elas contêm seções curtas cobrindo os recursos que são genuinamente úteis mas difíceis de descobrir por conta própria.

Responda a preocupações comuns

O ceticismo saudável é esperado; engenheiros devem ser cautelosos com ferramentas que tocam seu código. A resposta mais eficaz raramente é argumentar o caso geral. Em vez disso, reconheça a preocupação, ofereça um breve reframe e proponha uma demonstração concreta no código da própria pessoa. A maioria das preocupações é resolvida por uma única experiência bem-sucedida.

Folha de referência rápida

As técnicas abaixo são as que mais confiabilidade movem alguém de um primeiro teste para uso diário. Fixe esta tabela em um canal ou compartilhe-a por conta própria.
Claude Code é atualizado frequentemente. Verifique detalhes específicos da versão contra a página inicial da documentação antes de distribuir este material internamente.