Templates de Prompts para Equipas de Agentes

Problema: As Equipas de Agentes estão ativadas, e "cria uma equipa para ajudar no meu projeto" dá-lhe uma confusão. A diferença entre uma equipa eficaz e um desperdício de tokens vem da forma como o prompt é construído. Uma equipa produtiva tem papéis específicos, fronteiras de ficheiros claras e uma linha de chegada definida. Uma má tem três revisores a fazer trabalho sobreposto.

Solução rápida: Experimente primeiro o prompt de revisão de código paralela (padrão #1 abaixo). É o padrão de Equipas de Agentes mais amplamente útil e corre em qualquer base de código. Três revisores, três perspetivas, uma revisão sintetizada. Vai ver o output em minutos, e apanha coisas que um único revisor teria perdido.

Este é um complemento à visão geral das Equipas de Agentes. Comece por lá se ainda não configurou a sua primeira equipa. Para controlos e configuração, vá para Controlos Avançados. Os dez prompts abaixo cobrem os fluxos de trabalho onde a execução paralela com coordenação ativa bate o trabalho serial.

Padrões para Equipas de Código

1. Revisão de Código Paralela

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings. Use delegate mode so the
lead synthesizes a final review without doing its own analysis.

Porquê funciona: Um revisor tende para um tipo de problema de cada vez. Dividir os critérios em domínios independentes significa que segurança, desempenho e cobertura de testes recebem cada um uma passagem completa ao mesmo tempo. O líder junta tudo numa revisão que apanha problemas que nenhum revisor individual apanharia. Equipas de três revisores consistentemente detetam problemas que revisões de passagem única deixam cair. Espere cerca de 2-3x o custo de tokens de uma revisão de sessão única. Vale a cobertura.

O modo delegate é importante. Sem ele, o líder tende a fazer a sua própria revisão e a misturá-la estranhamente com os resultados dos colegas. Com o modo delegate ativo, o líder foca-se inteiramente na coordenação e síntese.

2. Debugging com Hipóteses Concorrentes

Users report the app exits after one message instead of staying connected.
Spawn 5 agent teammates to investigate different hypotheses. Have them talk
to each other to try to disprove each other's theories, like a scientific
debate. Update the findings doc with whatever consensus emerges.

Porquê funciona: Uma estrutura de debate bate o viés de ancoragem. A investigação sequencial fica presa na primeira teoria plausível e acaba a tentar confirmá-la. Múltiplos investigadores independentes a tentar ativamente desprovar uns os outros significa que a teoria que sobrevive está mais perto da causa raiz real.

Este padrão também revela ligações inesperadas. Quando o colega #3 encontra uma fuga de memória e o colega #1 estava a seguir comportamento de timeout, eles podem ligar os pontos diretamente. Sem líder no meio. Esse canal direto é o que separa as Equipas de Agentes dos padrões de sub-agentes.

3. Implementação de Funcionalidade Full-Stack

Create an agent team to implement the user notifications system.
Spawn four teammates:
- Backend: Create the notification service, database schema, and API endpoints
- Frontend: Build the notification bell component, dropdown, and read/unread states
- Tests: Write integration tests for the full notification flow
- Docs: Update the API documentation and add usage examples

Assign each teammate clear file boundaries. Backend owns src/api/notifications/
and src/db/migrations/. Frontend owns src/components/notifications/.
Tests own tests/notifications/. No file overlap.

Porquê funciona: Fronteiras ao nível de ficheiros eliminam conflitos de merge. Cada colega sabe quais diretórios possui, e a lista de tarefas partilhada mantém todos na mesma página. No momento em que o colega de backend entrega o contrato da API, o colega de frontend pega nele. Ambos estão a observar a mesma lista.

Sem fronteiras explícitas, dois colegas vão editar o mesmo ficheiro e colidir. A propriedade ao nível de diretório é o detalhe mais importante num prompt de implementação. Este padrão mapeia diretamente para o modelo de execução em ondas no guia de fluxo de trabalho, onde contratos upstream alimentam prompts de criação de agentes paralelos.

4. Registo de Decisão de Arquitetura

Create an agent team to evaluate database options for our new analytics feature.
Spawn three teammates, each advocating for a different approach:
- Teammate 1: Argue for PostgreSQL with materialized views
- Teammate 2: Argue for ClickHouse as a dedicated analytics store
- Teammate 3: Argue for keeping everything in the existing MongoDB

Have them challenge each other's arguments. Focus on: query performance
at 10M+ rows, operational complexity, migration effort, and cost.
The lead should synthesize a decision document with the strongest arguments
from each side.

Porquê funciona: A deliberação bate um único agente a pesar opções sozinho. Cada colega compromete-se com uma posição e vai à procura de falhas nas outras. O líder escreve apenas os argumentos que sobrevivem ao desafio.

Este é especialmente útil para decisões onde cada opção tem trade-offs reais e nenhum vencedor óbvio. Uma sessão única tende a escolher uma cedo e a racionalizá-la até ser a resposta. A estrutura adversarial força a avaliação genuína de todas as alternativas.

5. Análise de Bottlenecks

Create an agent team to identify performance bottlenecks in the application.
Spawn three teammates:
- One profiling API response times across all endpoints
- One analyzing database query performance and indexing
- One reviewing frontend bundle size and rendering performance

Have them share findings when they discover something that affects
another teammate's domain (e.g., slow API caused by missing DB index).

Porquê funciona: A comunicação entre domínios é onde as Equipas de Agentes batem os sub-agentes. Quando o analista de base de dados encontra um índice em falta que explica o endpoint lento do colega de API, passa a informação diretamente. Sub-agentes não conseguem fazer isso, porque sub-agentes só reportam de volta à sessão principal e nunca falam entre si.

Uma caça a problemas de desempenho também beneficia da lista de tarefas partilhada. À medida que cada colega regista problemas com classificações de severidade, o líder observa o quadro a formar-se em tempo real e redireciona esforços para os piores offenders.

6. Classificação de Inventário

Create an agent team to classify our product catalog. We have 500 items
that need categorization, tagging, and description updates.
Spawn 4 teammates, each handling a segment:
- Teammate 1: Items 1-125
- Teammate 2: Items 126-250
- Teammate 3: Items 251-375
- Teammate 4: Items 376-500

Use the classification schema in docs/taxonomy.md. Have teammates
flag edge cases for the lead to review.

Porquê funciona: Trabalho data-paralelo escala linearmente com os colegas. Cada um trabalha na sua fatia de forma independente, sinalizando itens ambíguos para uma revisão humana. Quatro colegas a processar 125 itens cada chega aproximadamente 4x mais rápido do que uma sessão a processar 500.

O mesmo padrão serve para qualquer operação em massa. Etiquetar tickets de suporte, categorizar páginas de documentação, normalizar registos de base de dados, processar ficheiros CSV. A chave é dividir por fronteiras de dados, não por função.

Padrões Para Equipas Não-Código

As Equipas de Agentes não são só para código. Qualquer coisa que beneficie de perspetivas paralelas e coordenação estreita está disponível. Os prompts abaixo cobrem investigação, conteúdo e estratégia de campanha.

7. Sprint de Investigação de Campanha

Create an agent team to research the launch strategy for [product].
Spawn three teammates:
- Competitor analyst: study competitor ad copy, positioning, and pricing
- Voice of customer researcher: mine reviews, Reddit threads, and forums
  for pain points and language customers actually use
- Positioning stress-tester: take findings from both teammates and
  pressure-test our current positioning against what they discover

Have them share findings and challenge each other. The lead synthesizes
a strategy document with positioning recommendations.

Porquê funciona: O investigador de concorrentes encontra lacunas de mercado. O colega de voz do cliente verifica se os compradores reais se importam com essas lacunas. O testador de posicionamento pega em ambos os inputs e tenta partir a sua mensagem com eles. Três perspetivas, uma síntese, o output de cada colega a alimentar os outros.

Compare com três sessões de investigação separadas. Ficaria com três relatórios independentes e depois passaria tempo a cruzá-los manualmente. As Equipas de Agentes fazem o cruzamento automaticamente através de mensagens entre agentes.

8. Build de Landing Page com Revisão Adversarial

Create an agent team to build the landing page for [offer].
Spawn three teammates:
- Copywriter: develop messaging, headlines, and body copy
- CRO specialist: design conversion structure, CTA placement, and flow
- Skeptical buyer: review everything as a resistant prospect, flag
  weak claims, missing proof, and friction points

Require plan approval before any implementation.

Porquê funciona: A aprovação do plano apanha direções más antes de queimarem ciclos. O revisor adversarial encontra falhas que os colegas focados na construção passam por cima. Os compradores reais são céticos. A sua equipa também deve ser.

A aprovação do plano é mais importante aqui porque texto de landing page é caro de reescrever. Apanhar uma proposta de valor fraca na fase de esboço demora minutos. Apanhá-la depois de uma build completa demora horas.

9. Exploração de Criativo de Anúncios

Spawn 4 teammates to explore different hook angles for [product].
Each teammate develops one direction with headline variations,
supporting copy, and a rationale for why the angle works.
Have them debate which direction is strongest.
Update findings doc with consensus and runner-up options.

Porquê funciona: Um agente a explorar sozinho ancora na primeira ideia decente. Quatro agentes a tentar ativamente superar-se uns aos outros produzem criativo battle-tested. A estrutura de debate significa que o ângulo vencedor sobreviveu a um desafio real, não ao monólogo interno de uma única sessão.

Este padrão produz ângulos que nenhuma sessão única teria explorado. Quando o colega #2 empurra de volta contra a abordagem do colega #1, o colega #1 muitas vezes refina o seu ângulo em algo mais forte em vez de o abandonar. A pressão competitiva eleva o piso de qualidade.

10. Pipeline de Produção de Conteúdo

Create a team for this week's content calendar.
Spawn three teammates:
- Researcher: identify search intent gaps and competitive opportunities
- Writer: draft content based on research findings
- Quality reviewer: run each piece through clarity, proof, and SEO checks

Chain tasks so the researcher finishes before the writer starts,
and the reviewer checks each piece before marking it complete.

Porquê funciona: Investigação paralela e gates de qualidade sequenciais. O investigador e o escritor podem sobrepor-se em peças diferentes enquanto o revisor apanha problemas antes de qualquer coisa ser publicada. QA integrado sem um processo de revisão separado.

O encadeamento de tarefas é o detalhe chave. Sem ele, os três colegas começam ao mesmo tempo e o escritor redige sem investigação em que se basear. Dependências de tarefas explícitas através da lista de tarefas partilhada impõem a ordem de execução correta. Para mais sobre encadeamento de tarefas entre agentes, veja os fluxos de trabalho assíncronos.

Uma Progressão de Três Semanas

Novo nas Equipas de Agentes? Comece simples e evolua. Saltar diretamente para um prompt de implementação com cinco colegas é receita para confusão. Esta progressão de três semanas constrói intuição para quando as equipas acrescentam valor e quando acrescentam overhead.

Semana 1: Investigação e Revisão

Escolha um PR que precisa de revisão. Ative as Equipas de Agentes, depois execute:

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings.

Três revisores, três perspetivas, uma revisão. Vai ver os colegas a trabalhar na lista de tarefas, a trocar resultados e a entregar conclusões. Baixo risco, muito aprendizado. Na pior das hipóteses, fica com uma revisão incompleta que termina manualmente.

Semana 2: Debugging com Debate

Pegue num relatório de bug e execute o padrão de hipóteses concorrentes:

Users report intermittent 500 errors on the checkout endpoint.
Spawn 3 teammates to investigate different hypotheses:
- One checking database connection pooling
- One investigating race conditions in the payment flow
- One analyzing server resource limits
Have them share findings and challenge each other's theories.

Isto ensina-lhe como a comunicação entre agentes funciona na prática. Observe como os colegas partilham evidências, como empurram de volta contra teorias fracas e como o consenso se forma. A lista de tarefas partilhada é onde a maior parte desta coordenação fica visível.

Semana 3: Implementação

Quando os padrões de coordenação parecerem naturais, tente uma build de funcionalidade com fronteiras de ficheiros claras:

Create an agent team to build the webhook system.
Assign directory-level ownership to prevent conflicts.
Use delegate mode for the lead.

Ao fim da terceira semana vai ter intuição para quando as equipas se pagam e quando uma sessão única ou abordagem de sub-agente é a melhor escolha. A maioria dos programadores descobre que as equipas funcionam melhor para tarefas que precisam de três ou mais fluxos de trabalho independentes com pelo menos alguma comunicação entre domínios.

O Que Realmente Funciona

Depois de dezenas de sessões de Equipas de Agentes, estes padrões mantêm-se em todos os fluxos de trabalho acima:

• Seja específico sobre os papéis: "um em segurança, um em desempenho" bate "revisores". Papéis vagos produzem trabalho vago.
• Defina fronteiras de ficheiros: Propriedade ao nível de diretório elimina conflitos de merge. Não negociável para tarefas de implementação.
• Inclua critérios de sucesso: "Reporte os resultados" ou "atualize o documento de decisão" dá a cada colega uma linha de chegada.
• Use o modo delegate para coordenação pura: Mantém o líder a não fazer o trabalho ele próprio. O trabalho do líder é síntese, não produção.
• Exija aprovação do plano para trabalho arriscado: Apanha direções más antes de queimarem tokens. Crítico para tarefas criativas e de implementação.
• Deixe os colegas argumentar: O atrito bate o acordo. Padrões de debate consistentemente superam os de procura de consenso.
• Mantenha o tamanho da equipa em 3-5: Mais colegas significa mais overhead de coordenação e maiores custos de tokens. Acima de cinco, o volume de comunicação consome o ganho do paralelismo.
• Faça o padrão corresponder à tarefa: Trabalho data-paralelo (classificação, processamento) divide por fronteiras de dados. Trabalho funcional (implementação de funcionalidades) divide por domínio. Trabalho avaliativo (decisões de arquitetura, criativo) divide por perspetiva.
• Acelere o líder com o modo rápido: Ative o modo rápido para o líder para coordenação mais ágil enquanto os colegas correm a velocidade normal para manter os custos baixos.

Para melhores práticas, resolução de problemas e limitações conhecidas, veja as Melhores Práticas das Equipas de Agentes. Para modos de display, gestão de custo de tokens e hooks de gates de qualidade, veja Controlos Avançados.

Estes prompts funcionam como estão para qualquer utilizador do Claude Code com as Equipas de Agentes ativadas. Comece com o prompt de revisão de código esta semana. O overhead é baixo, e cada prompt acima é um ponto de partida testado para um fluxo de trabalho que você já executa.