bright-y/static-prototype-splitter

Divisor de Protótipo Estático

Use este skill para transformar um protótipo estático finalizado ou semifinalizado em uma entrega mais limpa para demonstração, iteração, migração ou transferência.

O objetivo não é redesenhar o produto. Preserve a direção visual existente e a intenção de interação, tornando o protótipo mais fácil de abrir, inspecionar, modificar e migrar.

Escopo e Transferência

• Use este skill para uma nova entrega de divisão, componentização ou transferência a partir de um protótipo estático existente. Para edições contínuas em um protótipo já organizado, use prototype-maintenance quando disponível; não é uma dependência obrigatória.
• Para uma pequena alteração de cópia ou estilo, faça a alteração solicitada sem reestruturar o protótipo.
• Mantenha projetos de framework existentes em sua pilha estabelecida; não achate um projeto React/Vue ou similar em HTML estático, a menos que solicitado.
• Siga as regras de autorização do usuário para substituição de arquivos, configuração, dependências, acesso à rede, servidores locais e dados armazenados. Este skill não concede essas permissões.

Princípios Padrão

• Preserve os arquivos de origem. Não sobrescreva o protótipo original, a menos que o usuário peça explicitamente.
• Crie pastas de saída com carimbo de data/hora para os entregáveis gerados.
• Mantenha as edições focadas em estrutura, caminhos, ativos reutilizáveis e fiação básica de interação.
• Mantenha o idioma original, a terminologia do produto, o estilo visual e a hierarquia de páginas.
• Prefira HTML/CSS/JS estático simples, a menos que o usuário peça um framework.
• Evite redesenho não relacionado, instalação de dependências, ferramentas de build ou migração de framework.
• Quando um protótipo precisar de páginas divididas e uma visualização completa, trate os arquivos de página dividida como a única fonte da verdade. Evite manter uma segunda cópia divergente do conteúdo da página ou da lógica de interação na entrada combinada.
• A entrada combinada deve compor, carregar ou gerar a partir da fonte da página dividida por meio de roteamento, templates, módulos compartilhados ou um pequeno script de build/sincronização. Se uma implementação combinada temporária for necessária para confiabilidade, destaque a duplicação e recomende reconciliá-la antes de iterações adicionais no nível da página.
• Para edições posteriores de página, modifique primeiro a página dividida específica e seu script no nível da página, depois atualize ou regenere a visualização combinada para que o usuário não precise fazer a mesma alteração duas vezes.

Quando Acionar

Acione este skill quando o usuário pedir para:

• Dividir um protótipo HTML grande em páginas separadas.
• Organizar um protótipo estático em uma pasta de entrega.
• Componentizar um protótipo HTML estático.
• Empacotar um protótipo para entrega ou demonstração.
• Criar uma versão mais limpa de um protótipo de design de produto.
• Converter um aplicativo estático de arquivo único em uma estrutura multi-página ou componente estático.
• Preparar um protótipo para migração posterior para Vue, React, Taro, uni-app, mini programa WeChat ou outra pilha frontend.

Formatos de Saída Recomendados

Escolha um ou mais formatos com base na solicitação.

Versão de Arquivos Divididos

Use quando o usuário precisar de páginas de demonstração estáticas fáceis ou iteração de design página por página.

Estrutura recomendada:

output_directory_YYYYMMDD-HHMMSS/
├── arquivos_divididos/
│   ├── index.html
│   ├── pagina-a.html
│   ├── pagina-b.html
│   └── assets/
│       ├── styles.css
│       └── app.js
└── README.md

Diretrizes:

• Cada visualização principal se torna um arquivo HTML.
• Preserve a navegação entre páginas por meio de links normais, quando prático.
• Extraia CSS compartilhado e JS leve para assets/.
• Mantenha cada página independentemente aberta em um navegador.
• Mantenha os nomes das páginas significativos e estáveis.

Versão Componentizada Estática

Use quando o protótipo deve se tornar mais fácil de migrar para um framework frontend posteriormente.

Estrutura recomendada:

