🎮 Operação

Cada arquivo crítico tem 1 e somente 1 teammate dono. Outros podem ler, mas só o dono escreve.

É a regra mais quebrada e a que mais causa estrago: overwrite silencioso e merge implícito.

Defina territórios no spawn; pastas-âncora por papel; troca via mensagem com link de arquivo.

Teammates falam direto entre si via SendMessage; o lead só entra para sintetizar ou desempatar.

Tudo passar pelo lead serializa o time e desperdiça tokens em consolidação prematura.

Mensagem unicast por nome; "envie o contrato da API para Frontend"; lead como árbitro.

Spawn em paralelo + tasks independentes na partida. Quem precisa esperar, espera por mensagem — não por turno.

Trabalho sequencial mascarado de "team" é o pior dos mundos: custo de team com latência de single.

Tasks paralelas; dependências explícitas; fan-out + fan-in; "todos acordam juntos".

Lab que força dois teammates a editar o mesmo arquivo e mostra o overwrite — depois corrige com ownership.

Ver acontecer treina o olho. Você nunca mais esquece de definir território.

Reproduzir o bug; corrigir o prompt; rodar de novo; ver a diferença lado a lado.

Casos pequenos onde 1 arquivo compartilhado é OK (ex: TODO.md temporário) — desde que documentado.

Regras viram dogma se não tiverem exceções claras; saber quebrar com critério é parte do ofício.

Apenas append; lock explícito via mensagem; nunca em arquivos críticos.

Após uma execução, revisar mailbox + git diff + task list para ver se as 3 regras foram seguidas.

Times "aparentemente bem" às vezes serializam por baixo. Auditar fecha o ciclo de aprendizado.

git blame + autor (teammate name); contagem de mensagens P2P vs lead; tempo de wall-clock por papel.

Todo teammate carrega CLAUDE.md do diretório de trabalho ao acordar — é o jeito mais robusto de dar instruções globais.

Boilerplate no spawn é caro; o que vale para todos vai no CLAUDE.md.

Convenções de código; mapas de pastas; políticas de testes; quando NÃO usar (instruções específicas da tarefa).

Conversa anterior do lead, decisões tomadas no chat, contexto implícito — tudo isso fica fora do teammate.

É a fonte mais comum de "o agente esqueceu o que combinamos": ele simplesmente nunca soube.

Tudo que importa vai no spawn ou em CLAUDE.md; histórico do lead é privado por design.

Um teammate pode usar uma subagent definition (em .claude/agents/) como tipo, herdando tools e modelo.

Uma vez que você tem um security-reviewer bom, vale para o time todo — não reescreva.

Body anexado ao system prompt; tools allowlist respeitada; skills/mcpServers NÃO se aplicam.

Você pode mudar o modo de permissão de um teammate específico depois que ele já está rodando.

Útil para "soltar" o agente quando ele provou que pode, ou apertar quando ele se mostra aventureiro.

Por teammate, em runtime; não há "per-teammate mode no spawn"; mensagem direta ao agente alvo.

Config em ~/.claude/teams/{team}/config.json; tasks em ~/.claude/tasks/{team}/.

Saber inspecionar ajuda a entender estado do time e diagnosticar travamentos.

NÃO editar config à mão; pode ler para diagnóstico; tasks com locking automático.

MCP servers configurados no projeto/user ficam disponíveis a todos os teammates como tools.

Ótima alavanca: 1 servidor MCP de qualidade = N teammates instantaneamente capazes.

Allowlist de tools por papel; auditoria via PostToolUse hook; cuidado com MCP que escrevem.

Teammate inicia em plan mode (sem write tools), pesquisa, monta o plano e só depois passa para execução.

Reduz drasticamente "agente fez merda no caminho errado"; pesquisa primeiro, executa depois.

Read-only por construção; tools de escrita desativadas; plano em formato estruturado.

Teammate envia plano formalmente para o lead via approval request. Lead pode aprovar ou rejeitar com feedback.

É um dos poucos pontos onde o lead bloqueia explicitamente o teammate — controle de qualidade.

Aprovação ou rejeição com motivo; rejeitado = volta para plan mode; loop até OK.

"Só aprove se o plano cobre testes; rejeite se mexe em schema". Critérios viram texto no prompt do lead.

Sem critérios, o lead aprova quase tudo. Critérios explícitos transformam ele em portão de qualidade.

