Spec Kit subagents: orquestração por fases

Uma janela de contexto de 200 mil tokens não sobrevive a uma feature inteira implementada numa conversa só. Ao distribuir as tarefas do Spec Kit entre spec kit subagents, cada agente trabalha com um recorte pequeno de contexto, e você ganha paralelismo real entre backend e frontend.

O que é o GitHub Spec Kit e onde ele entra no seu fluxo

O GitHub Spec Kit é o kit de ferramentas open source do GitHub para aplicar spec-driven development com agentes de IA. Em 2025, o GitHub popularizou essa abordagem: você escreve a especificação antes do código, e o agente implementa a partir dela.

No fluxo descrito por Felipe Rocha, do canal Full Stack Club, em vídeo publicado em julho de 2026, a pasta de specs reúne o plano, a spec (que funciona como uma PRD), as tarefas numeradas, o quickstart e a estrutura de dados. Com tudo pronto, você roda o comando de implementação e o agente executa as tarefas.

Rocha também usa o Claude Code, a ferramenta de codificação agêntica da Anthropic que roda no terminal, e cita o Cursor, editor de código com IA, como alternativa para quem trabalha com o mesmo fluxo.

Por que implementar tudo de uma vez quebra o agente

O problema central aparece quando todas as tarefas estão prontas para implementação. Por padrão, o Spec Kit tenta executar tudo em uma única conversa, dividindo o trabalho em fases sequenciais dentro do mesmo contexto.

Segundo a experiência relatada por Rocha, isso gera três efeitos ruins: a janela de contexto cresce até o agente começar a alucinar, o custo da conversa sobe e o tempo de conclusão aumenta. Para features pequenas, uma conversa única até funciona; para projetos reais, não.

O paliativo era manual: pedir algo como "implement from phase 1 to phase 3" e, ao terminar, voltar e pedir a próxima fatia. Quem mantém vários projetos ou várias features paralelas sabe que ficar religando o agente a cada fase vira gargalo.

Como a orquestração de spec kit subagents funciona por fase

A solução edita a skill implement do Spec Kit para orquestrar subagents por fase. Cada fase do plano tem suas tarefas numeradas (T01, T02, T03...), e a skill passa a agrupar essas tarefas por dono antes de executar qualquer coisa.

O fluxo dentro de cada fase segue quatro passos claros:

1. Ler as tarefas da fase e separá-las em dois grupos: o que mexe no backend e o que mexe no frontend.
2. Definir, fase a fase, o que é paralelizável e o que precisa ser sequencial.
3. Chamar um subagent de backend engineer e/ou um subagent de frontend engineer com seus grupos de tarefas.
4. Reconciliar o trabalho: marcar cada tarefa como concluída e fazer o commit da fase.

Se as tarefas de frontend dependem do backend, o backend engineer roda primeiro e o frontend entra depois da conclusão. Se não há bloqueio, os dois subagents rodam ao mesmo tempo. Com dez fases, por exemplo, o fluxo chega a acionar cerca de vinte subagents ao longo da feature.

O ganho de contexto é direto: cada subagent roda com uma janela própria, na ordem de 200 mil tokens conforme o exemplo dado no vídeo. Nada disso é alegação oficial da Anthropic do GitHub; é a configuração descrita pelo autor do fluxo, que prefere o modelo Sonnet nos subagents porque os documentos já estão bem estruturados e não exigem raciocínio profundo.

Code review com agente dedicado após todas as fases

Depois que os subagents terminam, você pode acionar um terceiro agente de code review, preferencialmente com um modelo de raciocínio mais alto, como o Opus. Ele recebe as mudanças de ambos os engineers e gera um relatório salvo na pasta da spec.

O relatório prioriza as sugestões em quatro níveis, o que torna a decisão humana mais rápida:

Prioridade	Tratamento esperado
Critical	Atenção imediata antes do merge
High	Correção na mesma sprint
Medium	Ajuste quando conveniente
Low	Fica para refino futuro

Rocha recomenda rodar o review uma única vez, após todas as fases, e não a cada fase concluída. Os motivos são dois: revisar a cada fase deixaria o processo lento, e um código revisado na fase 1 tende a mudar até a fase 3. O passo humano de decidir o que aplicar permanece fora da automação.

Ele também treina o agente de review com o tempo: quando algo simples aparece classificado como crítico, você corrige a expectativa e o agente aprende a calibrar as prioridades.

Como editar a skill implement na prática

Você não precisa escrever a skill à mão. No vídeo, Rocha dita as instruções para o próprio Claude Code, o que ele considera mais rápido do que digitar. O pedido resume o contrato da skill: para cada fase, definir o que é paralelizável e chamar backend engineer e frontend engineer para as tarefas respectivas.

No resultado editado, o backend engineer cuida de tudo que toca a pasta src/server, onde ficam casos de uso, drivers e repositórios. O frontend engineer assume os componentes React. A skill também ganhou um passo de commit por fase, o que mantém o histórico versionado conforme as fases avançam.

Com isso, o autor relata que consegue deixar os agentes implementando uma feature enquanto trabalha com mais calma em outra, rodando tudo em paralelo. É ele quem afirma o resultado; não há benchmark independente do fluxo.

Perguntas frequentes sobre spec kit subagents

• Preciso trocar de ferramenta para usar subagents? Não. O fluxo foi desenhado dentro do Claude Code com o GitHub Spec Kit, e a lógica de orquestração por fases também se aplica a outros agentes de desenvolvimento com suporte a subagents.

• Vale usar um modelo maior nos subagents de implementação? O autor usa o Sonnet nos subagents porque as especificações já guiam a implementação, e reserva um modelo de raciocínio mais alto para o code review. Você pode ajustar conforme o custo e a complexidade do seu projeto.

• O code review pode rodar a cada fase? Pode, mas o autor desaconselha: o processo fica demorado e o código de fases iniciais costuma mudar nas fases seguintes. Revisar uma vez, ao final, costuma ser mais eficiente.

• Esse fluxo elimina a revisão humana? Não. O agente gera o relatório priorizado, mas quem decide o que aplicar continua sendo você, com base nas prioridades critical, high, medium e low.

• O Spec Kit só funciona com o Claude Code? Não. O GitHub Spec Kit foi desenhado para funcionar com múltiplos agentes de codificação com IA; o vídeo usa o Claude Code como ambiente, mas não afirma exclusividade.

Do vídeo ao artigo: transforme seu fluxo em conteúdo escrito

A lição deste fluxo é que organizar o trabalho por fases e donos vale tanto para agentes de IA quanto para o seu próprio conteúdo: dividir, priorizar e revisar antes de publicar. Se você explica arquitetura, ferramentas ou processos em vídeos, como os do Full Stack Club e iniciativas ligadas ao Crazystack, como o Crazystack Typescript e o Bootcamp do Dev Doido associados ao Gustavo Dev Doido, esse conhecimento merece uma versão escrita bem estruturada.

Com o Skala Blog, você cola a URL de um vídeo do YouTube, gera a transcrição e produz um artigo completo pronto para revisão — o mesmo caminho que deu origem ao texto que você acabou de ler.

Source video