output_directory_YYYYMMDD-HHMMSS/
├── versao_componentizada/
│   ├── index.html
│   └── assets/
│       ├── styles.css
│       ├── components.js
│       ├── data.js
│       └── app.js
└── README.md

Diretrizes:

• index.html: shell, contêiner raiz, referências de script/estilo.
• assets/styles.css: estilos compartilhados.
• assets/data.js: dados simulados e dados de negócio, quando útil.
• assets/components.js: funções de renderização HTML reutilizáveis ou templates de componente.
• assets/app.js: alternância de rotas, estado, vinculação de eventos e interações simples.
• Mantenha esta versão livre de framework, a menos que o usuário peça um framework específico.
• Se páginas HTML divididas também existirem, não duplique manualmente seu conteúdo dentro de app.js. Prefira importar templates compartilhados, carregar fragmentos de página ou usar uma etapa de sincronização determinística para que as páginas divididas permaneçam como fonte de manutenção.

Visualização Combinada a partir de Páginas Divididas

Use quando o usuário desejar cada página editável independentemente enquanto também precisa de uma visualização interativa completa.

Estrutura recomendada:

prototype/
├── app.html                  # Shell de visualização completa
├── pages/
│   ├── welcome.html
│   ├── templates.html
│   └── ...
├── assets/
│   ├── css/styles.css
│   ├── js/common.js
│   ├── js/router.js          # Apenas roteamento/composição da visualização
│   └── js/pages/
│       ├── templates.js
│       └── ...
└── README.md

Diretrizes:

• Mantenha a marcação da página e o comportamento específico da página em pages/ e assets/js/pages/.
• Mantenha app.html como um shell: moldura do dispositivo, navegação, contêiner de rota e referências de script/estilo compartilhados.
• Mantenha router.js focado em carregar páginas, vincular navegação compartilhada, preservar estado e preocupações apenas da visualização.
• Evite um app-combined.js longo que reescreva cada página manualmente. Se um existir como solução temporária, marque-o como gerado ou temporário e reconcilie-o com as páginas divididas antes de fazer muitas edições de página.
• Quando o usuário pedir para modificar uma página, edite apenas essa página e seu script de página, a menos que o shell de visualização ou os estilos compartilhados realmente precisem de ajuste.

Pasta de Entrega Empacotada

Use quando o usuário pedir um pacote completo ou pacote de entrega.

Estrutura recomendada:

pacote_completo_prototipo_YYYYMMDD-HHMMSS/
├── instrucoes_de_uso.md
├── arquivos_originais/
├── arquivos_divididos/
└── versao_componentizada/

Diretrizes:

• Inclua apenas os arquivos necessários para demonstração e entrega.
• Mantenha os nomes dos arquivos de origem reconhecíveis.
• Se criar um arquivo compactado, use um nome com carimbo de data/hora.
• Não exclua pastas intermediárias geradas, a menos que o usuário confirme.

Fluxo de Trabalho

1. Inspecione os arquivos do protótipo.

   • Identifique arquivos de entrada, visualizações principais, CSS compartilhado, JS compartilhado, manipuladores de eventos inline, ativos, dependências CDN externas, diálogos, gavetas, abas e navegação entre páginas.
   • Use rg --files e leituras direcionadas antes de editar.

2. Decida o formato de saída.

   • Se o usuário pedir apenas para dividir: crie arquivos_divididos.
   • Se o usuário pedir prontidão para migração ou componentização: crie versao_componentizada.
   • Se o usuário pedir entrega: crie um pacote completo com uma nota de uso.
   • Se não estiver claro, escolha a menor saída que atenda à solicitação. Crie várias versões apenas quando elas servirem a uma necessidade declarada; mantenha uma fonte autoritativa para conteúdo e comportamento compartilhados.

3. Crie uma pasta de saída com carimbo de data/hora.

   • Formato de carimbo de data/hora recomendado: YYYYMMDD-HHMMSS.
   • Preserve os arquivos originais inalterados.

4. Extraia e organize.

   • Mova CSS compartilhado para uma folha de estilo comum.
   • Mova JS compartilhado para um script comum.
   • Normalize caminhos de ativos.
   • Converta visualizações principais em arquivos HTML separados ou templates de componente.
   • Mantenha as interações importantes para demonstração: navegação, abas, gavetas, modais, alternadores, transições lista-detalhe, formulários básicos e entradas de arquivo.

5. Resolva detalhes de tempo de execução e extração.

   • Escolha o modo de abertura antes da implementação: páginas diretas file:// ou visualização HTTP ao usar fragmentos buscados ou módulos ES. Não prometa operação de clique duplo para um design que exige HTTP. Reutilize um servidor de visualização existente quando possível; iniciar um segue as regras de autorização do usuário.
   • Mantenha documentos HTML completos e fragmentos carregáveis distintos. Ao carregar um fragmento em um shell, normalize seus ativos relativos e URLs de navegação para a base do shell; a inserção bruta de fragmento não preserva a URL base do documento de origem nem executa seus scripts de forma confiável.
   • Ao mover CSS inline para uma folha de estilo, ajuste as bases de url(...), fontes e caminhos de importação relativos à nova folha de estilo. Preserve ordem de cascata, especificidade e comportamento responsivo.
   • Mantenha um modelo de script coerente. Preserve a ordem de carga e o estado compartilhado para scripts clássicos; preserve limites de importação/exportação para módulos. Manipuladores inline não podem acessar funções locais do módulo sem uma ponte explícita.
   • Monte o comportamento da página explicitamente e limpe ouvintes ou timers ao sair de uma visualização. Verifique que revisitar uma página não registra ações duas vezes.
   • Inventarie chaves de armazenamento existentes e transições de estado antes de dividir. Não limpe o armazenamento nem sobrescreva silenciosamente dados criados pelo usuário para fazer a demonstração funcionar.

6. Escreva a documentação de entrega.

   • Inclua arquivo de origem, hora de geração, páginas de entrada, finalidade da pasta e próximos passos recomendados.
   • Mantenha a documentação curta e útil.

7. Verifique.

   • Verifique se os arquivos HTML de entrada existem.
   • Verifique caminhos CSS/JS vinculados, URLs de ativos CSS, ativos de fragmento e destinos de navegação de cada entrada ou visualização composta.
   • Abra ou visualize localmente quando prático.
   • Para protótipos visuais, verifique o layout desktop/mobile se uma ferramenta de navegador estiver disponível.
   • Compare rotas e interações principais com o original: renderização inicial, navegação para frente/trás, revisitar uma visualização, confirmar/cancelar modal e estado salvo após atualização, quando aplicável.
   • Mencione qualquer comportamento não verificado ou risco de dependência CDN externa. Não afirme suporte offline sem verificar recursos externos.

Template de README / Nota de Uso

Use um README conciso no idioma do usuário ou do projeto. O exemplo em português a seguir pode ser adaptado; liste apenas as entradas realmente geradas e declare se HTTP é necessário:

# Organização do Protótipo

Gerado em: YYYY-MM-DD HH:mm:ss

Arquivo de origem: nome_arquivo_original.html

## Recomendado abrir

- `arquivos_divididos/index.html`
- `versao_componentizada/index.html`

## Arquivos Divididos

Adequado para demonstração de protótipo estático e ajustes de design página por página. Cada página é um HTML independente, com navegação entre páginas por links de arquivo.

## Versão Componentizada

Adequado para evoluir para Vue, React, Taro, uni-app, mini programa WeChat ou outras estruturas frontend.

## Observações

- Os arquivos originais não foram modificados.
- Estilos e scripts compartilhados foram organizados em `assets/`.
- Para continuar a engenharia, migre prioritariamente `components.js`, `data.js` e `app.js`.

Lista de Verificação de Qualidade

Antes da resposta final, verifique:

• Os arquivos de origem originais foram preservados.
• A pasta de saída tem um carimbo de data/hora.
• Os arquivos de entrada têm nomes claros.
• Os caminhos dos ativos funcionam em relação a cada arquivo HTML.
• A navegação entre páginas ou visualizações ainda funciona.
• As interações importantes não foram perdidas.
• O README ou nota de uso explica o que abrir.
• A resposta final inclui o caminho salvo e o resultado da verificação.