Use o /dr:execute quando o plano está pronto e você quer a entrega inteira, não só o código. Você aponta a task, o comando monta a equipe de agentes, implementa, revisa o que foi feito, atualiza a documentação e deixa as instruções de deploy escritas. É a execução completa, da qual o /dr:fast-execute é a variante rápida.
O nome da task planejada, o mesmo que o /dr:plan mostrou ao gravar o plano. Confira o plano antes de rodar: tudo o que estiver no checklist será construído e commitado na branch da task.
Antes de qualquer agente começar, o comando prepara o terreno. Ele cria ou troca para a branch sugerida no plano e confere se a sua árvore está limpa. Se houver alterações não commitadas, ele para e pede para você fazer commit ou stash primeiro.
Depois ele estuda o plano para decidir quem pode trabalhar junto. Tarefas que não dividem arquivos nem dependem umas das outras vão para agentes em paralelo. As que tocam os mesmos arquivos rodam em sequência, e as que dependem de outra esperam a sua vez e são despachadas assim que ela termina. Antes de começar, o comando mostra essa organização: arquivos envolvidos, dependências e grupos de execução.
Cada agente usa o especialista escolhido no planejamento, lê o plano por conta própria, segue os style guides da tecnologia em que está trabalhando, revisa o próprio código ao terminar e faz o commit da sua parte.
Quando todos terminam, o ciclo fecha sozinho em quatro etapas. Uma revisão de qualidade passa por todo o código implementado, corrigindo o que encontrar: desempenho, segurança, duplicação, nomes, tratamento de erros. Uma segunda revisão confere a aderência aos style guides e corrige as violações. Em seguida, a documentação do projeto é atualizada, ou criada, para cada funcionalidade tocada. Por fim, o comando escreve as instruções de deploy da task.
Uma branch com o trabalho commitado, já revisado em qualidade e estilo, a documentação do projeto em dia com o que mudou e um arquivo de instruções de deploy com os passos na ordem certa: o que a sua esteira de CI/CD faz sozinha, para você só acompanhar, e o que precisa ser rodado à mão, com os comandos prontos.
Na prática, o que seria “implementar, depois lembrar de revisar, depois documentar, depois descobrir como publicar” sai numa única rodada, com cada etapa feita por quem é especialista nela.
Como utilizar
/dr:execute aceita texto livre. Você descreve o que quer em linguagem natural e o comando resolve. Não há flags.
Exemplos
/dr:execute migrar-autenticacao-jwt
/dr:execute modulo-relatorios
Na ambiguidade
Se a sua frase pode ser interpretada de mais de uma forma, o comando pergunta antes de escrever (via AskUserQuestion). Em operação de escrita, o comando nunca chuta — a ambiguidade sempre volta para você.
Notas
O argumento é o nome da task, o slug da pasta em .dr_ai/tasks/. A variante /dr:fast-execute (o próximo passo sugerido pelo /dr:plan) executa em lotes, aceita IDs de tarefa como segundo argumento e não roda as etapas finais de revisão, documentação e deploy nem faz commits. /dr:execute:workforce executa uma task ou feature do Workforce de ponta a ponta.
Para quem quer saber o que acontece nos bastidores:
- Entrada: a pasta
.dr_ai/tasks/<nome>/, com __TaskPlan.md e __TaskChecklist.json gerados pelo /dr:plan. A branch sugerida vem da tarefa T0 do checklist, e só as tarefas pendentes são despachadas.
- Grupos de execução: derivados da seção de arquivos a criar ou alterar de cada tarefa no
__TaskPlan.md e das dependências declaradas. Cada agente usa o atribuído no checklist; sem atribuição, o padrão é dr:python-implementation para Python e dr:nodejs-implementation para o resto.
- Revisões: o
code-analyst faz a revisão de qualidade e, depois dele, o task-style-checker valida os arquivos modificados contra os style guides de ~/.claude/style-guides/.
- Documentação: o
tech-doc-writer (ou o project-doc-writer, para funcionalidades não técnicas) atualiza ou cria um documento por funcionalidade tocada, no diretório de documentação do projeto e no idioma de .dr_ai/settings.json.
- Deploy:
deploy_instructions.md, na pasta da task, lista os passos a partir do que mudou (backend, frontend, migrações, funções, infraestrutura, variáveis de ambiente) e marca como automático o que a esteira de CI/CD já cobre.
- Rastro: o progresso fica em
context_session.md dentro da pasta da task, com o status de cada tarefa atualizado no checklist.
