bright-y/static-prototype-splitter

Static Prototype Splitter (Divididor de Prototipos Estáticos)

Usa esta habilidad para convertir un prototipo estático terminado o semiterminado en un entregable más limpio para demostración, iteración, migración o transferencia.

El objetivo no es rediseñar el producto. Preserva la dirección visual existente y la intención de interacción, haciendo que el prototipo sea más fácil de abrir, inspeccionar, modificar y migrar.

Alcance y Transferencia

• Usa esta habilidad para un nuevo entregable de división, componentización o transferencia a partir de un prototipo estático existente. Para ediciones continuas en un prototipo ya organizado, usa prototype-maintenance cuando esté disponible; no es una dependencia requerida.
• Para un cambio pequeño de copia o estilo, realiza el cambio solicitado sin reestructurar el prototipo.
• Mantén los proyectos de framework existentes en su pila establecida; no aplastes un proyecto React/Vue o similar a HTML estático a menos que se solicite.
• Sigue las reglas de autorización del usuario para reemplazo de archivos, configuración, dependencias, acceso a red, servidores locales y datos almacenados. Esta habilidad no otorga esos permisos.

Principios Predeterminados

• Preserva los archivos fuente. No sobrescribas el prototipo original a menos que el usuario lo pida explícitamente.
• Crea carpetas de salida con marca de tiempo para los entregables generados.
• Mantén las ediciones centradas en la estructura, las rutas, los activos reutilizables y el cableado de interacción básico.
• Mantén el idioma original, la terminología del producto, el estilo visual y la jerarquía de páginas.
• Prefiere HTML/CSS/JS estático simple a menos que el usuario solicite un framework.
• Evita rediseños no relacionados, instalación de dependencias, herramientas de compilación o migración de framework.
• Cuando un prototipo necesite tanto páginas divididas como una vista previa completa, trata los archivos de páginas divididas como la fuente única de verdad. Evita mantener una segunda copia divergente del contenido de la página o la lógica de interacción en el punto de entrada combinado.
• El punto de entrada combinado debe componer, cargar o generar a partir del código fuente de las páginas divididas mediante enrutamiento, plantillas, módulos compartidos o un pequeño script de compilación/sincronización. Si una implementación combinada temporal es necesaria por fiabilidad, señala la duplicación y recomienda reconciliarla antes de continuar con la iteración a nivel de página.
• Para ediciones posteriores de páginas, modifica primero la página dividida específica y su script a nivel de página, luego actualiza o regenera la vista previa combinada para que el usuario no tenga que hacer el mismo cambio dos veces.

Cuándo Activar

Activa esta habilidad cuando el usuario pida:

• Dividir un prototipo HTML grande en páginas separadas.
• Organizar un prototipo estático en una carpeta de entregables.
• Componentizar un prototipo HTML estático.
• Empaquetar un prototipo para entrega o demostración.
• Crear una versión más limpia de un prototipo de diseño de producto.
• Convertir una aplicación estática de un solo archivo en una estructura de múltiples páginas o componentes estáticos.
• Preparar un prototipo para una migración posterior a Vue, React, Taro, uni-app, miniprograma de WeChat u otra pila frontend.

Formatos de Salida Recomendados

Elige uno o más formatos según la solicitud.

Versión de Archivos Divididos

Úsala cuando el usuario necesite páginas de demostración estáticas fáciles o iteración de diseño página por página.

Estructura recomendada:

output_YYYYMMDD-HHMMSS/
├── split-file-version/
│   ├── index.html
│   ├── page-a.html
│   ├── page-b.html
│   └── assets/
│       ├── styles.css
│       └── app.js
└── README.md

Pautas:

• Cada vista principal se convierte en un archivo HTML.
• Preserva la navegación entre páginas mediante enlaces normales cuando sea práctico.
• Extrae CSS compartido y JS ligero en assets/.
• Mantén cada página abrible de forma independiente en un navegador.
• Mantén los nombres de página significativos y estables.

Versión Estática Componentizada

Úsala cuando el prototipo deba facilitar la migración posterior a un framework frontend.

Estructura recomendada:

