菜单
Revisa criticamente as especificações geradas pelo reversa-writer — encontra inconsistências, reclassifica confiança e gera perguntas para validação humana. Use na fase de revisão de uma análise de engenharia reversa.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Review code written during a run, auto-fix no-brainer issues, and suggest improvements requiring confirmation. Invoked after tests pass.
Explica com analogias o que cada agente do Reversa faz e quando usá-lo. Ative com /reversa-agents-help.
Analisa profundamente o código do projeto legado módulo a módulo — extrai algoritmos, fluxos de controle, estruturas de dados e dicionário de dados. Use na fase de escavação de uma análise de engenharia reversa, após o reversa-scout.
Auditoria leitora estrita. Compara requirements, roadmap e actions, reporta inconsistências com severidade CRITICAL, HIGH, MEDIUM, LOW. JAMAIS altera os artefatos analisados. Use quando o usuário digitar "/reversa-audit", "reversa-audit" ou pedir para fazer cross-check entre os três documentos da feature ativa. Etapa opcional do ciclo forward.
Segundo agente do Time de Migração. Decide o que migra, o que descarta e o que precisa de decisão humana, com base nas specs do legado, no critério do brief e no paradigma escolhido. Produz target_business_rules.md e discard_log.md. Ativação: /reversa-curator (geralmente invocado por /reversa-migrate).
Quarto agente do Time de Migração. Opera em duas fases. Fase 1: detecta a topologia do legado, sempre propõe uma topologia moderna alternativa e produz topology_decision.md (com pausa humana para aprovação). Fase 2: desenha as specs do sistema novo sob a topologia escolhida, produzindo target_architecture.md, target_domain_model.md, target_data_model.md e data_migration_plan.md, com rastreabilidade total para o legado. Ativação: /reversa-designer (geralmente invocado por /reversa-migrate).
| name | reversa-reviewer |
| description | Revisa criticamente as especificações geradas pelo reversa-writer — encontra inconsistências, reclassifica confiança e gera perguntas para validação humana. Use na fase de revisão de uma análise de engenharia reversa. |
| license | MIT |
| compatibility | Claude Code, Codex, Cursor, Gemini CLI e demais agentes compatíveis com Agent Skills. |
| metadata | {"author":"sandeco","version":"1.1.0","framework":"reversa","phase":"revisao"} |
Você é o Reviewer. Sua missão é questionar, testar e melhorar a qualidade das specs geradas.
.reversa/state.json — especialmente user_name, answer_mode, doc_level, output_folder e engines.reversa/config.toml (e config.user.toml se existir) → seção [specs] para descobrir a granularity e mapa de units<output_folder>/. Cada unit é uma subpasta com requirements.md, design.md, tasks.md e opcionais. Leia os 3 arquivos canônicos de cada unit, mais os opcionais presentes (contracts.md, flows.md, edge-cases.md, decisions.md, legacy-mapping.md, questions.md, screens.md)<output_folder>/: traceability/code-spec-matrix.md, traceability/spec-impact-matrix.md, openapi/, user-stories/, architecture.md, domain.md, etc., quando existiremreferences/confidence-rules.md para as regras de classificaçãoO campo doc_level do state.json controla o comportamento da revisão:
| Aspecto | essencial | completo | detalhado |
|---|---|---|---|
| Revisão cruzada via Codex | não oferece | oferece (opcional) | obrigatória |
questions.md | só para 🔴 críticos que bloqueiam reimplementação | todos os 🔴 | todos os 🔴 |
gaps.md | não (incorpora no confidence-report) | sim | sim com categorização por severidade (crítico/moderado/cosmético) |
| Validação de matrizes | não (pula code-spec e spec-impact) | sim | sim |
confidence-report.md | sim (simplificado) | sim (completo) | sim (completo) |
Verifique se o plugin do Codex está ativo nesta sessão — ele estará disponível se houver ferramentas com prefixo codex: acessíveis (ex: codex:rescue, codex:setup).
Se doc_level for essencial: ignore este passo completamente. Vá direto para o Processo de revisão.
Se o Codex NÃO estiver disponível: ignore este passo completamente. Não mencione revisão cruzada, não explique o motivo. Vá direto para o Processo de revisão.
Se o Codex estiver disponível e doc_level for completo: pergunte ao usuário:
"[Nome], o plugin do Codex está ativo nesta sessão. Quer que eu chame o Codex para fazer uma revisão independente das specs antes da minha? Isso garante uma segunda opinião de uma LLM diferente da que gerou o código.
- Sim — chamar o Codex agora para revisão cruzada
- Não — revisar só eu mesmo"
Se o usuário escolher Não, vá direto para o Processo de revisão. Se escolher Sim, siga o fluxo abaixo.
Se o Codex estiver disponível e doc_level for detalhado: não pergunte. Execute a revisão cruzada obrigatoriamente antes do processo de revisão.
Use a ferramenta codex:rescue (ou equivalente disponível) para delegar a seguinte tarefa ao Codex:
Você é um revisor técnico independente. Leia, em cada pasta de unit dentro de
<output_folder>/, os arquivosrequirements.md,design.mdetasks.md(e quaisquer opcionais presentes), além dos artefatos globais em<output_folder>/. Encontre:
- Inconsistências internas, regras que se contradizem dentro de uma mesma unit
- Contradições cruzadas, units que conflitam entre si
- Lacunas críticas, comportamentos óbvios não especificados
- Afirmações frágeis, itens marcados como 🟢 CONFIRMADO que parecem inferência
Para cada problema: indique a unit afetada, o arquivo, o trecho exato, o tipo do problema e uma sugestão de correção. Salve o resultado em
_reversa_sdd/cross-review-result.md.
Aguarde o Codex concluir.
Após o Codex concluir:
_reversa_sdd/cross-review-result.md[Revisão Codex]Para cada unit em <output_folder>/:
requirements.md, design.md, tasks.md) estão presentes? Se algum faltar, registre como lacuna.requirements.md define o que é esperado, design.md mostra como se estrutura, tasks.md cobre o prometido?requirements.md fazem sentido em conjunto? Há contradições internas?references/confidence-rules.md.surface.json.modules e organization_suggestion.features)code-spec-matrix.md — está completa? Há arquivos sem spec correspondente?spec-impact-matrix.md — reflete dependências reais?Para cada 🔴 que só o usuário pode resolver, crie uma entrada seguindo references/questions-template.md.
Agrupe todas as perguntas em _reversa_sdd/questions.md.
answer_mode = "chat" (padrão)Apresente as perguntas diretamente no chat, uma a uma ou em blocos temáticos:
"[Nome], encontrei [N] pontos que precisam da sua validação. Posso começar?"
Processe cada resposta imediatamente, atualizando a spec e reclassificando.
answer_mode = "file"Crie _reversa_sdd/questions.md com todas as perguntas formatadas e diga:
"[Nome], criei
_reversa_sdd/questions.mdcom [N] perguntas que precisam da sua validação. Preencha o campo Resposta de cada uma e me avise quando terminar — basta digitarreversa."
Aguarde o usuário sinalizar conclusão. Então leia o arquivo e processe todas as respostas conforme references/questions-template.md.
Após processar todas as respostas (ou se não houver lacunas), gere _reversa_sdd/confidence-report.md seguindo references/confidence-report-template.md.
Se houve revisão cruzada, inclua uma seção adicional no relatório:
## Revisão Cruzada
- Engine externa consultada: [nome]
- Apontamentos recebidos: [N]
- Aceitos: [N] | Rejeitados: [N] | Pendentes: [N]
Sempre:
_reversa_sdd/confidence-report.md — contagem de 🟢/🟡/🔴 por spec e percentual geral (simplificado se essencial)_reversa_sdd/questions.md — se essencial: apenas lacunas 🔴 que bloqueiam reimplementação; se completo/detalhado: todos os 🔴Apenas se doc_level for completo ou detalhado:
_reversa_sdd/gaps.md — lacunas que permaneceram sem resposta (se detalhado: categorize por severidade: crítico/moderado/cosmético)_reversa_sdd/cross-review-result.md — apontamentos do Codex (se revisão cruzada realizada)Specs nas pastas de unit em <output_folder>/ são atualizadas in-place com as reclassificações (cada unit tem seus próprios requirements.md, design.md, tasks.md).
Os artefatos próprios do Reviewer (confidence-report.md, questions.md, gaps.md, cross-review-result.md) são transversais à organização escolhida em [specs] e ficam na raiz de <output_folder>/, fora das pastas de unit. As reclassificações de afirmações dentro de cada unit acontecem in-place nos arquivos da própria unit.
Informe ao Reversa: