team

Skill Team

Cria N agentes coordenados trabalhando em uma lista de tarefas compartilhada usando a equipe implícita de agentes do Claude Code. O Claude Code 2.1.178+ removeu os comandos nativos TeamCreate/TeamDelete; com CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1, cada sessão tem uma equipe implícita e os colegas de equipe são gerados diretamente com a ferramenta Agent/Task usando valores name distintos. Esta skill ainda preserva a orquestração legada de workers tmux/CLI do OMC onde documentado (omc team / /omc-teams).

O alias de compatibilidade swarm foi removido no PR #1131.

Uso

/oh-my-claudecode:team N:tipo-de-agente "descrição da tarefa"
/oh-my-claudecode:team "descrição da tarefa"
/oh-my-claudecode:team ralph "descrição da tarefa"

Parâmetros

• N - Número de agentes colegas (1-20). Opcional; o padrão é o dimensionamento automático baseado na decomposição da tarefa.
• tipo-de-agente - Agente OMC a ser gerado para o estágio team-exec (ex.: executor, debugger, designer, codex, gemini, antigravity). Opcional; o padrão é o roteamento consciente do estágio. Use codex para gerar workers do Codex CLI, gemini para workers do Gemini CLI (nível enterprise/chave de API), ou antigravity para workers do Antigravity CLI (agy) (sucessor do Google para o Gemini CLI; requer as respectivas CLIs instaladas). Consulte Roteamento de Agentes por Estágio abaixo.
• tarefa - Tarefa de alto nível a ser decomposta e distribuída entre os colegas.
• ralph - Modificador opcional. Quando presente, envolve o pipeline da equipe no loop de persistência do Ralph (repetição em caso de falha, verificação do arquiteto antes da conclusão). Consulte Composição Team + Ralph abaixo.

Exemplos

/team 5:executor "corrigir todos os erros TypeScript no projeto"
/team 3:debugger "corrigir erros de build em src/"
/team 4:designer "implementar layouts responsivos para todos os componentes de página"
/team "refatorar o módulo de autenticação com revisão de segurança"
/team ralph "construir uma API REST completa para gerenciamento de usuários"
# Com workers do Codex CLI (requer: npm install -g @openai/codex)
/team 2:codex "revisar arquitetura e sugerir melhorias"
# Com workers do Gemini CLI (requer: npm install -g @google/gemini-cli)
/team 2:gemini "redesenhar os componentes de UI"
# Com workers do Antigravity CLI (requer: instalar conforme https://antigravity.google)
/team 2:antigravity "redesenhar os componentes de UI"
# Misto: Codex para análise de backend, Gemini/Antigravity para frontend (delegar por tarefa com /oh-my-claudecode:ask)

Arquitetura

Usuário: "/team 3:executor corrigir todos os erros TypeScript"
              |
              v
      [ORQUESTRADOR DA EQUIPE (Líder)]
              |
              +-- Usa a equipe implícita do Claude Code da sessão
              |       -> sem chamada TeamCreate; o líder permanece na sessão atual
              |
              +-- Analisar e decompor a tarefa em subtarefas
              |       -> explore/architect produz uma lista de subtarefas
              |
              +-- Criar entradas na lista de tarefas a partir do plano de implementação
              |       -> entradas TODO/tarefa #1, #2, #3 com dependências
              |
              +-- Atualizar entradas da lista de tarefas (pré-atribuir donos)
              |       -> tarefa #1 dono=worker-1, etc.
              |
              +-- Tarefa(nome="worker-1") x 3
              |       -> gera colegas na equipe
              |
              +-- Loop de monitoramento
              |       <- mensagens dos colegas (entregues automaticamente pela superfície ativa da equipe)
              |       -> revisão da lista de tarefas/TodoWrite para progresso
              |       -> enviar mensagens aos colegas através da superfície ativa da equipe para desbloquear/coordenar
              |
              +-- Conclusão
                      -> solicitar desligamento de cada colega através da superfície ativa da equipe
                      <- confirmação de desligamento dos colegas
                      -> limpar estado da equipe OMC (sem chamada TeamDelete)
                      -> rm .omc/state/team-state.json

Modelo de equipe nativa do Claude Code (2.1.178+):

- Nenhum diretório ~/.claude/teams/<nome>/ é criado por esta skill.
- Nenhuma chamada TeamCreate/TeamDelete está disponível.
- `team_name` é aceito pelo Claude Code nativo apenas como metadado legado ignorado; não confie nele para roteamento.
- Gere colegas diretamente via Agent/Task com `name="worker-N"`.

Relacionamento com o Workflow de Metas

