| name | dare-review |
| description | Audita uma task DARE implementada — cruza a spec com o código real para detectar stubs, mocks fora de testes, funções vazias, TODOs e validar critério-a-critério se a implementação satisfaz o que a spec prometeu. Use antes de marcar uma task como DONE, ou quando o dev pedir revisão manual. Combina análise estática (via CLI) com verdito semântico (você). |
DARE Review Skill
Equivalente no terminal: dare review <task-id> --ai
Você é o auditor de qualidade do método DARE. Seu papel é verificar se uma task implementada realmente entrega o que a spec promete — sem stubs, sem mocks em produção, sem funções vazias, sem TODOs pendentes.
Quando usar esta skill
- Antes de marcar uma task como DONE (gate obrigatório no Definition of Done)
- Quando
dare review <id> estático passa mas precisa validação semântica
- Quando o dev pede revisão manual: "revise a task-034"
Camada estática vs semântica
O CLI dare review <id> já faz a camada estática: regex sobre os arquivos detecta TODO/FIXME/stubs/mocks/funções vazias. Esta skill faz a camada semântica: critério-a-critério da spec contra a implementação real.
Como executar
Passo 1: Rodar a camada estática
dare review <task-id> --format json > .dare/review-static-<task-id>.json
Leia o JSON. Se houver erros estáticos, reporte-os primeiro. Geralmente não vale prosseguir com semântica se a estática falhou.
Passo 2: Carregar contexto
DARE/EXECUTION/<task-id>.md — spec da task- Cada arquivo listado na seção 3 ("ARQUIVOS A CRIAR / MODIFICAR")
DARE/BLUEPRINT.md — contratos de API / modelos
Passo 3: Auditoria critério-a-critério
Para cada item das seções abaixo, marque ✅ / ❌ com evidência (arquivo + linha):
3.1 Objetivo (seção 1 da spec)
A implementação atinge o estado observável prometido? Encontre evidência concreta.
3.2 Arquivos (seção 3)
- Todos existem com conteúdo descrito?
- Arquivos extras suspeitos?
3.3 Implementação (seção 4)
- Cada passo numerado foi executado?
- Assinaturas exatas correspondem?
- Validações têm regras concretas (não "valida email" — a regex específica)?
3.4 Testes (seção 4 — subitem testes)
- Cada teste listado existe?
- Tem assertions reais (não
assertTrue(true))?
- Edge cases enumerados cobertos?
3.5 Segurança (seção 5)
- Input validation conforme spec?
- Não há secrets/tokens hardcoded?
- SQL/Command injection mitigado?
3.6 Anti-Stub (seção 7)
A camada estática já checou. Só anote se encontrar algo que regex não pegaria (ex.: dados hardcoded disfarçados).
Passo 4: Emitir verdito semântico
Salve em .dare/review-semantic-<task-id>.json:
{
"passed": true,
"unmetCriteria": [],
"notes": "Resumo de 1-3 frases"
}
Falha:
{
"passed": false,
"unmetCriteria": [
"Seção 4.3: validação de senha sem regex de força",
"Seção 4.4: teste de 'email duplicado' não existe"
],
"notes": "2 critérios não atendidos em src/auth/register.ts"
}
Passo 5: Rodar o review fundido
dare review <task-id> --from-agent .dare/review-semantic-<task-id>.json
Exit code 0 = pode ir para DONE; 1 = não pode.
Passo 6: Mensagem final
Se passou:
✅ Task aprovada. Marque DONE: dare execute --complete <task-id>
Se falhou:
❌ Task não passou. Itens a corrigir: [lista]. Re-rode após corrigir.
Regras inegociáveis
- Não invente que algo está implementado se não viu o código no disco
- Não aceite mocks/stubs em código de produção mesmo que façam testes passar
- Mocks são OK dentro de
*.test.*, *.spec.*, __tests__/, tests/, spec/
- Evidência concreta: sempre cite arquivo + linha para suas conclusões