output_YYYYMMDD-HHMMSS/
├── componentized-version/
│   ├── index.html
│   └── assets/
│       ├── styles.css
│       ├── components.js
│       ├── data.js
│       └── app.js
└── README.md

Pautas:

• index.html: shell, contenedor raíz, referencias a scripts/estilos.
• assets/styles.css: estilos compartidos.
• assets/data.js: datos simulados y datos comerciales, cuando sea útil.
• assets/components.js: funciones de renderizado HTML reutilizables o plantillas de componentes.
• assets/app.js: cambio de ruta, estado, enlace de eventos e interacciones simples.
• Mantén esta versión libre de framework a menos que el usuario solicite un framework específico.
• Si también existen páginas HTML divididas, no dupliques manualmente su contenido dentro de app.js. Prefiere importar plantillas compartidas, cargar fragmentos de página o usar un paso de sincronización determinista para que las páginas divididas sigan siendo la fuente de mantenimiento.

Vista Previa Combinada a Partir de Páginas Divididas

Úsala cuando el usuario quiera que cada página sea editable de forma independiente y también necesite una vista previa interactiva completa.

Estructura recomendada:

prototype/
├── app.html                  # Shell de vista previa completa
├── pages/
│   ├── welcome.html
│   ├── templates.html
│   └── ...
├── assets/
│   ├── css/styles.css
│   ├── js/common.js
│   ├── js/router.js          # Solo enrutamiento/composición de vista previa
│   └── js/pages/
│       ├── templates.js
│       └── ...
└── README.md

Pautas:

• Mantén el marcado de página y el comportamiento específico de la página en pages/ y assets/js/pages/.
• Mantén app.html como un shell: marco de dispositivo, navegación, contenedor de ruta y referencias de scripts/estilos compartidos.
• Mantén router.js centrado en cargar páginas, enlazar la navegación compartida, preservar el estado y los aspectos exclusivos de la vista previa.
• Evita un app-combined.js largo que reescriba cada página manualmente. Si existe como solución temporal a corto plazo, márcalo como generado o temporal y reconcílialo con las páginas divididas antes de hacer muchas ediciones de página.
• Cuando el usuario pida modificar una página, edita solo esa página y su script de página a menos que el shell de vista previa o los estilos compartidos realmente necesiten ajustes.

Carpeta Empaquetada para Entrega

Úsala cuando el usuario solicite un paquete completo o un lote de entrega.

Estructura recomendada:

prototipo-producto-completo_YYYYMMDD-HHMMSS/
├── instrucciones-de-uso.md
├── archivos-originales/
├── version-archivos-divididos/
└── version-componentizada/

Pautas:

• Incluye solo los archivos necesarios para la demostración y la entrega.
• Mantén los nombres de archivo fuente reconocibles.
• Si creas un archivo comprimido, usa un nombre con marca de tiempo.
• No elimines carpetas intermedias generadas a menos que el usuario lo confirme.

Flujo de Trabajo

1. Inspecciona los archivos del prototipo.

   • Identifica archivos de entrada, vistas principales, CSS compartido, JS compartido, controladores de eventos en línea, activos, dependencias CDN externas, diálogos, paneles laterales, pestañas y navegación de páginas.
   • Usa rg --files y lecturas dirigidas antes de editar.

2. Decide el formato de salida.

   • Si el usuario solo pide dividir: crea version-archivos-divididos.
   • Si el usuario pida preparación para migración o componentización: crea version-componentizada.
   • Si el usuario pide entrega: crea un paquete completo con una nota de uso.
   • Si no está claro, elige la salida más pequeña que cumpla con la solicitud. Crea múltiples versiones solo cuando sirvan una necesidad declarada; mantén una fuente autorizada para el contenido y el comportamiento compartidos.

3. Crea una carpeta de salida con marca de tiempo.

   • Formato de marca de tiempo recomendado: AAAAMMDD-HHMMSS.
   • Preserva los archivos originales sin cambios.

4. Extrae y organiza.

   • Mueve el CSS compartido a una hoja de estilo común.
   • Mueve el JS compartido a un script común.
   • Normaliza las rutas de los activos.
   • Convierte las vistas principales en archivos HTML separados o plantillas de componentes.
   • Mantén las interacciones que importan para la demostración: navegación, pestañas, paneles laterales, modales, alternadores, transiciones lista-detalle, formularios básicos y entradas de archivos.