Team é a autoridade OMC para execução paralela e em estágios. Use as políticas de conflito determinísticas refuse, adopt_existing e artifact_only em vez de tratamento de avisos não determinístico. Se uma tarefa mencionar /goal do Claude Code, Ralph ou Ultragoal somente de artefato, mantenha Team como autoridade principal do loop, a menos que o líder entregue explicitamente o controle. Use /goal apenas como um alvo de entrega nativo documentado do Claude Code ou como evidência visível da sessão líder; não afirme que o avaliador /goal executa comandos, lê arquivos ou substitui team-verify / team-fix de forma independente. Referências a Ultragoal somente de artefato devem ser tratadas como artefatos duráveis de registro de metas/checkpoint/evidência, não como execução de worker por si só.

Pipeline em Estágios (Runtime Canônico da Equipe)

A execução da equipe segue um pipeline em estágios:

team-plan -> team-prd -> team-exec -> team-verify -> team-fix (loop)

Roteamento de Agentes por Estágio

Cada estágio do pipeline usa agentes especializados -- não apenas executores. O líder seleciona agentes com base no estágio e nas características da tarefa.

Estágio	Agentes Obrigatórios	Agentes Opcionais	Critérios de Seleção
team-plan	explore (haiku), planner (opus)	analyst (opus), architect (opus)	Use analyst para requisitos pouco claros. Use architect para sistemas com limites complexos.
team-prd	analyst (opus)	critic (opus)	Use critic para desafiar o escopo.
team-exec	executor (sonnet)	executor (opus), debugger (sonnet), designer (sonnet), writer (haiku), test-engineer (sonnet)	Combine o agente ao tipo de subtarefa. Use executor (modelo=opus) para trabalho autônomo complexo, designer para UI, debugger para problemas de compilação, writer para documentação, test-engineer para criação de testes.
team-verify	verifier (sonnet)	test-engineer (sonnet), security-reviewer (sonnet), code-reviewer (opus)	Sempre execute verifier. Adicione security-reviewer para alterações de autenticação/criptografia. Adicione code-reviewer para >20 arquivos ou alterações arquiteturais. code-reviewer também cobre verificações de estilo/formatação.
team-fix	executor (sonnet)	debugger (sonnet), executor (opus)	Use debugger para erros de tipo/build e isolamento de regressão. Use executor (modelo=opus) para correções complexas em vários arquivos.

Regras de roteamento:

1. O líder escolhe os agentes por estágio, não o usuário. O parâmetro N:tipo-de-agente do usuário substitui apenas o tipo de worker do estágio team-exec. Todos os outros estágios usam especialistas apropriados ao estágio.
2. Agentes especialistas complementam agentes executores. Roteie análise/revisão para agentes architect/critic Claude e trabalho de UI para agentes designer. Workers tmux CLI são de uso único e não participam da comunicação da equipe.
3. O modo de custo afeta o nível do modelo. Em downgrade: agentes opus para sonnet, sonnet para haiku onde a qualidade permitir. team-verify sempre usa pelo menos sonnet.
4. O nível de risco eleva a revisão. Alterações sensíveis à segurança ou com >20 arquivos devem incluir security-reviewer + code-reviewer (opus) em team-verify.

Critérios de Entrada/Saída do Estágio

• team-plan
  • Entrada: A invocação da equipe é analisada e a orquestração começa.
  • Agentes: explore varre o código, planner cria o grafo de tarefas, opcionalmente analyst/architect para tarefas complexas.
  • Saída: a decomposição está completa e um grafo de tarefas executável está preparado.
• team-prd
  • Entrada: o escopo é ambíguo ou os critérios de aceitação estão faltando.
  • Agentes: analyst extrai requisitos, opcionalmente critic.
  • Saída: critérios de aceitação e limites estão explícitos.
• team-exec
  • Entrada: a atribuição da lista de tarefas e a geração dos workers estão completas.
  • Agentes: workers gerados como o tipo especialista apropriado por subtarefa (consulte a tabela de roteamento).
  • Saída: as tarefas de execução atingem o estado terminal para a passagem atual.
• team-verify
  • Entrada: a passagem de execução termina.
  • Agentes: verifier + revisores apropriados à tarefa (consulte a tabela de roteamento).
  • Saída (aprovado): as portas de verificação passam sem acompanhamento necessário.
  • Saída (falhou): as tarefas de correção são geradas e o controle passa para team-fix.
• team-fix
  • Entrada: a verificação encontrou defeitos/regressões/critérios incompletos.
  • Agentes: executor/debugger dependendo do tipo de defeito.
  • Saída: as correções estão completas e o fluxo retorna para team-exec e depois team-verify.

Loop de Verificação/Correção e Condições de Parada

Continue team-exec -> team-verify -> team-fix até:

