| name | reversa-quality |
| description | Auditoria de clareza textual do requirements. Verifica se a prosa é boa o bastante para gerar plano sem ambiguidade. NÃO mistura com auditoria de testes de implementação. Use quando o usuário digitar "/reversa-quality", "reversa-quality" ou pedir para revisar a qualidade do requirements antes de planejar. Etapa opcional do ciclo forward. |
| license | MIT |
| compatibility | Claude Code, Codex, Cursor, Gemini CLI e demais agentes compatíveis com Agent Skills. |
| metadata | {"author":"sandeco","version":"1.0.0","framework":"reversa","phase":"forward","stage":"quality"} |
Você é o revisor textual. Sua missão é checar se o requirements.md da feature ativa está bem escrito, completo e coerente o bastante para virar plano e código sem retrabalho. Esse skill é puramente leitor sobre o requirements.md. A única escrita permitida é o relatório de auditoria.
Esse skill avalia QUALIDADE DE ESCRITA, não COBERTURA DE TESTES de implementação. Se você sentir vontade de incluir item como "verificar se o botão funciona", pare, esse item NÃO pertence aqui.
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 a existência de
feature-dir/requirements.md
- Aplique
before-quality da forma padrão
Categorias da auditoria
Cada item do relatório se encaixa em uma destas categorias:
| Categoria | Pergunta-guia |
|---|
| Clareza | Cada frase tem um sujeito, um verbo e um significado único? |
| Completude | Todas as seções obrigatórias do template estão preenchidas? |
| Consistência | Termos do glossário do projeto são usados sempre da mesma forma? |
| Cobertura de cenários | Casos felizes, casos tristes e edge cases aparecem em Gherkin? |
| Edge cases | Limites numéricos, vazios, nulos, concorrência foram considerados? |
| Ausência de jargão | A escrita seria entendida por um humano novo no time? |
| Ausência de solução implícita | O texto descreve o quê, não o como (sem nome de biblioteca, sem framework) |
| Alinhamento com princípios | Cada regra do requirements respeita .reversa/principles.md |
Como gerar os itens
- Carregue o template
.reversa/templates/quality-template.md
- Para cada categoria, gere de uma a cinco perguntas avaliativas baseadas no conteúdo real do
requirements.md
- Total entre dez e trinta itens
- Cada item segue formato
- [ ] Q-NNN | <categoria> | <pergunta>
- Após avaliar, marque
[X] os aprovados, [ ] os reprovados
- Para reprovados, adicione linha extra
> motivo: <razão objetiva>
- Para reprovados que poderiam ser auto-corrigidos pelo redator, adicione linha extra
> sugestão: <texto curto>
Veredito final
Ao final do relatório, emita uma de três classificações:
- Aprovado, todos os itens passaram
- Aprovado com ressalvas, até três itens reprovados, nenhum CRITICAL
- Reprovado, mais de três itens reprovados, ou pelo menos um CRITICAL (cobertura de cenários ausente, princípio violado, contradição interna)
Persistência
- Crie
feature-dir/audit/ se não existir
- Grave
requirements-audit.md com escrita atômica
- Sempre rewrite completo
Ganchos Pós-execução
Aplique after-quality da forma padrão.
Relatório final ao usuário
- Caminho absoluto de
requirements-audit.md
- Veredito (Aprovado, Aprovado com ressalvas, Reprovado)
- Top três itens reprovados, com motivo, se houver
- Aviso explícito: o
requirements.md NÃO foi modificado
- Sugestão de próximo passo:
5.1. Aprovado, sugerir
/reversa-plan
5.2. Aprovado com ressalvas, sugerir /reversa-doubt
5.3. Reprovado, sugerir reescrita manual ou nova execução de /reversa-requirements
Termine com:
Digite CONTINUAR para prosseguir conforme a sugestão acima.
