Verificando acesso...

MÓDULO 2.2

📝 Anatomia do prompt de spawn

Goal → Team → Roles → Final deliverables — o template canônico em 4 blocos.

6
Tópicos
55
Minutos
Intermediário
Nível
Mão na massa
Tipo
1

🎯 Bloco 1: Goal

Frase única que descreve o objetivo final do time, não o passo-a-passo. Teammates acordam sem contexto; o Goal dá norte para decisões locais.

📌 Goal eficiente vs ineficiente

Goal observável tem critério de aceite embutido.

  • ✓ 'app rodando em localhost:3000 com login'
  • ✗ 'fazer um app legal'
  • ✓ 'pull request mergeable até sexta'
  • ✗ 'ajude com o projeto'

💡 Regra de ouro

Se você não sabe quando o time terminou só lendo o Goal, ele está vago demais.

2

👥 Bloco 2: Team (N + modelo)

Especifique quantos teammates e qual modelo padrão. Sem N explícito o lead chuta. Sem modelo, default herda do lead — pode ser caro demais.

📊 Mix de modelos por papel

  • Tech Writer / docs → Haiku
  • Dev padrão → Sonnet
  • Architect / decisão → Opus
  • QA simples → Haiku, complexo → Sonnet

📌 Nomeando o time

Nome próprio facilita auditoria e resume.

  • ✓ 'Create a team called Neuroflow with 3 teammates'
  • ✓ 'Spawn the backend_review squad'
  • ✗ 'Crie uns agentes'
3

🎭 Bloco 3: Roles

Cada role tem 3 campos no prompt: o que faz, o que entrega, e para quem manda mensagem ao terminar. Sem destinatário explícito, todos voltam ao lead.

📌 Template de role

Estrutura repetível.

  • Papel: Backend Dev
  • Faz: API REST em src/api/
  • Entrega: rotas /users e /posts funcionando
  • Quando termina: mande contrato para Frontend Dev

⚠️ Erro comum

Esquecer o 'destinatário'. Sem ele, todos retornam ao lead, eliminando vantagem do mailbox.

4

📦 Bloco 4: Final deliverables

Lista explícita de artefatos: app rodando, tests/report.md, docs/build-summary.md. Sem isso, time pode encerrar com trabalho parcial.

📌 Deliverables observáveis

Path + formato + critério de aceite.

  • tests/report.md com lista pass/fail
  • ✓ App acessível em localhost:3000 sem erros
  • docs/build-summary.md com decisões
  • ✗ 'um relatório do trabalho'

💡 Executável > documentação

Sempre inclua um deliverable que possa ser rodado ou aberto, não só lido.

5

📐 Templates reutilizáveis

Mantenha prompts versionados em prompts/. Times bem desenhados são reutilizáveis. Salvar bons prompts vale ouro — escala para o time todo.

📌 Estrutura de prompts/

Catalog de spawns por situação.

  • prompts/spawn-fullstack.md
  • prompts/spawn-pr-review.md
  • prompts/spawn-debug-hypothesis.md
  • prompts/spawn-incident-response.md

💡 Versionamento

Cada prompt tem changelog próprio. Pequenas mudanças trazem ganho ou regressão — saiba qual.

6

🧪 Refactor: vago → cirúrgico

Lab: pegue um prompt vago e transforme em prompt de 4 blocos com roles e deliverables claros. Treina o olho — depois você corrige no automático.

✓ Versão cirúrgica

  • Goal observável
  • N e modelo definidos
  • Cada role tem destinatário
  • Deliverables com path

✗ Versão vaga

  • 'Faça uma equipe pra ajudar'
  • 'uns agentes'
  • 'alguém revisa no final'
  • 'me dê o resultado'

📌 Resumo do Módulo

Bloco 1: Goal — O 'porquê' antes dos 'quem'
Bloco 2: Team (N + modelo) — Tamanho e modelo importam
Bloco 3: Roles — Papel + entrega + destinatário
Bloco 4: Final deliverables — Como sei que terminou
Templates reutilizáveis — Salvar prompts que funcionam
Refactor: vago → cirúrgico — Antes/depois lado a lado

Próximo módulo:

2.3 — Faça vs Não Faça