bright-y/static-prototype-splitter

Static Prototype Splitter

Utilisez ce skill pour transformer un prototype statique, terminé ou semi-fini, en une version plus propre destinée à la démonstration, l'itération, la migration ou la remise.

L'objectif n'est pas de reconcevoir le produit. Préservez la direction visuelle existante et l'intention interactive tout en rendant le prototype plus facile à ouvrir, inspecter, modifier et migrer.

Périmètre et remise

• Utilisez ce skill pour une nouvelle remise découpée, componentisée ou de transfert à partir d'un prototype statique existant. Pour des modifications continues sur un prototype déjà organisé, utilisez prototype-maintenance lorsqu'il est disponible ; ce n'est pas une dépendance obligatoire.
• Pour une petite modification de copie ou de style, effectuez la modification demandée sans restructurer le prototype.
• Conservez les projets de framework existants dans leur stack établie ; n'aplatissez pas un projet React/Vue ou similaire en HTML statique sauf demande explicite.
• Suivez les règles d'autorisation de l'utilisateur concernant le remplacement de fichiers, la configuration, les dépendances, l'accès réseau, les serveurs locaux et les données stockées. Ce skill n'accorde pas ces autorisations.

Principes par défaut

• Préservez les fichiers sources. N'écrasez pas le prototype original sauf si l'utilisateur le demande explicitement.
• Créez des dossiers de sortie horodatés pour les livrables générés.
• Limitez les modifications à la structure, aux chemins, aux actifs réutilisables et au câblage des interactions de base.
• Conservez la langue d'origine, la terminologie du produit, le style visuel et la hiérarchie des pages.
• Préférez le HTML/CSS/JS statique simple sauf si l'utilisateur demande un framework.
• Évitez les refontes non liées, l'installation de dépendances, les outils de build ou la migration de framework.
• Lorsqu'un prototype nécessite à la fois des pages découpées et un aperçu complet, traitez les fichiers de pages découpées comme la source unique de vérité. Évitez de maintenir une deuxième copie divergente du contenu de la page ou de la logique d'interaction dans l'entrée combinée.
• L'entrée combinée doit composer, charger ou générer à partir de la source des pages découpées via le routage, les templates, les modules partagés ou un petit script de build/synchronisation. Si une implémentation combinée temporaire est nécessaire pour la fiabilité, signalez la duplication et recommandez de la réconcilier avant toute itération ultérieure au niveau de la page.
• Pour les modifications ultérieures de page, modifiez d'abord la page découpée spécifique et son script au niveau de la page, puis rafraîchissez ou régénérez l'aperçu combiné afin que l'utilisateur n'ait pas à effectuer la même modification deux fois.

Quand déclencher

Déclenchez ce skill lorsque l'utilisateur demande de :

• Découper un grand prototype HTML en pages séparées.
• Organiser un prototype statique dans un dossier de livrable.
• Componentiser un prototype HTML statique.
• Empaqueter un prototype pour une remise ou une démonstration.
• Créer une version plus propre d'un prototype de design produit.
• Convertir une application statique monofichier en une structure multipage ou à composants statiques.
• Préparer un prototype pour une migration ultérieure vers Vue, React, Taro, uni-app, un mini-programme WeChat ou une autre stack frontend.

Formes de sortie recommandées

Choisissez une ou plusieurs formes en fonction de la demande.

Version fichiers découpés

Utilisez-la lorsque l'utilisateur a besoin de pages de démonstration statiques faciles ou d'itération de design page par page.

Structure recommandée :

sortie_AAAAMMJJ-HHMMSS/
├── fichiers_decoupes/
│   ├── index.html
│   ├── page-a.html
│   ├── page-b.html
│   └── assets/
│       ├── styles.css
│       └── app.js
└── README.md

Directives :

• Chaque vue principale devient un fichier HTML.
• Préservez la navigation entre les pages par des liens normaux lorsque c'est pratique.
• Extrayez le CSS partagé et le JS léger dans assets/.
• Chaque page doit pouvoir être ouverte indépendamment dans un navigateur.
• Gardez des noms de page significatifs et stables.

Version componentisée statique

Utilisez-la lorsque le prototype doit pouvoir être migré plus facilement vers un framework frontend ultérieurement.

Structure recommandée :

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

Directives :