5. Resuelve los detalles de ejecución y extracción.

   • Elige el modo de apertura antes de la implementación: páginas directas file://, o vista previa HTTP cuando se usen fragmentos obtenidos o módulos ES. No prometas operación de doble clic para un diseño que requiera HTTP. Reutiliza un servidor de vista previa existente cuando sea posible; iniciar uno sigue las reglas de autorización del usuario.
   • Mantén los documentos HTML completos y los fragmentos cargables distintos. Al cargar un fragmento en un shell, normaliza sus rutas de activos relativos y URL de navegación a la base del shell; la inserción de fragmentos en bruto no preserva la URL base del documento fuente ni ejecuta sus scripts de manera confiable.
   • Al mover CSS en línea a una hoja de estilo, reubica las rutas de url(...), las fuentes y las rutas de importación en relación con la nueva hoja de estilo. Preserva el orden de cascada, la especificidad y el comportamiento responsivo.
   • Mantén un modelo de script coherente. Preserva el orden de carga y el estado compartido para scripts clásicos; preserva los límites de importación/exportación para módulos. Los controladores en línea no pueden acceder a funciones locales del módulo sin un puente explícito.
   • Monta el comportamiento de la página de forma explícita y limpia los oyentes o temporizadores al salir de una vista. Verifica que volver a visitar una página no registre acciones dos veces.
   • Inventaría las claves de almacenamiento existentes y las transiciones de estado antes de dividir. No borres el almacenamiento ni sobrescribas silenciosamente los datos creados por el usuario para que la demostración funcione.

6. Escribe la documentación de transferencia.

   • Incluye archivo fuente, hora de generación, páginas de entrada, propósito de la carpeta y próximos pasos recomendados.
   • Mantén la documentación breve y útil.

7. Verifica.

   • Comprueba que existan los archivos HTML de entrada.
   • Comprueba las rutas CSS/JS enlazadas, las URL de activos CSS, los activos de fragmentos y los destinos de navegación desde cada entrada o vista compuesta.
   • Abre o previsualiza localmente cuando sea práctico.
   • Para prototipos visuales, verifica el diseño de escritorio/móvil si hay una herramienta de navegador disponible.
   • Compara rutas clave e interacciones con el original: renderizado inicial, navegación adelante/atrás, revisita de una vista, confirmación/cancelación modal y estado guardado después de actualizar, donde corresponda.
   • Menciona cualquier comportamiento no verificado o el riesgo de dependencia CDN externa. No afirmes soporte sin conexión sin verificar los recursos externos.

Plantilla de README / Nota de Uso

Usa un README conciso en el idioma del usuario o del proyecto. El siguiente ejemplo en chino se puede adaptar; enumera solo las entradas realmente generadas e indica si se requiere HTTP:

# 项目原型整理

生成时间：YYYY-MM-DD HH:mm:ss

来源文件：原始文件名.html

## 推荐打开

- `拆分文件版/index.html`
- `组件化版/index.html`

## 拆分文件版

适合静态原型演示和逐页设计调整。每个页面是独立 HTML，页面之间通过文件链接跳转。

## 组件化版

适合继续演进为 Vue、React、Taro、uni-app、微信小程序或其他前端结构。

## 说明

- 原始文件未被修改。
- 公共样式和脚本已整理到 `assets/`。
- 如需继续工程化，可优先迁移 `components.js`、`data.js` 和 `app.js`。

Lista de Verificación de Calidad

Antes de la respuesta final, verifica:

• Los archivos fuente originales se han preservado.
• La carpeta de salida tiene una marca de tiempo.
• Los archivos de entrada tienen nombres claros.
• Las rutas de los activos funcionan en relación con cada archivo HTML.
• La navegación entre páginas o vistas sigue funcionando.
• Las interacciones importantes no se han perdido.
• El README o la nota de uso explica qué abrir.
• La respuesta final incluye la ruta guardada y el resultado de la verificación.