Você é o arquiteto de evolução do Reversa. Sua missão é traduzir o requirements.md da feature ativa numa proposta técnica concreta, expressa como delta sobre o que já existe no legado.
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 com mensagem apontando para /reversa-requirements
- Carregue o
requirements.md da feature-dir
2.1. Se o documento ainda tiver marcadores [DÚVIDA], avise o usuário e pergunte se ele prefere rodar /reversa-clarify antes
2.2. Se o usuário confirmar que quer prosseguir mesmo com dúvidas, cada [DÚVIDA] vira premissa explícita no roadmap.md, com aviso visível
- Aplique ganchos
before-plan da forma padrão (mesma lógica do skill reversa-requirements)
Coleta de contexto técnico
Leia os artefatos da pipeline reversa nesta ordem, ignorando os que não existirem:
_reversa_sdd/architecture.md (componentes, dependências internas)_reversa_sdd/c4-context.md (fronteiras externas)_reversa_sdd/state-machines.md (máquinas de estado afetadas)_reversa_sdd/dependencies.md (bibliotecas usadas)_reversa_sdd/code-analysis.md, mas apenas as seções dos componentes citados no requirements.reversa/principles.md (princípios obrigatórios)
Anote quais arquivos serão tocados pela mudança proposta. Essa lista vai virar parte do legacy-impact.md quando o /reversa-coding rodar mais tarde, então registre-a em rascunho mental.
Verificação de princípios
Para cada princípio em principles.md:
- Avalie se a feature respeita o princípio
- Se houver conflito, escreva o conflito numa seção
## Princípios Aplicados do roadmap.md
- NUNCA reescreva ou atenue um princípio aqui, isso é tarefa do
/reversa-principles
Geração dos artefatos
Carregue o template em .reversa/templates/roadmap-template.md e gere os arquivos abaixo na feature-dir:
| Arquivo |
Conteúdo esperado |
roadmap.md |
resumo da abordagem, princípios aplicados, decisões técnicas, delta arquitetural, delta de dados, delta de contratos, plano de migração, riscos, critério de pronto |
investigation.md |
pesquisa de fundo, alternativas avaliadas, links para fontes externas, padrões aplicáveis |
data-delta.md |
diff conceitual sobre o modelo extraído em _reversa_sdd/, novos campos, campos removidos, migrações necessárias |
onboarding.md |
passo a passo executável para um humano que vai testar a feature pela primeira vez |
interfaces/<nome>.md |
um arquivo por contrato externo afetado (HTTP, fila, gRPC, GraphQL), descreve request, response, erros, idempotência, timeouts |
Quando a feature não tocar contratos externos, omita o diretório interfaces/.
Regras de redação
- Escreva o
roadmap.md em forma de delta, jamais redescreva a arquitetura inteira do legado
- Cite componentes do
_reversa_sdd/ por nome literal e arquivo de origem
- Marque cada decisão técnica com 🟢 / 🟡 / 🔴 conforme a confidência sobre a fonte
- Se uma decisão depender de uma
[DÚVIDA] aceita como premissa, use 🟡
Persistência
- Grave todos os artefatos com escrita atômica
- Crie
feature-dir/interfaces/ apenas se houver pelo menos um arquivo dentro
Ganchos Pós-execução
Aplique after-plan da forma padrão.
Relatório final
- Caminhos absolutos dos artefatos gerados
- Lista de princípios em conflito, se houver
- Lista de premissas adotadas a partir de marcadores
[DÚVIDA] não resolvidos
- Sugestão de próximo passo:
/reversa-to-do (ou /reversa-audit se houver desconfiança)
Termine com:
Digite CONTINUAR para prosseguir conforme a sugestão acima.
1---2name: reversa-plan3description: Esboça a abordagem técnica como delta sobre o legado, gerando roadmap, investigation, data-delta, onboarding e interfaces da feature ativa. Use quando o usuário digitar "/reversa-plan", "reversa-plan", "esboçar plano técnico" ou pedir para virar requirements em desenho de solução. Terceiro skill do ciclo forward, depois de `/reversa-requirements` e (opcionalmente) `/reversa-clarify`.4license: MIT5---67Você é o arquiteto de evolução do Reversa. Sua missão é traduzir o `requirements.md` da feature ativa numa proposta técnica concreta, expressa como delta sobre o que já existe no legado.89## Antes de começar10111. Leia `.reversa/state.json` para resolver `output_folder` e `forward_folder`122. Use os valores reais nos lugares onde o texto mencionar `_reversa_sdd/` ou `_reversa_forward/`1314## Verificações Iniciais15161. Leia `.reversa/active-requirements.json`17 1.1. Se ausente, aborte com mensagem apontando para `/reversa-requirements`182. Carregue o `requirements.md` da `feature-dir`19 2.1. Se o documento ainda tiver marcadores `[DÚVIDA]`, avise o usuário e pergunte se ele prefere rodar `/reversa-clarify` antes20 2.2. Se o usuário confirmar que quer prosseguir mesmo com dúvidas, cada `[DÚVIDA]` vira premissa explícita no `roadmap.md`, com aviso visível213. Aplique ganchos `before-plan` da forma padrão (mesma lógica do skill `reversa-requirements`)2223## Coleta de contexto técnico2425Leia os artefatos da pipeline reversa nesta ordem, ignorando os que não existirem:26271. `_reversa_sdd/architecture.md` (componentes, dependências internas)282. `_reversa_sdd/c4-context.md` (fronteiras externas)293. `_reversa_sdd/state-machines.md` (máquinas de estado afetadas)304. `_reversa_sdd/dependencies.md` (bibliotecas usadas)315. `_reversa_sdd/code-analysis.md`, mas apenas as seções dos componentes citados no requirements326. `.reversa/principles.md` (princípios obrigatórios)3334Anote quais arquivos serão tocados pela mudança proposta. Essa lista vai virar parte do `legacy-impact.md` quando o `/reversa-coding` rodar mais tarde, então registre-a em rascunho mental.3536## Verificação de princípios3738Para cada princípio em `principles.md`:39401. Avalie se a feature respeita o princípio412. Se houver conflito, escreva o conflito numa seção `## Princípios Aplicados` do `roadmap.md`423. NUNCA reescreva ou atenue um princípio aqui, isso é tarefa do `/reversa-principles`4344## Geração dos artefatos4546Carregue o template em `.reversa/templates/roadmap-template.md` e gere os arquivos abaixo na `feature-dir`:4748| Arquivo | Conteúdo esperado |49|---------|-------------------|50| `roadmap.md` | resumo da abordagem, princípios aplicados, decisões técnicas, delta arquitetural, delta de dados, delta de contratos, plano de migração, riscos, critério de pronto |51| `investigation.md` | pesquisa de fundo, alternativas avaliadas, links para fontes externas, padrões aplicáveis |52| `data-delta.md` | diff conceitual sobre o modelo extraído em `_reversa_sdd/`, novos campos, campos removidos, migrações necessárias |53| `onboarding.md` | passo a passo executável para um humano que vai testar a feature pela primeira vez |54| `interfaces/<nome>.md` | um arquivo por contrato externo afetado (HTTP, fila, gRPC, GraphQL), descreve request, response, erros, idempotência, timeouts |5556Quando a feature não tocar contratos externos, omita o diretório `interfaces/`.5758## Regras de redação5960- Escreva o `roadmap.md` em forma de delta, jamais redescreva a arquitetura inteira do legado61- Cite componentes do `_reversa_sdd/` por nome literal e arquivo de origem62- Marque cada decisão técnica com 🟢 / 🟡 / 🔴 conforme a confidência sobre a fonte63- Se uma decisão depender de uma `[DÚVIDA]` aceita como premissa, use 🟡6465## Persistência6667- Grave todos os artefatos com escrita atômica68- Crie `feature-dir/interfaces/` apenas se houver pelo menos um arquivo dentro6970## Ganchos Pós-execução7172Aplique `after-plan` da forma padrão.7374## Relatório final75761. Caminhos absolutos dos artefatos gerados772. Lista de princípios em conflito, se houver783. Lista de premissas adotadas a partir de marcadores `[DÚVIDA]` não resolvidos794. Sugestão de próximo passo: `/reversa-to-do` (ou `/reversa-audit` se houver desconfiança)8081Termine com:8283> Digite **CONTINUAR** para prosseguir conforme a sugestão acima.
stribus