• index.html : coquille, conteneur racine, références aux scripts et styles.
• assets/styles.css : styles partagés.
• assets/data.js : données mock et données métier, si utiles.
• assets/components.js : fonctions de rendu HTML réutilisables ou templates de composants.
• assets/app.js : changement de route, état, liaison d'événements et interactions simples.
• Conservez cette version sans framework sauf si l'utilisateur demande un framework spécifique.
• Si des pages HTML découpées existent également, ne dupliquez pas manuellement leur contenu dans app.js. Préférez importer des templates partagés, charger des fragments de page ou utiliser une étape de synchronisation déterministe afin que les pages découpées restent la source de maintenance.

Aperçu combiné à partir de pages découpées

Utilisez-le lorsque l'utilisateur souhaite que chaque page soit modifiable indépendamment tout en disposant d'un aperçu interactif complet.

Structure recommandée :

prototype/
├── app.html                  # Coquille d'aperçu complet
├── pages/
│   ├── accueil.html
│   ├── templates.html
│   └── ...
├── assets/
│   ├── css/styles.css
│   ├── js/common.js
│   ├── js/router.js          # Routage/composition d'aperçu uniquement
│   └── js/pages/
│       ├── templates.js
│       └── ...
└── README.md

Directives :

• Conservez le balisage de la page et le comportement spécifique à la page dans pages/ et assets/js/pages/.
• Conservez app.html comme une coquille : cadre de périphérique, navigation, conteneur de route et références partagées de script/style.
• Limitez router.js au chargement des pages, à la liaison de la navigation partagée, à la conservation de l'état et aux préoccupations liées à l'aperçu uniquement.
• Évitez un long app-combined.js qui réécrit chaque page manuellement. S'il en existe un comme solution de contournement à court terme, marquez-le comme généré ou temporaire et réconciliez-le avec les pages découpées avant d'effectuer de nombreuses modifications de page.
• Lorsque l'utilisateur demande de modifier une page, modifiez uniquement cette page et son script de page, sauf si la coquille d'aperçu ou les styles partagés nécessitent vraiment un ajustement.

Dossier de remise empaqueté

Utilisez-le lorsque l'utilisateur demande un paquet complet ou un lot de livraison.

Structure recommandée :

paquet_complet_prototype_produit_AAAAMMJJ-HHMMSS/
├── mode_d_emploi.md
├── fichiers_originaux/
├── fichiers_decoupes/
└── version_componentisee/

Directives :

• Incluez uniquement les fichiers nécessaires à la démonstration et à la remise.
• Conservez les noms de fichiers sources reconnaissables.
• Si vous créez une archive, utilisez un nom horodaté.
• Ne supprimez pas les dossiers générés intermédiaires sauf confirmation de l'utilisateur.

Flux de travail

1. Inspectez les fichiers du prototype.

   • Identifiez les fichiers d'entrée, les vues principales, les CSS partagés, les JS partagés, les gestionnaires d'événements en ligne, les actifs, les dépendances CDN externes, les boîtes de dialogue, les panneaux latéraux, les onglets et la navigation entre les pages.
   • Utilisez rg --files et des lectures ciblées avant de modifier.

2. Déterminez la forme de sortie.

   • Si l'utilisateur demande uniquement un découpage : créez fichiers_decoupes.
   • Si l'utilisateur demande une préparation à la migration ou une componentisation : créez version_componentisee.
   • Si l'utilisateur demande une livraison : créez un paquet complet avec une note d'utilisation.
   • En cas de doute, choisissez la sortie la plus petite qui répond à la demande. Créez plusieurs versions uniquement si elles servent un besoin exprimé ; conservez une source faisant autorité pour le contenu partagé et le comportement.

3. Créez un dossier de sortie horodaté.

   • Format d'horodatage recommandé : AAAAMMJJ-HHMMSS.
   • Conservez les fichiers originaux inchangés.

4. Extrayez et organisez.

   • Déplacez les CSS partagés dans une feuille de style commune.
   • Déplacez les JS partagés dans un script commun.
   • Normalisez les chemins des actifs.
   • Convertissez les vues principales en fichiers HTML séparés ou en templates de composants.
   • Conservez les interactions importantes pour la démonstration : navigation, onglets, panneaux latéraux, modales, toggles, transitions liste-détail, formulaires de base et entrées de fichiers.

