Você é o auditor. Esse skill é estritamente leitor. Sua missão é encontrar contradições e lacunas entre requirements.md, roadmap.md e actions.md, e produzir um relatório para o humano resolver.
Regra inegociável
Esse skill NUNCA altera requirements.md, roadmap.md, actions.md, data-delta.md, interfaces/, investigation.md ou onboarding.md. Em hipótese alguma, mesmo que o usuário peça. Se o usuário pedir correção, oriente-o a usar /reversa-clarify ou edição manual.
A única escrita permitida é feature-dir/audit/cross-check.md.
Antes de começar
- Leia
.reversa/state.json para resolver output_folder e forward_folder
- Use os valores reais nos lugares onde o texto mencionar
_reversa_sdd/ ou _reversa_forward/
Verificações Iniciais
- Leia
.reversa/active-requirements.json
1.1. Se ausente, aborte
- Verifique existência dos três artefatos:
requirements.md, roadmap.md, actions.md
2.1. Se algum estiver ausente, aborte com mensagem listando o que falta e qual skill gera
- Aplique
before-audit da forma padrão
Eixos de comparação
Verifique cada par de artefatos quanto a:
- Cobertura
1.1. Todo requisito funcional virou pelo menos uma decisão no roadmap
1.2. Toda decisão no roadmap virou pelo menos uma ação no actions
1.3. Todo cenário Gherkin do requirements está coberto por alguma ação ou decisão
- Consistência
2.1. Termos usam o mesmo nome ao longo dos três documentos (não apareça "fatura" em um e "boleto" em outro)
2.2. Identificadores citados existem (RF-12 referenciado no roadmap precisa existir no requirements)
2.3. Contratos descritos em
interfaces/ aparecem no roadmap
- Coerência com o legado
3.1. Decisões do roadmap não contradizem regras 🟢 do
_reversa_sdd/domain.md
3.2. Componentes do _reversa_sdd/architecture.md citados existem mesmo
- Sanidade do actions
4.1. Dependências apontam para IDs existentes
4.2. Tarefas marcadas
[//] não compartilham arquivo alvo
4.3. Não há ciclo de dependência
Severidade
| Severidade |
Quando aplicar |
| CRITICAL |
Conflito direto com regra 🟢 do legado, contrato externo quebrado, ciclo de dependência |
| HIGH |
Requisito sem cobertura no roadmap, decisão sem ação correspondente, identificador fantasma |
| MEDIUM |
Inconsistência terminológica entre dois documentos, dependência apontando para fora da lista |
| LOW |
Cosmético, ortografia em ID, paralelismo subutilizado |
Construção do relatório
Grave em feature-dir/audit/cross-check.md:
- Cabeçalho com data, identificador da feature e link para os três artefatos analisados
- Resumo: contagem de findings por severidade
- Tabela
ID | Severidade | Eixo | Descrição | Onde está
- Para cada finding CRITICAL ou HIGH, parágrafo explicando o impacto e sugestão de skill para o humano corrigir (NUNCA prometa que esse skill faz a correção, apenas indique a direção)
- Lista de itens verificados que passaram, agrupados por eixo (para o humano enxergar o que está OK)
Use IDs no formato A001, A002, ... estáveis dentro do relatório, mas NÃO compartilhados com IDs de outros documentos.
Persistência
- Crie
feature-dir/audit/ se não existir
- Grave
cross-check.md com escrita atômica
- Sempre rewrite completo, jamais append
Ganchos Pós-execução
Aplique after-audit da forma padrão.
Relatório final ao usuário
- Caminho absoluto do
cross-check.md
- Contagem de findings por severidade (CRITICAL, HIGH, MEDIUM, LOW)
- Aviso explícito: nenhum dos três artefatos foi alterado
- Sugestão de próximo passo:
4.1. Se houver CRITICAL ou HIGH, sugerir revisão manual antes de seguir
4.2. Caso contrário, sugerir
/reversa-coding
Termine com:
Digite CONTINUAR para prosseguir conforme a sugestão acima.
1---2name: reversa-audit3description: 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.4license: MIT5---67Você é o auditor. Esse skill é estritamente leitor. Sua missão é encontrar contradições e lacunas entre `requirements.md`, `roadmap.md` e `actions.md`, e produzir um relatório para o humano resolver.89## Regra inegociável1011Esse skill NUNCA altera `requirements.md`, `roadmap.md`, `actions.md`, `data-delta.md`, `interfaces/`, `investigation.md` ou `onboarding.md`. Em hipótese alguma, mesmo que o usuário peça. Se o usuário pedir correção, oriente-o a usar `/reversa-clarify` ou edição manual.1213A única escrita permitida é `feature-dir/audit/cross-check.md`.1415## Antes de começar16171. Leia `.reversa/state.json` para resolver `output_folder` e `forward_folder`182. Use os valores reais nos lugares onde o texto mencionar `_reversa_sdd/` ou `_reversa_forward/`1920## Verificações Iniciais21221. Leia `.reversa/active-requirements.json`23 1.1. Se ausente, aborte242. Verifique existência dos três artefatos: `requirements.md`, `roadmap.md`, `actions.md`25 2.1. Se algum estiver ausente, aborte com mensagem listando o que falta e qual skill gera263. Aplique `before-audit` da forma padrão2728## Eixos de comparação2930Verifique cada par de artefatos quanto a:31321. Cobertura33 1.1. Todo requisito funcional virou pelo menos uma decisão no roadmap34 1.2. Toda decisão no roadmap virou pelo menos uma ação no actions35 1.3. Todo cenário Gherkin do requirements está coberto por alguma ação ou decisão362. Consistência37 2.1. Termos usam o mesmo nome ao longo dos três documentos (não apareça "fatura" em um e "boleto" em outro)38 2.2. Identificadores citados existem (RF-12 referenciado no roadmap precisa existir no requirements)39 2.3. Contratos descritos em `interfaces/` aparecem no roadmap403. Coerência com o legado41 3.1. Decisões do roadmap não contradizem regras 🟢 do `_reversa_sdd/domain.md`42 3.2. Componentes do `_reversa_sdd/architecture.md` citados existem mesmo434. Sanidade do actions44 4.1. Dependências apontam para IDs existentes45 4.2. Tarefas marcadas `[//]` não compartilham arquivo alvo46 4.3. Não há ciclo de dependência4748## Severidade4950| Severidade | Quando aplicar |51|------------|----------------|52| CRITICAL | Conflito direto com regra 🟢 do legado, contrato externo quebrado, ciclo de dependência |53| HIGH | Requisito sem cobertura no roadmap, decisão sem ação correspondente, identificador fantasma |54| MEDIUM | Inconsistência terminológica entre dois documentos, dependência apontando para fora da lista |55| LOW | Cosmético, ortografia em ID, paralelismo subutilizado |5657## Construção do relatório5859Grave em `feature-dir/audit/cross-check.md`:60611. Cabeçalho com data, identificador da feature e link para os três artefatos analisados622. Resumo: contagem de findings por severidade633. Tabela `ID | Severidade | Eixo | Descrição | Onde está`644. Para cada finding CRITICAL ou HIGH, parágrafo explicando o impacto e sugestão de skill para o humano corrigir (NUNCA prometa que esse skill faz a correção, apenas indique a direção)655. Lista de itens verificados que passaram, agrupados por eixo (para o humano enxergar o que está OK)6667Use IDs no formato `A001`, `A002`, ... estáveis dentro do relatório, mas NÃO compartilhados com IDs de outros documentos.6869## Persistência7071- Crie `feature-dir/audit/` se não existir72- Grave `cross-check.md` com escrita atômica73- Sempre rewrite completo, jamais append7475## Ganchos Pós-execução7677Aplique `after-audit` da forma padrão.7879## Relatório final ao usuário80811. Caminho absoluto do `cross-check.md`822. Contagem de findings por severidade (CRITICAL, HIGH, MEDIUM, LOW)833. Aviso explícito: nenhum dos três artefatos foi alterado844. Sugestão de próximo passo:85 4.1. Se houver CRITICAL ou HIGH, sugerir revisão manual antes de seguir86 4.2. Caso contrário, sugerir `/reversa-coding`8788Termine com:8990> Digite **CONTINUAR** para prosseguir conforme a sugestão acima.
stribus