Cobertura de testes; sem migração de DB sem flag; sem novos endpoints; "X linhas no máximo".

Quando rejeitado, teammate fica em plan mode, revisa com base no feedback e resubmete.

É o equivalente a "PR review" — apenas no spawn. Aproveita para enxugar escopo antes da execução.

Loop limitado por bom-senso; lead pode promover plano com mudanças; saída do plan mode = execução libera.

Em tarefas críticas, você pode pedir para todo plano passar pelo humano antes da execução.

No início, aprovar manualmente é o melhor jeito de calibrar critérios para depois delegar ao lead.

"Send all plans to me"; usar em produção/migrações; promover progressivamente o lead.

Spawn de "architect" em plan mode obrigatório, com 3 critérios de aprovação no prompt do lead.

Ver o ciclo completo treina o vocabulário e te dá confiança para operar sem aprovador humano.

Lab repetível; medir ciclos plano-revisão; ajustar critérios quando aprovar muito ou rejeitar muito.

Hook = evento (PreToolUse, TaskCompleted...) + matcher (qual tool/situação) + handler (script/HTTP).

Hooks são determinísticos. Onde prompt pode falhar, hook bloqueia com certeza.

Configurados em settings.json; matcher por regex; exit code 2 = bloqueia + envia stderr ao agente.

Dispara antes da task entrar na lista; pode bloquear com exit 2 + motivo no stderr.

Útil para vetar tasks ambíguas, com escopo grande demais ou que extrapolam o orçamento.

JSON na stdin com title/description; feedback no stderr volta ao agente como instrução.

Hook que roda pytest/npm test e bloqueia o "completed" se algo falha.

Transforma a task list em garantia de qualidade — não dá para "fechar tarefa quebrada".

Exit 2 com saída do pytest; quick subset de testes na task local; full suite no hook do team.

Quando um teammate vai dormir, hook pode dizer "ainda não, faltam estes deliverables" e devolvê-lo ao trabalho.

Evita "idle prematuro" comum em sessões longas — agente "achou que terminou".

Verificar arquivos requeridos; checar status de testes; só liberar quando tudo presente.

Hook que inspeciona parâmetros do tool antes de rodar — bloqueia padrões perigosos como rm -rf.

É a sua rede de segurança. Mesmo com permissões liberadas, hook protege contra acidentes.

Matcher por tool name; if "Bash(rm *)"; permissionDecision deny + reason.

Stop dispara ao fim de cada turno; PostToolUse após cada tool. Bons para logar custo, latência e erros.

Sem telemetria você não otimiza. Hooks de log dão dados para decidir tamanhos e modelos.

Logar em arquivo; decision "block" do Stop só em casos raros; cuidado com loops com Stop bloqueando.

Modo in-process: lead lista teammates; Shift+Down circula entre eles; Enter abre, Esc fecha.

Funciona em qualquer terminal. É o jeito mais portátil de usar Teams.

Shift+Down; Ctrl+T para task list; mensagens diretas digitando após selecionar.

Modo tmux: cada teammate ganha um pane próprio; você vê tudo simultaneamente.

Para diagnóstico e demos é imbatível: você vê quem está em idle e quem está trabalhando.

Instale tmux pelo gerenciador; --teammate-mode tmux; clique para interagir.

No macOS, iTerm2 com it2 CLI + Python API entrega split-pane sem precisar de tmux puro.

É mais "nativo" no macOS; tmux -CC dentro de iTerm2 é o entrypoint recomendado.

Habilitar Python API nas Settings; instalar it2 CLI; usar tmux -CC para integração.

VS Code integrated terminal, Windows Terminal e Ghostty NÃO suportam split-pane.

Saber evita 30 minutos de "por que meus teammates não aparecem em paneis?". Use in-process nesses terminais.

Verifique which tmux; se faltar, instale; use --teammate-mode in-process.

Shift+Down circula teammates; Ctrl+T abre task list; Esc interrompe turno; Enter foca.

Sem atalhos você perde 50% da produtividade; com atalhos você opera o time como um pianista.

Memorizar 4 atalhos; alternar lead ↔ teammate; mensagem direta em foco.

Quando o team não fecha limpo, sessões tmux ficam órfãs. Use tmux ls + tmux kill-session.

Sessões órfãs consomem memória e podem confundir o próximo run.

Encerre via lead primeiro; tmux só é último recurso; padronize nome de sessão.