Regras de handoff para equipes com Claude Code: evidências, permissões, rollback e receita

Por que o handoff de equipe importa

Usar Claude Code sozinho ainda pode funcionar com memória pessoal. Em equipe, isso não basta. Quando outra pessoa precisa revisar um patch gerado por IA, a pergunta não é apenas se o diff parece correto. Também é preciso saber quem aprovou a ação sensível, qual URL pública foi checada, que evidência pode ser repetida e qual caminho de receita foi protegido.

Isso é essencial em artigos, landing pages, páginas de produto, links Gumroad e formulários de consultoria. Um build pode passar enquanto o botão do PDF grátis aponta para o idioma errado. Um texto pode ficar melhor e, ao mesmo tempo, alterar uma promessa comercial. Um formulário pode parecer correto e falhar depois do envio.

O objetivo do handoff não é criar um diário longo de atividade. O objetivo é deixar um contrato curto de revisão: o que mudou, qual prova existe, qual permissão foi usada, como voltar atrás, o que não pode ser tocado e se PDF grátis, Gumroad e consultoria foram verificados.

Leia junto com o template de handoff de sessão, o Permission Budget Loop e o checklist de revisão. Para fundamentos do produto, consulte também a documentação oficial do Claude Code.

Falhas comuns no handoff

A primeira falha é passar só um log: “ampliei o artigo”, “corrigi links”, “rodei build”. Isso não mostra ao reviewer em qual prova confiar, que página abrir ou qual caminho de conversão foi testado. Revisão precisa de evidência, não apenas de memória do processo.

A segunda falha é deixar regras de aprovação só na conversa. Alguém acha que pediu uma pequena correção de texto, mas Claude Code acaba mexendo em preço, destino de CTA, configuração de deploy ou formulário público. Se o limite de permissão não está escrito, o reviewer precisa adivinhar intenção olhando o diff.

A terceira falha é não registrar rollback. Se uma mudança de IA quebra a página depois da publicação, a equipe precisa saber o ponto de restauração, o comando de reversão e a ordem de recuperação. Sem isso, os primeiros minutos viram discussão de responsabilidade, não recuperação da página ou do fluxo de compra.

A quarta falha é tratar receita como trabalho de outra pessoa. Em operação de conteúdo, tráfego é só o começo. O leitor precisa conseguir baixar o PDF grátis, comprar no Gumroad ou enviar uma consulta. Esses caminhos fazem parte da superfície funcional do artigo.

No fluxo de Masa, o problema não era apenas artigo curto. O problema maior era que o reviewer não conseguia ver rapidamente se o artigo ainda estava ligado ao caminho certo de aprendizado e compra. Ao colocar prova, permissão, rollback e receita no handoff, os comentários passaram de “o que eu olho?” para “essa evidência basta” ou “falta checar Gumroad”.

Evidências que devem ir para review

Boa evidência é concreta e repetível. O reviewer deve conseguir rodar o mesmo comando, abrir a mesma URL e entender o mesmo limite de risco. Para um artigo, isso costuma incluir tamanho do corpo, quantidade de h2, links internos, links externos, blocos de código, heroImage, qualidade da localização e destino do CTA.

Para uma página de produto, inclua visual mobile, envio de formulário, texto de preço, link de compra, canonical e página de obrigado. Para uma tarefa de desenvolvimento, inclua testes, type check, build, arquivos afetados e riscos pendentes. A checklist muda, mas a pergunta é sempre: o que o reviewer consegue validar sem adivinhar?

Um registro mínimo de comandos pode ficar assim:

npm run build
node scripts/check-updated-article-quality.mjs

Se algum comando não foi executado, não escreva apenas “não testado”. Explique o motivo e onde será verificado: dependências ausentes, API key local indisponível, ambiente só em CI ou necessidade de preview online. Assim a lacuna fica visível e revisável.

Screenshots ajudam, mas não bastam sozinhos. Um screenshot prova que um viewport parecia correto em um momento. Ele não prova destino de link, compra ou rollback. Combine screenshot com URL, resultado de comando e nota curta de risco.

Kit mínimo para copiar e colar

Cole este bloco Markdown na descrição do PR, Issue, Slack ou Notion. Ele é curto de propósito. Um handoff que leva vinte minutos para preencher não sobrevive no uso diário.

# Claude Code team handoff

## Change made
- 

## Proof
- build:
- public URL:
- screenshot:

## Revenue path checked
- free PDF:
- Gumroad:
- consultation:

## Next owner
- reviewer:
- decision needed:
- do not touch:

Permissões funcionam melhor quando também podem ser lidas por máquina. Este JSON não substitui uma política de segurança, mas dá a Claude Code e à equipe a mesma linguagem de limites.

{
  "approval_rules": {
    "safe": ["read files", "search", "small copy edit"],
    "review_required": ["pricing", "CTA links", "deployment"],
    "blocked": ["secrets", "force push", "delete customer data"]
  }
}