5. Résolvez les détails d'exécution et d'extraction.

   • Choisissez le mode d'ouverture avant l'implémentation : pages file:// directes, ou aperçu HTTP lors de l'utilisation de fragments récupérés ou de modules ES. Ne promettez pas un fonctionnement en double-clic pour une conception nécessitant HTTP. Réutilisez un serveur d'aperçu existant lorsque c'est possible ; son démarrage suit les règles d'autorisation de l'utilisateur.
   • Conservez les documents HTML complets et les fragments chargeables distincts. Lors du chargement d'un fragment dans une coquille, normalisez ses actifs relatifs et ses URL de navigation par rapport à la base de la coquille ; l'insertion brute d'un fragment ne préserve pas l'URL de base du document source et n'exécute pas ses scripts de manière fiable.
   • Lors du déplacement de CSS en ligne dans une feuille de style, rebasez les chemins url(...), de police et d'importation par rapport à la nouvelle feuille de style. Préservez l'ordre en cascade, la spécificité et le comportement responsive.
   • Conservez un modèle de script cohérent. Préservez l'ordre de chargement et l'état partagé pour les scripts classiques ; préservez les limites d'import/export pour les modules. Les gestionnaires en ligne ne peuvent pas accéder aux fonctions locales d'un module sans un pont explicite.
   • Montez le comportement de la page explicitement et nettoyez les écouteurs ou les temporisateurs lors du départ d'une vue. Vérifiez que revoir une page n'enregistre pas les actions deux fois.
   • Inventoriez les clés de stockage existantes et les transitions d'état avant de découper. Ne videz pas le stockage et n'écrasez pas silencieusement les données créées par l'utilisateur pour faire fonctionner la démonstration.

6. Rédigez la documentation de remise.

   • Incluez le fichier source, l'heure de génération, les pages d'entrée, l'objectif des dossiers et les prochaines étapes recommandées.
   • Gardez la documentation courte et utile.

7. Vérifiez.

   • Vérifiez que les fichiers HTML d'entrée existent.
   • Vérifiez les chemins CSS/JS liés, les URL d'actifs CSS, les actifs de fragments et les cibles de navigation à partir de chaque entrée ou vue composée.
   • Ouvrez ou prévisualisez localement lorsque c'est pratique.
   • Pour les prototypes visuels, vérifiez la mise en page bureau/mobile si un outil de navigateur est disponible.
   • Comparez les routes et interactions clés avec l'original : rendu initial, navigation avant/arrière, revue d'une vue, confirmation/annulation de modale et état conservé après rafraîchissement le cas échéant.
   • Mentionnez tout comportement non vérifié ou risque de dépendance CDN externe. Ne prétendez pas à un support hors ligne sans vérifier les ressources externes.

Modèle README / Note d'utilisation

Utilisez un README concis dans la langue de l'utilisateur ou du projet. L'exemple chinois suivant peut être adapté ; listez uniquement les entrées réellement générées et indiquez si HTTP est requis :

# Organisation du prototype du projet

Date de génération : AAAA-MM-JJ HH:mm:ss

Fichier source : nom_fichier_source.html

## Ouverture recommandée

- `fichiers_decoupes/index.html`
- `version_componentisee/index.html`

## Version fichiers découpés

Adaptée à la démonstration de prototype statique et aux ajustements de conception page par page. Chaque page est un HTML indépendant, les pages sont liées entre elles par des liens de fichiers.

## Version componentisée

Adaptée à une évolution ultérieure vers Vue, React, Taro, uni-app, mini-programme WeChat ou une autre structure frontend.

## Remarques

- Les fichiers originaux n'ont pas été modifiés.
- Les styles et scripts communs ont été organisés dans `assets/`.
- Pour poursuivre l'industrialisation, migrez en priorité `components.js`, `data.js` et `app.js`.

Liste de contrôle qualité

Avant la réponse finale, vérifiez :

• Les fichiers sources originaux sont préservés.
• Le dossier de sortie a un horodatage.
• Les fichiers d'entrée sont clairement nommés.
• Les chemins des actifs fonctionnent par rapport à chaque fichier HTML.
• La navigation entre les pages ou les vues fonctionne toujours.
• Les interactions importantes ne sont pas perdues.
• Le README ou la note d'utilisation explique ce qu'il faut ouvrir.
• La réponse finale inclut le chemin enregistré et le résultat de la vérification.