Use o /dr:review:task depois de uma execução, antes de publicar. Você aponta a task, e o comando confere se o que mudou no repositório é o que o plano prometia, e se o que mudou está bem feito. Você recebe os problemas encontrados, organizados por severidade, e decide o que corrigir. Nada é alterado sem a sua escolha.
O nome da task, o mesmo usado no /dr:plan e no /dr:execute. Se a task não existir, o comando lista as disponíveis e para.
O comando começa delimitando o terreno. Ele compara os arquivos que o plano previa com os que de fato mudaram no git e classifica cada um: esperado, inesperado ou ausente. É essa lista que os revisores recebem.
Em seguida, seis revisores analisam o trabalho ao mesmo tempo, cada um por um ângulo: se o escopo foi respeitado, se os critérios de aceite foram atendidos, a qualidade do código, a aderência aos style guides e aos padrões do próprio projeto, a segurança e a performance. Cada apontamento vem com arquivo e linha como evidência, nunca uma impressão solta.
Com os resultados consolidados, o comando mostra uma tabela com a contagem de problemas por severidade e pergunta o que você quer corrigir: críticos e maiores (a recomendação), todos, só os críticos, nenhum, ou uma seleção sua em texto livre. As correções escolhidas vão para especialistas na tecnologia de cada arquivo, e só então o código é tocado.
Um relatório objetivo, salvo no projeto, com contagens e tabelas planas: arquivo, linha, severidade e uma linha de descrição por problema, sem narrativa. E, se você escolheu corrigir, o código ajustado nos pontos selecionados.
Na prática, a revisão que dependeria de alguém com tempo e contexto vira seis olhares simultâneos, com evidência em cada apontamento e a decisão final ainda sua.
Como utilizar
/dr:review:task aceita texto livre. Você descreve o que quer em linguagem natural e o comando resolve. Não há flags.
Exemplos
/dr:review:task migrar-autenticacao-jwt
/dr:review:task modulo-relatorios --yes
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 em .dr_ai/tasks/. Com --yes (ou o alias legado --fix), correções críticas e maiores são aplicadas sem a pergunta de confirmação, e o verificador de estilo já corrige sozinho as violações mecânicas. Roda com modelo opus.
Para quem quer saber o que acontece nos bastidores:
- Escopo: os arquivos planejados vêm de
__BatchMeta.json (quando existe) ou da seção de arquivos de cada tarefa em __TaskPlan.md; os reais, de git diff --name-status e git status --porcelain. Artefatos gerados, lockfiles e código vendorizado são ignorados.
- Os seis agentes:
task-scope-validator, task-criteria-validator, task-quality-reviewer, task-style-checker (que também lê os padrões do projeto em quality.standards_dir, padrão .dr_ai/docs/standards), code-security-analyzer e code-performance-analyzer, despachados em uma única mensagem.
- Relatório:
.dr_ai/code-reviews/task-review_<task>_<timestamp>.md. A pasta respeita directories.code-reviews; idioma e formato seguem user.language e preferences.output_style de .dr_ai/settings.json. O nível de detalhe é sempre mínimo, independentemente de preferences.verbosity.