Também fixe o prompt do reviewer. Sem escopo claro, a revisão se espalha para gosto de estilo, debates antigos de produto ou refactors fora do pedido.

You are receiving a Claude Code handoff.
Check the proof first.
Then review only:
1. whether the stated goal was met
2. whether protected links still work
3. whether the next owner has one clear action

Template de permissões, rollback e receita

Em equipe, permissões, rollback e receita devem ficar no mesmo template. Muitos incidentes começam quando alguém aprova algo verbalmente, ninguém registra o ponto de restauração e todos assumem que o CTA ainda funciona.

handoff:
  owner: "Masa"
  reviewer: "team-reviewer"
  permission:
    safe:
      - "copy edit inside the article body"
      - "run local quality checks"
    needs_review:
      - "price copy"
      - "CTA destination"
      - "deployment setting"
    blocked:
      - "secrets"
      - "customer data"
      - "force push"
  rollback:
    restore_point: "commit or branch before Claude Code work"
    command: "git revert <commit>"
    priority_path:
      - "public article page"
      - "free PDF signup"
      - "Gumroad purchase"
      - "consultation form"
  revenue:
    free_pdf: "checked"
    gumroad: "checked"
    consultation: "checked"

Esse template não existe para criar burocracia. Uma alteração pequena de artigo leva cinco minutos para registrar. Se o trabalho toca preço, compra, formulário, dados de cliente ou deploy, esses campos devem estar completos antes do pedido de review.

Quatro casos reais de uso

O primeiro caso é publicação de artigo. Um redator expande o texto com Claude Code; depois um editor ou engenheiro verifica script de qualidade, página pública, links internos, link externo, heroImage e CTA do PDF grátis. O reviewer não precisa reler o site inteiro: ele confere se a melhoria prometida e o caminho de conversão funcionam.

O segundo caso é copy de produto. Um PM pode pedir para Claude Code reescrever a descrição de um material no Gumroad, mas preço, condições, destino do CTA e link de compra ficam em review_required. Isso evita que um texto melhor altere uma promessa comercial sem aprovação.

O terceiro caso é melhoria da página de consultoria. Claude Code pode organizar títulos, reescrever perguntas e remover repetição. Mesmo assim, o handoff precisa provar que o formulário envia, que mensagens de erro aparecem e que a página de obrigado abre. Caso contrário, a equipe melhora o texto e quebra o caminho de lead.

O quarto caso é manutenção de política de permissões. Se o lead define que leitura e busca são safe, preço e deploy precisam de review, e secrets ou dados de cliente são blocked, essa regra deve ser entregue como diff. A próxima sessão de Claude Code pode receber o mesmo contexto.

Como o reviewer deve ler o handoff

O reviewer começa pela evidência, não pelo diff. Confere build ou script de qualidade, abre preview ou URL pública, vê o screenshot se existir e testa links protegidos. Se a evidência falta, devolve o handoff como incompleto em vez de inferir resultado pelo código.

Depois vem o escopo de permissão. Se a mudança ficou em safe, uma revisão normal basta. Se tocou preço, CTA, deploy, formulários ou copy de receita, o owner responsável precisa confirmar. Se tocou algo blocked, não deve ir para merge mesmo que o resultado pareça útil.

Por fim vem rollback. Um handoff sem rollback não está pronto para operação. Em um artigo puro, reverter um commit pode bastar. Em produto, checkout, tracking ou consultoria, a ordem importa: primeiro recuperar a página pública, depois PDF grátis, Gumroad e formulário de consulta.

Caminho natural para materiais e consultoria

Para adoção individual, comece pelo cheatsheet gratuito de Claude Code. Ele basta quando o bloqueio principal é lembrar comandos e criar hábitos seguros. Quando prompts de review, debugging, melhoria de artigos ou documentação começam a se repetir, use 50 Claude Code Prompt Templates.

Para equipes, o Claude Code Setup Guide ajuda a padronizar CLAUDE.md, hooks, permissões, MCP e comandos de verificação. Ele serve quando a equipe consegue executar internamente, mas precisa de estrutura.

Se a parte cara é decidir quem aprova, quais links proteger e como conectar AdSense, Gumroad e consultoria, compare a página de produtos e use a página de consultoria. Consultoria não resolve só um prompt; ela desenha responsabilidade, evidência, rollback e prioridades de receita.

O caminho natural é simples: PDF grátis para hábitos, Gumroad para fluxos repetíveis e consultoria para regras específicas da equipe. Assim a recomendação acompanha a maturidade do leitor.

O que verifiquei neste artigo

Este artigo inclui handoff Markdown, regras JSON, prompt de reviewer e template YAML de permissões, rollback e receita. A intenção é tornar o trabalho do Claude Code revisável por outra pessoa, não apenas compreensível para quem rodou a sessão. Na prática, o handoff funciona quando o próximo owner responde rápido: o que mudou, qual prova existe e qual caminho precisa ficar protegido.