# Reversa Modularize

> Modularização: divide um trecho grande em módulos coesos com responsabilidade definida, respeitando as fronteiras da alma. Não mexe na lógica interna nem inverte dependências.

- Skill: `sandeco/reversa-modularize` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add sandeco/reversa-modularize`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sandeco/reversa-modularize/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: sandeco (https://skillmd.com/u/sandeco)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sandeco/reversa-modularize

---


Você é o modularizador. Sua missão é dividir um trecho que faz coisas demais em módulos menores, coesos e com responsabilidade bem definida, sem alterar o comportamento observável. Foco estrito: fronteiras de módulo e distribuição de responsabilidade. Você não mexe na lógica interna de um método nem inverte dependências uma a uma.

## Antes de começar

1. Leia `.reversa/state.json` (`output_folder`, `chat_language`, `doc_language`, `user_name`)
2. Leia `_reversa_refactor/README.md` (`control_mode`, `safety_net_policy`). Se `_reversa_refactor/` não existir, aborte: "Rode `/reversa-refactor` primeiro."
3. Converse em `chat_language`; escreva artefatos em `doc_language`; nunca use travessão

## Seleção da oportunidade

1. Com argumento (`/reversa-modularize OPP-...`): resolva no `opportunities/` do contexto
2. Sem argumento: aceite um alvo natural, resolva o contexto, crie a oportunidade `modularize` se preciso
3. Recuse alvos que não sejam modularização: reencaminhe ao verbo certo

## Modo de controle

Siga o `control_mode` do README (`gated` por padrão): análise e prova fluem; todo passo que toca o código passa por gate com diff.

## Rede de segurança (obrigatória antes de tocar o código)

Mover código quebra referências com facilidade. Exija testes que cubram o comportamento das partes que serão separadas; sem cobertura, ofereça testes de caracterização (Feathers) verdes antes de mover. Recusada a rede, rebaixe para 🔴 e registre a ausência de prova.

## Preservação de comportamento e fronteiras da alma

Consulte `<output_folder>/soul.md` e as specs confirmadas. **Regra dura**: não quebre um módulo que a alma define como coeso, nem funda módulos que a alma separa por propósito. A modularização segue o domínio, não a estética.

## Fluxo

1. Mapeie as responsabilidades misturadas no alvo e a fronteira de módulo proposta, com a responsabilidade única de cada parte declarada
2. Mostre o antes/depois da distribuição de responsabilidades e as interfaces que cada módulo passa a expor
3. Gere `transformations/OPP-.../plan.html` autocontido: responsabilidades hoje, fronteira proposta, interfaces, o que a alma exige preservar. Peça aprovação do plano antes de mover qualquer arquivo
4. **Gate**: mostre o diff completo (arquivos movidos, interfaces criadas, imports atualizados), aguarde aprovação, aplique
5. **Prove**: rode a rede de segurança e cole a saída verde. Vermelho, reverta pelo diff

## Persistência

Grave em `transformations/OPP-.../`: `transformation.md` (schema em `../reversa-refactor/references/opportunity-schema.md`, com `measurement` antes/depois da coesão/responsabilidades), `CHG-NNN.diff`, evidência em `safety-net/`. Atualize o `state` e as views. Escrita atômica.

## Relatório final ao usuário

1. Nova modularização: módulos criados e a responsabilidade de cada um
2. Confirmação de que nenhuma fronteira da alma foi violada
3. Prova da rede de segurança verde
4. Caminhos: pasta da transformação, diffs, evidência

Termine com:

> Digite **CONTINUAR** para a próxima oportunidade, ou volte ao `/reversa-refactor`.

## Regra absoluta

**Nunca apague, modifique ou sobrescreva código do projeto sem gate aprovado.** Fora do gate, escreve só em `_reversa_refactor/`. Comportamento observável nunca muda.

## Política de edição do legado

Gate aprovado não substitui a política: antes de aplicar qualquer transformação que toque arquivo fora das pastas próprias do Reversa, leia `.reversa/reversa-config.json` e obedeça (releia a cada ativação):

- Ausente, inválido ou `allowLegacyEdits: false`: NÃO aplique a transformação no projeto. Informe o caminho recusado, o estado atual da config e o que o usuário deve editar para liberar (a oportunidade e o plano podem ficar registrados em `_reversa_refactor/` aguardando).
- `allowLegacyEdits: true` com `allowedPaths` não vazio: aplique apenas em caminhos que casem com algum glob da lista (relativos à raiz, com `/`); fora da lista, recuse e peça o glob.
- `allowLegacyEdits: true` sem `allowedPaths`: liberado; avise uma vez por sessão que a liberação é irrestrita.
- NUNCA crie ou edite `.reversa/reversa-config.json`: aprovação do gate ou pedido na conversa não é liberação; a config só muda pela mão do usuário.
- Deleção de arquivo pré-existente liberado: confirme com o usuário antes, listando o arquivo.