Use o /dr:implement quando você quer o código feito, seja uma funcionalidade nova ou uma mudança no que já existe. Você descreve o pedido, e o comando ajusta o tamanho do processo ao tamanho do trabalho: uma troca de texto é feita na hora, sem cerimônia; um módulo novo passa por planejamento, implementação por especialistas e uma revisão ao final.
O que você quer, em linguagem natural: “sistema de autenticação de usuários”, “paginação no endpoint de usuários”, “trocar o texto do estado vazio na tela de pedidos”. Se quiser, indique o especialista que deve implementar, peça testes junto, ou force o caminho curto ou o completo quando já souber o tamanho da mudança.
A primeira coisa que o comando faz é medir o pedido, só pelo que você escreveu. Mudanças pequenas e bem delimitadas, como um texto de tela, um item a mais num filtro ou um ajuste em um ou dois arquivos que espelha o código ao redor, seguem o caminho direto: ele lê os arquivos envolvidos, faz a alteração seguindo o padrão vizinho, roda o typecheck e o lint e te mostra o que mudou. Se no meio do caminho a mudança se revelar maior, ele para, lista o que já editou e passa ao caminho completo, levando essas alterações junto. Na dúvida, vale o completo.
No caminho completo, o comando começa estudando o seu código: a stack, as convenções, os módulos que o pedido toca e tudo o que depende do comportamento que vai mudar. Com isso, desenha a implementação, comparando alternativas quando há uma escolha real, e divide o trabalho em pacotes que não compartilham arquivos. Quando uma decisão depende de uma informação que só você tem, ele não chuta: devolve a pergunta, espera a sua resposta e planeja de novo.
Cada pacote vai para um agente especialista, em paralelo quando não há dependência entre eles. Ao terminar, cada agente declara o que fez e se concluiu, e o comando confere as mudanças reais contra o que foi declarado, para que nada passe sem dono. Se você pediu testes, especialistas de teste os escrevem e rodam em seguida. Por fim, um revisor faz uma única passada: corrige o que é barato de corrigir e registra o que merece outra rodada.
O código implementado no seu projeto, sem commit, e um relatório do que foi feito. No caminho completo, o relatório traz o plano que guiou o trabalho, o status de cada pacote, os testes rodados e as pendências da revisão, com o /dr:fix como próximo passo quando sobrar algo.
Na prática, o pedido de uma frase vira um trabalho dividido entre especialistas, com o cuidado de nunca dois deles editarem o mesmo arquivo e com uma revisão já feita antes de você abrir o diff.
Exemplos
/dr:implement sistema de autenticação de usuários
/dr:implement dashboard de vendas --agent react-architect
/dr:implement paginação no endpoint de usuários --with-tests
/dr:implement trocar o texto do estado vazio na tela de pedidos --direct
Argumentos
| Argumento | Obrigatório? | Descrição |
|---|
description | Sim | What to implement or change |
--agent <agent-name> | Não | Force the implementation specialist (recommended by the planner otherwise). In Direct Mode, it names the specialist the change is delegated to |
--full | Não | Force the Full Pipeline, even for a request the Complexity Gate would classify as Direct Mode |
--direct | Não | Force Direct Mode, skipping the Full Pipeline regardless of the gate's judgment |
--with-tests | Não | Run the test phase after the implementation, with test specialists (Full Pipeline only) |
--no-review | Não | Skip the review pass. Use only for throwaway or trivial code (Full Pipeline only) |
Notas
Sem --agent, o especialista é recomendado pelo plano; com --agent, todo o trabalho vai para um único pacote desse agente (no modo direto, a alteração é delegada a ele). --full força o pipeline completo e --direct força o modo direto, qualquer que seja o julgamento do filtro; os antigos --checklist e --no-checklist ainda funcionam como apelidos obsoletos dessas duas. --full junto com --direct faz o comando perguntar qual vale. --with-tests inclui a fase de testes e --no-review pula a revisão (as duas só valem no pipeline completo; no modo direto são ignoradas com aviso no relatório).
Para quem quer saber o que acontece nos bastidores:
- Filtro de complexidade: o julgamento entre modo direto e pipeline completo é feito só pelo texto do pedido, sem ler o código. No modo direto não há pasta de task, plano nem revisão.
- Artefatos: o pipeline completo registra o
git status antes de começar e grava tudo em .dr_ai/tasks/<nome>/ (um nome já usado ganha o sufixo -2, -3): __ImplementSummary.md com o pedido, as flags e o resultado, e __ImplementPlan.md com o plano. Os artefatos e o relatório seguem o idioma de user.language em .dr_ai/settings.json.
- Planejamento: o
code-architect analisa o código e escreve o plano, com os pacotes de trabalho, seus arquivos e o especialista recomendado para cada um, escolhido no catálogo de agentes do plugin. Decisões que bloqueiam o plano voltam como perguntas em aberto.
- Implementação: um agente por pacote, com status final
DONE, PARTIAL ou BLOCKED. Um pacote cuja dependência terminou bloqueada é pulado e reportado. As mudanças reais no git são comparadas com o que cada pacote declarou, e o que ninguém declarou segue para a revisão.
- Revisão: o
code-analyst faz uma única passada, sem loop. O que não corrige fica em __ImplementReview.md.
- /dr:plan — planejar antes, sem tocar no código
- /dr:execute — executar um checklist já planejado
- /dr:debug — quando o trabalho é investigar um problema, não construir ou alterar