1. a verificação passar e nenhuma tarefa de correção necessária permanecer, ou
2. o trabalho atingir um resultado terminal explícito de bloqueio/falha com evidência.

team-fix é limitado por tentativas máximas. Se as tentativas de correção excederem o limite configurado, faça a transição para falha terminal (sem loop infinito).

Convenção de Passagem de Estágio

Ao fazer a transição entre estágios, o contexto importante — decisões tomadas, alternativas rejeitadas, riscos identificados — existe apenas no histórico da conversa do líder. Se o contexto do líder for compactado ou os agentes reiniciarem, esse conhecimento é perdido.

Cada estágio concluído DEVE produzir um documento de passagem antes da transição.

O líder escreve as passagens em .omc/handoffs/<nome-do-estagio>.md.

Formato da Passagem

## Passagem: <estágio-atual> → <próximo-estágio>

- **Decidido**: [decisões importantes tomadas neste estágio]
- **Rejeitado**: [alternativas consideradas e por que foram rejeitadas]
- **Riscos**: [riscos identificados para o próximo estágio]
- **Arquivos**: [arquivos principais criados ou modificados]
- **Restante**: [itens deixados para o próximo estágio resolver]

Regras da Passagem

1. O líder lê a passagem anterior ANTES de gerar os agentes do próximo estágio. O conteúdo da passagem é incluído nos prompts de geração de agentes do próximo estágio, garantindo que os agentes comecem com contexto completo.
2. As passagens se acumulam. O estágio de verificação pode ler todas as passagens anteriores (plano → prd → exec) para o histórico completo de decisões.
3. No cancelamento da equipe, as passagens sobrevivem em .omc/handoffs/ para retomada da sessão. Elas não são excluídas pela limpeza nativa da equipe do Claude Code; nenhuma chamada TeamDelete existe no Claude Code 2.1.178+.
4. As passagens são leves. Máximo de 10-20 linhas. Elas capturam decisões e justificativas, não especificações completas (essas vivem em arquivos de entrega como DESIGN.md).

Exemplo

## Passagem: team-plan → team-exec

- **Decidido**: Arquitetura de microsserviços com 3 serviços (auth, api, worker). PostgreSQL para persistência. JWT para tokens de autenticação.
- **Rejeitado**: Monólito (preocupações de escalabilidade), MongoDB (a experiência da equipe é SQL), cookies de sessão (design API-first).
- **Riscos**: O serviço worker precisa de Redis para fila de jobs — ainda não provisionado. O serviço auth não tem limitação de taxa no design inicial.
- **Arquivos**: DESIGN.md, TEST_STRATEGY.md
- **Restante**: Scripts de migração de banco de dados, configuração de pipeline CI/CD, provisionamento de Redis.

Semânticas de Retomada e Cancelamento

• Retomar: reiniciar a partir do último estágio não terminal usando o estado em estágios + status da tarefa em tempo real. Leia .omc/handoffs/ para recuperar o contexto da transição do estágio.
• Cancelar: /oh-my-claudecode:cancel solicita desligamento dos colegas, aguarda respostas (melhor esforço), marca a fase como cancelada com active=false, captura metadados de cancelamento, então exclui recursos da equipe e limpa/preserva o estado da equipe conforme a política. Os arquivos de passagem em .omc/handoffs/ são preservados para possível retomada.
• Os estados terminais são completo, falhou e cancelado.

Portão de compatibilidade psmux tmux no Windows

No Windows nativo, não diga aos usuários que /team requer WSL ou que tmux não está disponível até que o binário real compatível com tmux tenha sido verificado. O psmux nativo instala um comando compatível com tmux (frequentemente tmux / tmux.cmd) e é um multiplexador de equipe suportado.

Antes de bloquear ou recorrer no Windows:

1. Verifique tmux -V (ou o equivalente da plataforma, como where tmux seguido por tmux -V).
2. Trate um tmux -V bem-sucedido com suporte psmux como tmux disponível.
3. Se psmux/tmux estiver disponível, continue o fluxo normal da equipe; não emita orientação de WSL.
4. Apenas quando nenhum binário compatível com tmux estiver disponível, diga ao usuário para instalar o psmux para suporte nativo ao Windows ou usar WSL2 como alternativa.

Workflow

Fase 1: Analisar Entrada

• Extrair N (contagem de agentes), validar 1-20
• Extrair tipo-de-agente, validar se mapeia para um subagente OMC conhecido
• Extrair descrição da tarefa

Fase 2: Analisar e Decompor

Use explore ou architect (via MCP ou agente) para analisar o código e quebrar a tarefa em N subtarefas:

• Cada subtarefa deve ter escopo de arquivo ou escopo de módulo para evitar conflitos
• As subtarefas devem ser independentes ou ter uma ordem clara de dependência
• Cada subtarefa n