Do squad instalado à operação autônoma
Roteiro de 90 dias pra sair de "instalei o squad" pra "código de produção com quality gate aprovado, security audit fechado e performance dentro dos SLOs". Cada fase com objetivo, métrica e entregável.
Primeiros 30 dias · dominar o pipeline
Cada feature passa pelo chief, cada PR pelo @qa-expert, cada deploy pelo /eng-deploy-check. Sem exceção.
Instale global em ~/.claude/, confirme os 36 agentes carregados (inclui o novo vps-operator) e implemente 1 feature simples — um CRUD, uma página com form.
Três features de complexidade crescente com os 13 hooks ligados. Observe quanta dor eles evitam no caminho.
Rode /eng-security-audit e /eng-perf-audit em código existente, leia os relatórios e aplique 3 correções de cada.
Force um erro em staging, rode /eng-incident-triage, mitigue, escreva o RCA e o postmortem blameless.
Dias 31–60 · eficiência operacional
Sair do "uso o squad pra tudo" pro "uso o squad onde gera ROI alto". Aprender quando vale skip ceremony e quando vale o pipeline completo.
Pegue uma tarefa grande com 3+ partes independentes e use o fan-out nativo de Tasks (workflow eng-research-fanout). Aprenda file ownership boundaries — zero conflito de merge.
Crie 1-2 rules do seu projeto ("todo endpoint /api/* tem rate limit", "toda migration explica o porquê") e adicione em ~/.claude/rules/.
Dias 61–90 · autonomia
Você não consulta mais a documentação do squad — você ensina alguém. E customiza pro seu domínio.
Crie 2-3 contextos pré-carregados pras áreas frequentes do seu produto: checkout flow, auth system, billing.
Documente o workflow específico do time (incident em horário comercial vs fora, protocol de feature flag) e adicione em workflows/.
Monte o painel: features aprovadas no gate, incidentes evitados pelo security-scan, queries otimizadas. ROI mensurável.
Métricas de progresso
| Marco | Quando | Sinal de que está no caminho |
|---|---|---|
| Primeira feature com pipeline completo | dia 1–7 | /eng-code-quality-gate aprovado |
| Hooks ativos em projeto real | dia 14 | 0 secrets no git, 100% commits conventional |
| Primeiro security audit fechado | dia 21 | 0 vulnerabilidades CRITICAL/HIGH |
| Primeiro postmortem blameless | dia 30 | doc com root cause + action items |
| Multi-agent paralelo dominado | dia 45 | 1 feature grande na metade do tempo |
| Rules e contextos customizados | dia 75 | 2+ rules próprias enforcadas |
| Operação autônoma | dia 90 | time inteiro usando o squad sem te chamar |
Erros comuns por fase
Chamar specialist sem chief
Sintoma: code review reprovando entregas. Causa: pulou o quality gate. Correção: sempre @engineering-chief primeiro.
Paralelizar tudo
Sintoma: race conditions e conflito de merge. Causa: paralelizou tarefa com dependência. Correção: só paralelize partes independentes, com file ownership claro.
Over-customizar
Sintoma: rules contraditórias, agentes em loop. Causa: adicionou rules sem testar interação. Correção: teste cada rule isolada antes de combinar.
Frameworks aplicados
Building Effective Agents (Anthropic), Agentic Patterns (Andrew Ng), papers de AI engineering — entender os porquês dos workflows.
Multi-LLM strategy
Opus 5 pra triage e raciocínio pesado, Sonnet 5 pra implementação e checks rápidos. Roteie por complexidade via /eng-llm-route.
Compartilhar customizações
Leve rules, skills e workflows pro grupo da mentoria — validados com o validador-gate + sync-global — e audite o squad de outro membro.