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-clarify
5.3. Reprovado, sugerir reescrita manual ou nova execução de /reversa-requirements
Termine com:
Digite CONTINUAR para prosseguir conforme a sugestão acima.
1---2name: reversa-quality3description: 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.4license: MIT5---67Você é 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.89Esse 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.1011## Antes de começar12131. Leia `.reversa/state.json` para resolver `output_folder` e `forward_folder`142. Use os valores reais nos lugares onde o texto mencionar `_reversa_sdd/` ou `_reversa_forward/`1516## Verificações Iniciais17181. Leia `.reversa/active-requirements.json`19 1.1. Se ausente, aborte202. Verifique a existência de `feature-dir/requirements.md`213. Aplique `before-quality` da forma padrão2223## Categorias da auditoria2425Cada item do relatório se encaixa em uma destas categorias:2627| Categoria | Pergunta-guia |28|-----------|---------------|29| Clareza | Cada frase tem um sujeito, um verbo e um significado único? |30| Completude | Todas as seções obrigatórias do template estão preenchidas? |31| Consistência | Termos do glossário do projeto são usados sempre da mesma forma? |32| Cobertura de cenários | Casos felizes, casos tristes e edge cases aparecem em Gherkin? |33| Edge cases | Limites numéricos, vazios, nulos, concorrência foram considerados? |34| Ausência de jargão | A escrita seria entendida por um humano novo no time? |35| Ausência de solução implícita | O texto descreve o quê, não o como (sem nome de biblioteca, sem framework) |36| Alinhamento com princípios | Cada regra do requirements respeita `.reversa/principles.md` |3738## Como gerar os itens39401. Carregue o template `.reversa/templates/quality-template.md`412. Para cada categoria, gere de uma a cinco perguntas avaliativas baseadas no conteúdo real do `requirements.md`423. Total entre dez e trinta itens434. Cada item segue formato `- [ ] Q-NNN | <categoria> | <pergunta>`445. Após avaliar, marque `[X]` os aprovados, `[ ]` os reprovados456. Para reprovados, adicione linha extra `> motivo: <razão objetiva>`467. Para reprovados que poderiam ser auto-corrigidos pelo redator, adicione linha extra `> sugestão: <texto curto>`4748## Veredito final4950Ao final do relatório, emita uma de três classificações:5152- **Aprovado**, todos os itens passaram53- **Aprovado com ressalvas**, até três itens reprovados, nenhum CRITICAL54- **Reprovado**, mais de três itens reprovados, ou pelo menos um CRITICAL (cobertura de cenários ausente, princípio violado, contradição interna)5556## Persistência5758- Crie `feature-dir/audit/` se não existir59- Grave `requirements-audit.md` com escrita atômica60- Sempre rewrite completo6162## Ganchos Pós-execução6364Aplique `after-quality` da forma padrão.6566## Relatório final ao usuário67681. Caminho absoluto de `requirements-audit.md`692. Veredito (Aprovado, Aprovado com ressalvas, Reprovado)703. Top três itens reprovados, com motivo, se houver714. Aviso explícito: o `requirements.md` NÃO foi modificado725. Sugestão de próximo passo:73 5.1. Aprovado, sugerir `/reversa-plan`74 5.2. Aprovado com ressalvas, sugerir `/reversa-clarify`75 5.3. Reprovado, sugerir reescrita manual ou nova execução de `/reversa-requirements`7677Termine com:7879> Digite **CONTINUAR** para prosseguir conforme a sugestão acima.
stribus