Planejamento e trabalho em equipeClaude Code and other supported coding agents

Jesse Vincent (obra) / subagent-driven-development

Como fazer um plano inteiro ser construído sem você intervir a cada tarefa?

Com um implementador novo e um revisor para cada tarefa, uma depois da outra, e só quatro motivos para parar.

O que vale lembrar

  1. As tarefas rodam em sequência. A skill descarta subagentes de implementação em paralelo porque eles entram em conflito.
  2. Toda tarefa precisa dos dois veredictos, aderência à especificação e qualidade do código, e a autorrevisão do implementador nunca substitui nenhum deles.
  3. O progresso fica num arquivo de registro dentro de um espaço de trabalho ignorado pelo git, porque a memória da conversa não sobrevive à compactação.
  4. Cada papel recebe um modelo escolhido de forma explícita: um rápido e barato para tarefas mecânicas e o mais capaz disponível para a revisão final do branch inteiro.

01O que muda na prática

Percorrer um plano longo num único contexto faz cada tarefa carregar a bagunça das anteriores. Aqui a sessão que coordena entrega cada tarefa a um implementador novo junto com a ficha da tarefa, extraída do plano, e depois passa o diff resultante a um revisor como arquivo, o que deixa o contexto dela livre para coordenar.

A execução também não fica esperando por você. Conflitos, ambiguidades e defeitos do plano são decididos na hora, com a especificação como autoridade final, e cada decisão vai para o registro junto com o custo de estar errada. No fim, essas decisões são reunidas na última mensagem, para você encontrar e desfazer as que não aprovar.

02Onde decepciona

Não sai barato. Pela própria skill, ela custa um contexto novo por tarefa e por revisão, enquanto a execução inline custa um contexto e um revisor final, e uma tarefa que continua reprovando pode chegar a cinco rodadas de correção antes que os achados ainda abertos sejam deixados de lado com uma decisão registrada.

Ela também depende de um plano bom. Tarefas muito acopladas ficam fora do escopo, e decisões tomadas sem uma especificação acessível valem como provisórias, então um plano vago vira uma série rápida de decisões que você vai ter que conferir depois.

Instalação e primeira execução

  1. Instale o superpowers a partir de obra/superpowers, sob licença MIT. A skill traz o SKILL.md com modelos de prompt para o implementador e os revisores, sete arquivos de referência e três scripts de bash.
  2. Tenha o plano escrito antes de começar e trabalhe num worktree isolado. A skill não começa a implementar em main ou master sem o seu consentimento explícito.
  3. Conte com ela indo até o fim. Ela só para diante de uma operação irreversível ou destrutiva, uma ação sensível à segurança, um efeito fora do worktree como um push ou uma publicação, ou um plano tão quebrado que qualquer caminho seria chute.

Perguntas que as pessoas realmente fazem

Ela roda subagentes em paralelo?
Não. Os implementadores trabalham uma tarefa por vez, e a skill proíbe disparar vários subagentes de implementação ao mesmo tempo porque eles entram em conflito. Problemas sem relação que podem ser atacados simultaneamente são o terreno do dispatching-parallel-agents.
Qual a diferença para executing-plans?
As duas rodam o plano na sessão atual, compartilham o mesmo espaço de trabalho e o mesmo registro e nunca pausam entre tarefas. executing-plans faz todas as tarefas num só contexto, com um único revisor no fim; esta skill usa um subagente novo e uma revisão para cada tarefa.
O que acontece quando uma revisão encontra problemas?
Começa um ciclo de correção. Nas três primeiras rodadas o mesmo implementador é retomado, na quarta e na quinta assume um novo com um modelo mais capaz, e o que continuar aberto é deixado de lado com uma decisão anotada no registro. Achados menores não entram no ciclo e esperam a revisão final.

Fontes

  1. obra/superpowers no GitHubrepository
  2. Diretório de agent skillsdirectory
  3. obra/superpowers, pasta da skill subagent-driven-developmentdocumentation

Versões legíveis por máquina desta página